Comment 1 Dani Megert 2009-06-18 04:12:04 EDT

I suspect an install issue/incompatibility.

Cannot reproduce using 3.5 RC4. Please reopen with more detailed steps if you can still reproduce using a build from 
http://download.eclipse.org/eclipse/downloads/drops/S-3.5RC4-200906051444/index.php

Comment 2 Markus Keller 2009-06-18 05:33:05 EDT

This boils down to an NPE in JavaModelManager.containersReset(..), see the very end of the stack trace. This prevents the jdt.core plug-in (and thus also jdt.ui) from being activated:

Caused by: java.lang.NullPointerException
at
org.eclipse.jdt.internal.core.JavaModelManager.containersReset(JavaModelManager.java:748)
at
org.eclipse.jdt.internal.core.JavaModelManager.loadVariablesAndContainers(JavaModelManager.java:3001)
at
org.eclipse.jdt.internal.core.JavaModelManager.startup(JavaModelManager.java:4589)
at org.eclipse.jdt.core.JavaCore.start(JavaCore.java:4965)

Comment 3 Markus Keller 2009-06-18 05:35:24 EDT

Moving to JDT/Core.

Krimarck, could you please attach the affected project here if it's not too big or secret? Or at least the .classpath file in the project? We need to know what's on the build path of that project.

Comment 4 Dani Megert 2009-06-18 07:24:23 EDT

*** Bug 277305 has been marked as a duplicate of this bug. ***

Comment 5 informatica.info 2009-06-18 08:34:43 EDT

It looks like Eclipse sometimes reaches an inconsistent state in the classloading process. In my case, adding the mysql-connector jar file to a project caused the problem, although it only complained after restarting Eclipse. It did not matter whether the file was added as an "External JAR" or as a "Connectivity driver definition", the result was the same.

The workaround is to make a full reinstall, but in order to fix the underlying cause it would help if Eclipse had a more benign reaction to the issue.

Comment 6 Olivier Thomann 2009-06-18 09:28:58 EDT

Jay,

Please investigate.

Comment 7 Krimarck 2009-06-18 10:45:29 EDT

Created attachment 139547 [details]
project .classpath

attach solicited file.

Comment 8 Krimarck 2009-06-18 11:00:55 EDT

Created attachment 139550 [details]
Screenshot

If is useful

Comment 9 Krimarck 2009-06-18 11:05:55 EDT

Created attachment 139551 [details]
log in metadata folder

That is in .metadata folder. i tried atach metadata, but fails because is too big.

Comment 10 Jay Arthanareeswaran 2009-06-22 07:56:48 EDT

I suspect the null containerPath that is getting passed from DriverClasspathContainerPage#update is causing the NPE. 
---
			try {
				oldContainer = JavaCore.getClasspathContainer(container.getPath(), fProject);
			} catch (JavaModelException e) {
				// ignore
				oldContainer = null;
			}
			IClasspathEntry entry = null;
			if (oldContainer != null) {
				try {
					JavaCore.setClasspathContainer(null, new IJavaProject[]{fProject}, new IClasspathContainer[] {oldContainer}, null);
				} catch (JavaModelException e) {

---

Here, JavaCore#getClassContainer is invoked with a non-null path and JavaCore#setClasspathContainer is invoked with a null path. This results in two entries for the same container. Even when the library is removed from the project, the null-keyed container remains and causes a NPE later.

I am moving the bug to Data Tools. Can someone from Data Tools confirm the above, please?

Krimarck, I don't see the same problem with an external JAR file. I guess this could be because of the existing driver library. As a workaround, you can delete the .metadata/.plugins/org.eclipse.jdt.core/variablesAndContainers.dat (after taking backup) and try using an external jar file. Of course, this at the risk of loosing your previous variables and library definitions. This will be quicker and easier than a new install.

Comment 11 Brian Fitzpatrick 2009-06-23 14:47:48 EDT

Interesting. I found little (read: no) documentation on how to expose something along these lines, but I'm not shocked that a bug is appearing now. I can certainly look into fixing this for 1.7.1, but we're too late in the Galileo cycle to really take care of it. 

Comment 12 Brian Fitzpatrick 2009-06-23 14:50:55 EDT

(In reply to comment #10)
> I suspect the null containerPath that is getting passed from
> DriverClasspathContainerPage#update is causing the NPE. 

Do you have any suggestions on how to fix this? The lack of documentation made getting this far like fumbling around in the dark with a match for light...

Comment 13 Dani Megert 2009-06-24 02:29:27 EDT

>The lack of documentation made
>getting this far like fumbling around in the dark with a match for light...
To what part/API do you refer exactly? 
  org.eclipse.jdt.core.JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor)

is very clear about not allowing 'null' hence passing it in is definitely illegal no matter how unclear the API would be in other parts.

Comment 14 Brian Fitzpatrick 2009-08-13 10:32:31 EDT

Hey Dani...

So if you look at the snippet in comment #10, what's the better way to do this so we don't break the legal inputs for the setClasspathContainer call? 

--Fitz

Comment 15 Dani Megert 2009-08-14 05:40:17 EDT

>So if you look at the snippet in comment #10, what's the better way to do this
I'm not quite sure what you want to do with that code.

Comment 16 Brian Fitzpatrick 2009-08-17 15:18:22 EDT

Basically all I'm trying to update the classpath container with an updated jar reference. For example, the user uses a Driver Definition (basically a collection of one or more jar paths for the jars of a JDBC driver) to do some development work in a Java project. He adds a "Driver Jar Classpath" container, which references one of the DTP driver definitions. We add the jars of the driver definition to the project classpath. Later on, the user updates the paths of the referenced driver definition (possibly to point to a different/newer version of the driver) or changes to a different driver definition. We need to 1) remove the old driver jars from the classpath and 2) add the new ones back in. 

So the code basically looks for an old driver classpath container. If it finds one, I want to remove the old classpath container. So I'm trying to see if the project HAS an old container - if it does, I want to set it to remove it, clear it, set it to null, or something... and add a new one back in...

The comment is indicating that somehow we're not removing the old classpath container I think...

Here's the full method... 

	private void update(DriverInstance di) {
		if (di != null) {
			IClasspathContainer container = new DriverClasspathContainer(di.getName());
			IClasspathContainer oldContainer;
			try {
				oldContainer = JavaCore.getClasspathContainer(container.getPath(), fProject);
			} catch (JavaModelException e) {
				// ignore
				oldContainer = null;
			}
			IClasspathEntry entry = null;
			if (oldContainer != null) {
				try {
					JavaCore.setClasspathContainer(null, new IJavaProject[]{fProject}, new IClasspathContainer[] {oldContainer}, null);
				} catch (JavaModelException e) {
					e.printStackTrace();
				}
				entry = JavaCore.newContainerEntry(container.getPath());
			}
			else {
				entry = JavaCore.newContainerEntry(container.getPath());
			}
			fEditResult = entry;
		}
		else {
			fEditResult = null;
		}

Comment 17 Dani Megert 2009-08-18 10:06:20 EDT

I think you only need to set the new actual container. This should do the trick, assuming DriverClasspathContainer is that container:

private void update(DriverInstance di) {
    if (di != null) {
        IClasspathContainer container= new DriverClasspathContainer(di.getName());
        JavaCore.setClasspathContainer(container.getPath(),
new IJavaProject[]{fProject}, container, null);


Note that you cannot remove/unregister a container but just replace it. Also, JavaCore.newContainerEntry(...) will only give you a placeholder for the project which points to the actual container. I don't think you need to recreate them for your use case.

Comment 18 Brian Fitzpatrick 2009-08-18 14:38:04 EDT

Thanks for the suggestion...

The only problem with your JavaCore.setClasspathContainer call is that the 3rd argument is an array...

	public static void setClasspathContainer(IPath containerPath, IJavaProject[] affectedProjects, IClasspathContainer[] respectiveContainers, IProgressMonitor monitor) throws JavaModelException
	
Should it simply be "new IClassPathContainer[] {container}"?

Comment 19 Dani Megert 2009-08-19 02:52:17 EDT

>Should it simply be "new IClassPathContainer[] {container}"?
Yes, of course.

Comment 20 Brian Fitzpatrick 2009-08-27 16:54:51 EDT

Created attachment 145859 [details]
Possible patch

This should fix it based on Dani's suggestions.

Cristian, can you take a look to see if it fixes the issues you were seeing?

Comment 21 Brian Fitzpatrick 2009-08-27 16:54:57 EDT

Created attachment 145860 [details]
mylyn/context/zip

Comment 22 Brian Fitzpatrick 2009-09-02 11:43:06 EDT

unless we hear something in the next day or so, I'm going to bump this to 1.7.2

Comment 23 Christian Dupuis 2009-09-02 12:31:07 EDT

Is there a nightly snapshot build I can test? Thanks.

Comment 24 Brian Fitzpatrick 2009-09-02 12:38:15 EDT

I haven't checked it in. I just have the patch. I'd rather not check it in until it's tested. Sounds like that may be a catch-22?

Comment 25 Dani Megert 2009-09-03 02:46:39 EDT

>sounds like that may be a catch-22?
Brian, you could export the plug-in and attach it here for testing. In order to make it work you must use the exact same bundle version and JAR name as the one that Christian currently uses in his install.

Comment 26 Brian Fitzpatrick 2009-09-03 12:14:10 EDT

Ok. Let's give that a shot. Christian... In your installation, what is the jar name for the org.eclipse.datatools.enablement.jdt.classpath? I'm guessing it's "org.eclipse.datatools.enablement.jdt.classpath_1.0.1.v200906020900.jar"

I'm going to attach a gzip with the jar in it.

Comment 27 Brian Fitzpatrick 2009-09-03 12:14:58 EDT

Created attachment 146417 [details]
Zipped jar to test with

Try this jar to see if it fixes the issue.

Comment 28 Brian Fitzpatrick 2009-09-08 14:12:23 EDT

Since I haven't heard anything else, this is a bit late to get into the 1.7.1 stream for us. We'll push it off to 1.7.2 and get it in early in the release.

Comment 29 Brian Fitzpatrick 2009-09-08 14:12:59 EDT

Setting to 1.7.2

Comment 30 Neil Hauge 2009-09-16 17:29:52 EDT

*** Bug 289503 has been marked as a duplicate of this bug. ***

Comment 31 Brian Fitzpatrick 2009-09-17 15:41:31 EDT

I'd still like to have someone test this before I check it in... Any takers?

Comment 32 Shawn Clark 2009-09-21 12:46:29 EDT

I am having a similar issue that I have described in Bug 289639. I tried using the provided jar file to test and my issue was still present.

Comment 33 Brian Fitzpatrick 2009-09-21 14:38:35 EDT

Ugh. Dani, any other suggestions we can try here?

Comment 34 Shawn Clark 2009-09-21 16:36:11 EDT

Read through this bug and the bug I submitted to understand the root problem a little more. Realized what was being fixed with the jar file and noticed that my test of the jar was only once the problem existed.

My testing was that once the problem showed itself to go and change the jar out and try to load up Eclipse. This would still show the error as there is something with the classpath definition.

I just ran another test with the new jar from a functioning version of my workspace and can not reproduce the problem so it looks like the jar does fix the issue.

Comment 35 Brian Fitzpatrick 2009-09-21 19:28:19 EDT

Whew. :) Thanks for testing Shawn. I'll try and get this fix delivered this week so it'll show up in early 1.7.2 builds of DTP and we can verify once again that things are fixed and working correctly.

Comment 36 Brian Fitzpatrick 2009-09-24 15:42:37 EDT

Delivered fix to o.e.d.e.jdt.classpath as tag v200909240342

Was accidentally delivered under bug 278285, so my apologies. That will remain open and this one will be closed.

Comment 37 Shawn Clark 2009-09-30 12:10:48 EDT

Any chance we could get a new jar file compiled against the SR1 of Galileo as it looks like this issue didn't make it into SR1?

Thanks

Comment 38 Brian Fitzpatrick 2009-09-30 12:19:24 EDT

It didn't make it into SR1, but should appear in any SR2 build (our DTP 1.7.2 builds).

Comment 39 Jay Arthanareeswaran 2009-12-09 23:45:16 EST

*** Bug 294185 has been marked as a duplicate of this bug. ***