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.
Product Version: NetBeans IDE 6.7 RC1 (Build 200905232021) Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02 System: Windows XP version 5.1 running on x86; Cp1251; ru_RU (nb) full installation, ergonomics disabled - open New Project Wizard - select Java Web -> Web Application - click Next twice - on Server and Settings step expend Server combobox there are only Tomcat and GFv2 in list
This needs to be at least evaluated for NB 6.7
Tried on linux (debian sid amd64) and cannot reproduce. Everything functional. I'll try on msft system.
reproduced for me on WinXP and Ubuntu 8.10 with clean userdir GFv3 become available after expanding Servers node in Services window
Reproduced. Easy workaround but very confusing for users marking as stopper. Upgrading to P1
please attach the IDE log file...
don't need the IDE log... I am able to reproduce the issue...
http://hg.netbeans.org/web-main/rev/82c82488e410
Fix reviewed.
Integrated into 'main-golden', will be available in build *200905270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/82c82488e410 User: vince kraemer <vkraemer@netbeans.org> Log: #166017: instances list and default server are not initialized if the server node is not accessed.
verified with NetBeans IDE Dev (Build 200905270201)
the 'fix' triggered issue 166073, so I am back at the drawing board.
same fix strategy. moved into a location where the glassfish.javaee module is not going to be triggering manipulations of the j2eeserver rregistry (which is the cause for the deadlock in issue 166073). http://hg.netbeans.org/web-main/rev/eb1aac61ec52
Sounds like the whole way these things are registered and found needs to be rethought - ModuleInstall.restored() is not a good place for this sort of thing, although as an emergency workaround it may be necessary for now. Consider lookup registration or files somewhere in the SFS. I don't see why a registry of anything should require that much locking; if it really does, consider providing *only* a callback interface to receive the collection of instances, so you control the thread the registry lookup runs on (and therefore what locks are held - i.e. you make deadlocking on it impossible).
Fixed verified with procedure and build below NetBeans-dev-web-main-709-on-090527-full build from (http://bertram.netbeans.org/hudson/job/web-main/lastSuccessfulBuild/) -Added and Registered GlassFish v3 Prelude & V3 Enterprise -Created a web project -> select GlassFish v3 Prelude or V3 Enterprise in the server list
http://hg.netbeans.org/release67/rev/01402266d151
Integrated into 'main-golden', will be available in build *200905280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/eb1aac61ec52 User: vince kraemer <vkraemer@netbeans.org> Log: #166017: initialize the glassfish registry (and the default domain) before the downstream modules start to initialize.
Verified in 6.7rc1 build #200905282243