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.
the fix for issue 162741 prevents new servers from being registered.
additional info... like stack traces is available in http://www.netbeans.org/issues/show_bug.cgi?id=162214#desc24
http://hg.netbeans.org/web-main/rev/ce740019ac3b
Integrated into 'main-golden', will be available in build *200905260201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ce740019ac3b User: vince kraemer <vkraemer@netbeans.org> Log: #165957: second half of fix for 162741...
Verified in trunk build #200905260201 ... Has to be verified in RC1 build
align with the HR 6.7 process
In reviewing this patch, I'm troubled by the inclusion of this line at this position in the GlassFishInstance constructor. This makes the instance publicly visible before it's fully constructed (which is completed by the updateModuleSupport() call). 2.8 + instanceProvider.addServerInstance(this); 2.9 updateModuleSupport(); On the other hand, putting the addServerInstance() call at the end of the constructor causes the failure this issue was filed for the in the first place. The real issue is that in the get*DeploymentManager() methods in glassfish.javaee module are calling getServerInstance() to find out if a particular URI is a registered server URI. This method exposes publicly available servers which is acceptable except in the case where the server URI in question is in the process of being registered (which is the case for this bug.). I propose an amendment to the attach patch to add new isRegisteredUri(String uri) api to the glassfish.common SPI that can be used find out if a particular URI is registered, or in process, rather than calling getServerInstance(). The portion of the original patch that pushes the addServerInstance() call to the GlassFishInstance constructor stays, but is moved to the last line of the constructor. Also a small temporary registry is introduced that tracks server URI's that are in the act of being registered. Patch to follow.
http://hg.netbeans.org/web-main/rev/0c3d55cd53f6 AND http://hg.netbeans.org/web-main/rev/57200c6a9ab6 Two commits because Vince found a hypothetical NPE in the finally clause after I pushed this.
The combined fix (my initial changes plus Peter's amendments) are good, codewise... I will have QA verify it in a build.
Integrated into 'main-golden', will be available in build *200905271401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/0c3d55cd53f6 User: pcw@netbeans.org Log: #165957 - augmented patch that resolves encapsulation loophole in original patch
Verified the fix with NetBeans-dev-web-main-709-on-090527-full build from (http://bertram.netbeans.org/hudson/job/web-main/lastSuccessfulBuild/) -Was able to register GlassFish v3 Prelude & V3 Enterprise -Created a web project and was able to select GlassFish v3 Prelude & V3 Enterprise in the server list -If Java EE Web features were deactivated, when create a new Java EE project the feature is re-activated and I was able to select a v3 server from the server list The problem is verified as fix
http://hg.netbeans.org/release67/rev/66c0024bc019
Verified in nb67rc1 build #200905282243
*** Issue 166228 has been marked as a duplicate of this issue. ***