Community
Participate
Working Groups
If you have a project using classpathcontainer initializers, the JavaModelCache will contain invalid information about that project. To recreate: 1. Create a Dynamic Web project that uses a classpath initializer - Maven is a good example 2. Define a Tomcat server (any version) 3. Deploy your application to Tomcat, all is good 4. Close the Dynamic Web project 5. Open the Dynamic Web project 6. Redeploy the project to tomcat <project will fail to run because libraries referenced in the classpath are not present> This is NOT a WTP bug. The issue is that when the project opens, JavaElement.openWhenClosed is called. This grabs all the detail on the project and updates it in JavaModelCache. The problem is that the classpathcontainerinitializers have not yet fired, thus the projectCache contains packageFragmentRoots for some things, but not for the classpathcontainerinitializers that have not yet fired. The classpathcontainerinitializers fire later. But after they fire, the JavaModelCache is never refreshed. When J2EEflexProjDeployable attempts to gather the libraries for deployment, it excludes the libraries defined with classpathcontainers since it attempts to validate them against packagefragmentroots. Developers can work around this issue by manually adjusting their classpath or by closing then reopening eclipse.
SAS Institute Inc. is also an adopter that uses a classpath container and suffers from this issue. I would rate the priority more like major since users wouldn't expect that closing and opening a project, or opening a project that was closed when the Eclipse session was started, would break behavior with no indication that something is amiss.
Srikanth, could you please have a look at this one ?
Created attachment 138267 [details] Test case I am having difficulty in reproducing the bug. I have tried this with eclipse 3.4.2 and 3.5 and with the attached dynamic web project but no success. Can you please check the project and let me know if it's okay? Also, I have a question wrt to the steps you have given. I don't find the option to deploy a project to a server. Instead I use the 'Run On Server' option. After closing and opening the project, I have tried both with the tomcat server left running and closed. Please let me know if this is not the right way to do.
Hi, The good news is that this issue appears to be fixed in Eclipse 3.5. However, for completeness, I'll describe the state of the issue with respect to 3.4 and 3.5. The main difficulty in reproducing is that I'm not aware of a way to make the problem visible externally using only WebTools. The classpath containers found in a typical Dynamic Web Project, like the one attached, do not rely on IJavaProject.getPackageFragmentRoots() to help determine what jars to include in a webapp. Only a classpath container marked with the WTP "org.eclipse.jst.component.dependency" attribute relies on getPackageFragmentRoots() to provide accurate data to work correctly. WebTools provides no such classpath containers, so a third party plug-in using this feature is required to view the problem externally, such as the maven plug-ins. However, if you run Eclipse 3.4.x with WebTools in a debug session, it is possible to view the problem with IJavaProject.getPackageFragmentRoots(). If you put a breakpoint at the end of the JavaProject.getPackageFragmentRoots() and examine the size of the returned "roots" you will find the correct size is never returned after closing and opening the project. For the sample project, the correct size I get is 28. After closing and reopening the project, the maximum size returned is only 11. Fortunately, those missing roots don't appear to cause a problem for the typical Dynamic Web Project. So that the issue can be viewed externally, I'll attach an Eclipse 3.4.x plug-in project that implements the type of classpath container that will show the problem. As to what is different in Eclipse 3.5 that fixes the issue, my guess is that the change for revision 406 JavaModelManager likely fixed the issue. It removed calls to containerAddInitializationInProgress() from the JavaModelManager.initializeAllContainers() method. I think it was because these containers were marked as being "initialized" that JavaProject.buildStructure() could "resolve" and cache the classpath without having called any classpath container initialiazers. I can confirm with the plug-in project to be attached, and our SAS Institute Inc adopter product that I do not see this issue when using Eclipse 3.5 and WebTools 3.1 (I'm currently using RC4 versions). Hopefully, Jared can also confirm that the maven plug-ins aren't experiencing this problem with Eclipse 3.5. Thanks, Larry
Created attachment 138689 [details] Zip of a plug-in project that can show the problem Steps to use the attached plug-in project. An Eclipse with Web Tools (Web Developer Tools + Java Developer Tools) is required to use the plug-in project. 1. Import the JavaModelCacheTest plug-in project into a new workspace. 2. Run the plug-in as an Eclipse Application. 3. In the running session, use Preferences to create a TEST_JAR classpath variable that contains the absolute path of some jar. (This jar will be the resolved classpath for the test classpath container.) 4. Execute File -> New -> Other -> Web -> Dynamic Web Project and fill in a project name. 5. Click the Modify button in the Configuration section and check the "Classpath Container Facet". (Adding this facet adds the test classpath container to the project.) 6. Click OK followed by Finish to complete creation of the project. 7. Right click on the new project and select Export -> Web -> WAR file and click Next. 8. Specify a destination and click Finish. 9. Close and re-open the project. 10. Right click on the new project and select Export -> Web -> WAR file and click Next. 11. Specify a second destination and click Finish. When using Eclipse 3.4.x, the first WAR file will contain the TEST_JAR specified in its WEB-INF/lib folder. The second one will not. When using Eclipse 3.5, both WAR files will contain the jar. Let me know if any issues occur using this plug-in project or would like any futher explanation.
Yes, I can see the problem with eclipse 3.4.2 and also see it working with the latest. Thanks Larry, I will spend some time with the code that was modified to resolve the issue, confirm the fix and close this issue.
I agree with Larry's comments (#4) about the changes that seem to have fixed the issue. Now that it's working in the latest, we can close this bug, I guess.
Closing as WORKSFORME as we have confirmation from both user side and JDT/Core side.
Verified for 3.6M1
