This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Create a Web Project for GF v3 server and exit IDE. In project's private.properties remove j2ee.server.home and j2ee.server.instance and make sure that project's project.properties contains non-empty j2ee.platform.classpath. If I start IDE I'm experiencing following incorrect behaviour: two missing properties from private.properties are correctly added but j2ee.platform.classpath value in project.properties is change to be empty. Restart IDE second time and j2ee.platform.classpath is updated to have correct value. It looks like invalid value in j2ee.server.home and j2ee.server.instance during IDE start results in removal of value from j2ee.platform.classpath. Product Version = NetBeans IDE Dev (Build 100726-3807de0e15c5) (#3807de0e15c5) Operating System = Linux version 2.6.32-24-generic running on i386 Java; VM; Vendor = 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_20-b02 Java Home = /usr/lib/jvm/java-6-sun-1.6.0.20/jre
Created attachment 101153 [details] stack trace Here is explanation (see attached stack trace for more details): during the IDE startup WebProject's open hook calls WebProjectProperties.setServerInstance() which ends up calling GlassFish implementation of J2eePlatformImpl to return its libraries (Hk2JavaEEPlatformImpl.getLibraries). Based on the returned libraries the project's classpath is updated. The problem is that GlassFish library is created empty and later updated on background with some real classpath/javadoc content. And coincidentally that's after WebProject was opened and updated. This can be fixed at several layers - GF, server API, WebProject. What do you think is the right place? I'm passing to Petr as he represents middle layer and might now if it is GF's fault or project's fault.
Vince, Petr, I forgot to add you to CC. Please read my previous comment of this issue which is addressed to you.
Hmm. I think there is an event that either... a) isn't being listened for (probably a bug in the project's module) b) the event is not getting propagated from the plugin back to the project's module (a bug in the plugin) I will double check the plugin for firing the event to all listeners.
I did a quick check in 6.9 and was not able to reproduce the problem... though I will admit that my steps to reproduce were a bit different... I created multiple web and java ee projects that target v3 in 6.9. (web, appclient, ejb module and ent app) I exited out of the IDE. I used vi to delete the two lines from the private.properties of projects I restarted the IDE I WAITED FOR THE 'Scanning Projects' step to finish I looked at the j2ee.cplatform.classpath... none of them were blank...
release 6.9 was branched on May 18, 2010. The last 'real' change in JavaEEServerModuleFactory.java was on April 29, 2010.
I followed similar steps with a dev build and Tomcat as the target server. I was able to replicate the results that David originally described initially. I suspect that there is some change in the j2eeserver layer (or below) as the root cause of this problem.
(In reply to comment #6) > I followed similar steps with a dev build and Tomcat as the target server. > > I was able to replicate the results that David originally described initially. > > I suspect that there is some change in the j2eeserver layer (or below) as the > root cause of this problem. It is good to know it is reproducible for you as well on dev builds. PetrH was changing the code little bit while implementing WL Server Libraries support. But because this issue depends on timing it is likely that perfectly legitimate call is executed but timing wise it is too early and no listener is attached to learn about library cp update - and that sounds like web project's problem.
I did some more tests with the dev build and discovered that all the java ee and web project types (that are ant based) have a similar problem to the dev/web combination.
*** Bug 189211 has been marked as a duplicate of this bug. ***
Investigating.
So far it is not reproducible for me. Looks like timing issue which gets better observable in dev.
I Can still reproduce the Bug 189211 in the latest dev build.
*** Bug 189688 has been marked as a duplicate of this bug. ***
Petr, I was also able to reproduce it always. See also issue 189688 which I think is result of this problem.
Also quite easily reproducible -> P2.
Created attachment 102030 [details] Hacky patch that fixes some aspects of this I was debugging this problem in the scenario when I: 1. Open an existing project originally developed for GlassFish 2. Resolve missing server to WebLogic Developer Web Profile There are two problems: - when J2EEProjectProperties.setServerProperties() method is called, the call to extractPlatformLibrariesRoot() returns null, which means that the properties will be incorrectly written to private properties. This is because the platform classpath returned by WebLogic contains some entries that are not under the server root (they are under the "middleware home", but not under the wlserver directory), so there is no way to relativize these. - inside J2EEProjectProperties.setLocalServerProperties(), to determine the platform classpath, method Util.getJ2eePlatformClasspathEntries() is called. This method determines the platform target server, however at this point the previous broken server (GlassFish) is still returned, rather than the new server that I chose in the Resolve missing server dialog. I am attaching a patch that hacks around these problems, but probably is not quite correct. Petr and David, could you please look at it?
I'm testing the correct fix right now.
Fixed in web-main ed4be3a2825b.
The fix seems to be addressing issue reported by Petr but not the original problem I opened this issue with, no?
Moreover, the fix does not address the WebLogic aspect - I am still getting j2ee.platform.classpath in private.properties, as some of the classpath entries are not under j2ee.server.home. Reopening.
The original issue is fixed. (In reply to comment #20) > Moreover, the fix does not address the WebLogic aspect - I am still getting > j2ee.platform.classpath in private.properties, as some of the classpath entries > are not under j2ee.server.home. Reopening. This is different issue (mentioned in comment 16 for the first time). I don't know whether it is by design or not - only first platform root is taken into account in the improvement David implemented in this area (j2ee.server.home). And the behavior is the fallback for case when there is no common root for the server classpath.
(In reply to comment #20) > Moreover, the fix does not address the WebLogic aspect - I am still getting > j2ee.platform.classpath in private.properties, as some of the classpath entries > are not under j2ee.server.home. Reopening. I'm not sure what can be done with some paths not being relative - the solution implemented was very simple (without an API contract): as most of the server jars are under server installation directory then let's store server installation directory and use relative paths to access jars. For WL this is not true as some of the jars are outside of server installation directory. Perhaps an API contract might be necessary to give a chance to WL to make paths relative?
Sorry, I did not intend to change the issue state.
See issue 190387.
Integrated into 'main-golden', will be available in build *201009170000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ed4be3a2825b User: Petr Hejl <phejl@netbeans.org> Log: #189141 j2ee.platform.classpath is empty