Community
Participate
Working Groups
Executing smoke test for build http://build.eclipse.org/webtools/committers/wtp-R3.0-M/20080828055051/M-3.0.2-20080828055051/ Smoke test located at http://wiki.eclipse.org/WTP_Smoke_Test_Results_R302_082808 1.Set up the environment as described in the test. 2.Create a new EJB 3.0 project. 3.Create a new Session Bean in the project as described in the smoke test. Problem: The session bean can not be compiled. Its local interface is located in the client project. JDT reports an error "TestBeanLocal can not be resolved to a Type" Note:The ejb client project is listed in the Java EE Module Dependencies page of the ejb project.
This problem was not observed with official 3.0.1 and 3.1 M1 releases. Therefore, it is seems to be introduced with some changes to the class path dependencies made this week.
One clarification on reproducing: in the smoke test we create the EJB as added to an EAR. This way the EJB project is created together with an EJB Client project.
For cross reference, see also bug 245597
Jason please take a look.
This seems like a similar problem as bug 245426 where JDT is not ready. Bug 245426 is not the problem however. Using the context menu action Java EE Tools -> Update EAR Libraries will force the EAR Libraries context menu to update. Also, this can be easily reproduced simply using regular java classes. Just try referencing any class from the EJB project to the client project, it will not compile.
Jerome, I'm hoping you might be able to add some insight. I'm not sure what is going wrong; I'm attaching a screenshot showing the failure. The project 'Test' contains a class 'test.B' which extends class 'test.A'. Class 'test.A' is in project 'TestClient'. Project 'Test' references project 'TestClient' via the 'EAR Libraries' classpath container. I've been stepping through the EAR Libraries classpath container code, and it appears to be properly including the TestClient project, and the UI reflects this. However, the JDT internals contradict this because of the compilation errors. This only appears to happen the first time these projects are created. Manually removing and readding the classpath container fixes the problem. Using an action we added to force the re computation of the container also fixes the problem. So does restarting the workspace and performing a clean.
Created attachment 111519 [details] screenshot Screenshot showing the entry, yet JDT does not compile.
Looks like bug 244086 is the problem here that introduced this. Not sure why, though. Still seems there is a JDT bug here somewhere.
Maybe this is obvious to you, but seems my first question is which is worse, bug 244086 or this bug? If this bug is worse, should we just revert bug 244086? Until a better fix is available, that is? Thanks,
(In reply to comment #6) Jason, it is hard to tell but here are things to explore: 1. is the classpath container really initializing correctly on the first call? ie. does it call setContainer and does it provide all classpath entries on the first initialize? 2. is there any side effect done by a builder? e.g. the referered project is created by the builder 3. is there a timing issue? i.e. do you still see the problem if you put a breakpoint in your initializer and run under debug?
In reply to comment #9 yes, reverting bug 244086 would be best for the short term. Only the change related to the DependencyGraphImpl is needed.
Created attachment 111584 [details] temporary patch The above described temporary patch.
These projects are not created by builders, rather, all three are created from one wizard. Timing is not affected by setting breakpoints, however, it may be timing related because this problem is only reproducible from Eclipse & WTP. It is not reproducible from an adopter product built on top of Eclipse & WTP. I will double check to ensure org.eclipse.jdt.core.JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor) is being properly called.
(In reply to comment #12) > Created an attachment (id=111584) [details] > temporary patch > > The above described temporary patch. > I still see the same problem with the current RC1 candidate. Jason, have you committed this patch to R3_0_maintenance? I cannot find such change in CVS. Can you check and respin, if necessary, for RC1?
Requesting review for the temporary patch
Approved. (Even tested with EJBAnnotationReaderWithClientTest)
Committed to R3_0_maintenance for 3.0.2
Verified with the M-3.0.2-20080906061108 build.
