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.

Bug 175932 - GF v3 is missing in new Web Project wizard after activation
Summary: GF v3 is missing in new Web Project wizard after activation
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Vince Kraemer
: 176005 176044 176534 (view as bug list)
Depends on:
Reported: 2009-11-02 13:13 UTC by Martin Schovanek
Modified: 2009-11-26 08:03 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

initial proposed patch (2.41 KB, text/plain)
2009-11-20 10:23 UTC, Vince Kraemer
FO based fix (5.14 KB, text/plain)
2009-11-21 11:04 UTC, Petr Hejl
yet another patch (6.10 KB, text/plain)
2009-11-22 11:38 UTC, Petr Hejl
stacktrace (6.29 KB, text/plain)
2009-11-23 06:17 UTC, Jaroslav Pospisil
simple solution (6.14 KB, text/plain)
2009-11-23 12:38 UTC, Petr Hejl
complicated solution (11.72 KB, text/plain)
2009-11-23 12:39 UTC, Petr Hejl
the thread dump with simple solution (38.83 KB, application/octet-stream)
2009-11-23 15:32 UTC, Vince Kraemer
the diff to apply to release68 (7.46 KB, text/plain)
2009-11-23 18:49 UTC, Vince Kraemer

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schovanek 2009-11-02 13:13:22 UTC
[#200910310201, jdk1.6]

to reproduce:
1) have installed Tomcat 6.0.20, Gf v2.1.1, GF v3 b70
2) start NB with fresh userdir
3) create a new Web Project
ERROR: the GF v3 server is missing at 'Server and Setting' panel

WORKAROUND: activate the J2EE Feature before you invoke the New Web Project wizard, eq: expand the Servers node.

Probably a ergonomics related issue.
Comment 1 Petr Jiricka 2009-11-03 11:18:27 UTC
I am able to reproduce using build 2009-11-03_02-22-15 (installed from the installer, Java download bundle, Mac OS X

Confirmed that this is ergonomics-related - after deleting the ergonomics cluster, the problem disappears. Reassigning.
Comment 2 Jaroslav Tulach 2009-11-03 13:59:04 UTC
GlassFish registration is flawed:
1. it runs premature registration of during startup: glassfish.common.Installer 
2. the Installer writes down(!) some files into config directory (why, can't this be done by installer?)
3. the Installer does not listen on changes in enabled modules

As a result when web project is created, nothing is written down into the config directory, until the system restarts. 
Flawed design, the registrations shall not be written down, but rather declared in the layer of some modules or 
written down by installer during installation.

Reassigning to glassfish to fix the design. Let me know if you need code and design review.
Comment 3 Vince Kraemer 2009-11-03 16:21:01 UTC
It looks like the init behavior of the gf common module was was radically changed in this commit... 
This issue appears to be fallout from that.
oh well.
Comment 4 Vince Kraemer 2009-11-03 18:00:09 UTC
I just confirmed that reverting the change to ide.ergonomics/ makes this issue go away...  oh well.
Comment 5 Vince Kraemer 2009-11-03 19:03:14 UTC
JTulach: I have some questions about your comments in

If the current registration is premature, when do you think a server plugin should register its 'default' server and not
trigger a regression of issue 173740?

It seems like you think the default server registration strategy that has been in place for many releases is flawed.  It
looks like you think the ide installer should initialize the various files that implement the server registries.  That
seems like a pretty big change at this point of the release cycle. Do you think we need new APIs to support that?

What is the API that will allow a module to listen for changes in the content of the set of activated module?
Comment 6 David Konecny 2009-11-03 22:52:16 UTC
If something is flawed then it is FoD!

Yarda, either fix this on your/FoD side or suggest some simple solution for GF side. For next release we could/should
consider moving registration to NetBeans Installer but right now we need a quick fix. I do not know what GF code does
but the fact it has worked prior FoD and there were no associated performance problems makes you look like you are just
FUD-ing. And FoD-ing. :-)
Comment 7 Vince Kraemer 2009-11-03 23:01:06 UTC
I remembered a similar issue, from back in the April time frame, that I was able to find and study. It was issue 162064.

Once I found it, finding the modification necessary to fix this issue became pretty simple.

Comment 8 Jaroslav Tulach 2009-11-04 07:56:23 UTC
For release 6.8 I indeed suggest to seek some easy fix. I was thinking the problem is in missing listener, but I was 
not sure where. Thanks for finding out that it was just missing folder definition in the base module.

For any future release I prefer change in the way installer and j2eeservers communicate. As far as I can tell, right 
now the installer sets a property in etc/netbeans.conf and various j2eeservers, when started, use this property and 
write something into $userdir/config/GlassFish, etc. This is flawed from performance point of view (the modules do 
some work on start, sooner then user needs to use them) as well as unnecessary complicated. I'd rather see the 
installer to create the file directly in nb6.9/config/GlassFish directory. I'll report this as separate issue when 6.8 
is over.
Comment 9 Jaroslav Pospisil 2009-11-04 14:12:25 UTC
*** Issue 176005 has been marked as a duplicate of this issue. ***
Comment 10 Quality Engineering 2009-11-04 22:28:55 UTC
Integrated into 'main-golden', will be available in build *200911041401* on (upload may still be in progress)
User: Vince Kraemer <>
Log: #175932: this hasn't been necessary in the past...
Comment 11 Jaroslav Pospisil 2009-11-18 05:13:42 UTC
Reproduced again in 200911171401,Win Vista,JDK 1.6.0_16,b72
Comment 12 Vince Kraemer 2009-11-18 08:57:29 UTC
any interesting or useful data in the IDE log file?
Comment 13 Vince Kraemer 2009-11-18 09:28:17 UTC
*** Bug 176534 has been marked as a duplicate of this bug. ***
Comment 14 Vince Kraemer 2009-11-18 09:35:35 UTC
cannot reproduce with 200911171401 on Mac OS X
Comment 15 Jaroslav Pospisil 2009-11-19 06:21:07 UTC
Well,I'm not able to reproduce it anymore in that or latest build,so maybe it was caused by some old data in my userdir.Closing as fixed and will reopen if appears again.
Comment 16 matusdekanek 2009-11-20 00:32:12 UTC
Unfortunately still valid on:

Product Version: NetBeans IDE Dev (Build 200911191401)
Java: 1.6.0_16; Java HotSpot(TM) Client VM 14.2-b01
System: Linux version 2.6.31-14-generic running on i386; UTF-8; en_US (nb)

Use the steps from bug 176534:
-start IDE with clean userdir
-open a java application (activates java se)
-open a java web application (activates java ee)
And there it is, the glassfish server is not available in the projects.
Comment 17 Vince Kraemer 2009-11-20 00:52:59 UTC
yup. the steps described in that issue make it easy to reproduce this issue...
Comment 18 Vince Kraemer 2009-11-20 10:23:19 UTC
Created attachment 91443 [details]
initial proposed patch

This patch resolves the InstanceCreationException that users run into if they follow the work-flow described in
Comment 19 Vince Kraemer 2009-11-20 13:52:47 UTC
What is going on prior to the patch integration....

Here is what is happening after each user action...

1. Start IDE
   the usual stuff.  It is a clean userdir. none of the modules (other than Base IDE) are initialized.

2. create a Java SE app or library
   The modules that implement the Java SE features initialize.  
i. The J2eeserver module is also initialized at this time. I am not exactly sure 'why' it initializes.This includes the ServerRegistry.  There are no modules that provide plugins, so the registry is empty... 0 handlers.

ii. The glassfish.common module is also initialized at this time.  That module initializes a lookup listener for the path 'Servers/GlassFish'.  The module also registers the default server with the 'common server' registry.

3. The user attempts to create a web app project.
   The modules that implement the web and Java EE features are activated.  This includes the glassfish.javaee module.  The gf.javaee module has an entry for Servers/GlassFish in its layer file.  

i. The listener associated with the lookup Servers/GlassFish fires in gf.common code and the two modules start to work together to synchronize the 'common server' registry (has an instance of glassfish) and the j2eeserver registry (needs to have an instance of glassfish), by calling InstanceProperties.createInstancePropertiesWithoutUI.  That code is in glassfish.javaee/.../ (method createModule).

ii. The createInstancePropertiesWithoutUI method, checks to see that the registry is initialized... (it is).

iii. Since the registry is initialized, the method reads through all the currently available deployment factory objects that are in the registry to see if a server should be handled by a plugin, by checking the deployer URL.  Note, there are no serversplugins registered at this point.

iv. at some point AFTER the call to createInstancePropertiesWithoutUI has failed, the listener associated with path /J2EE/DeploymentPlugins fires as each of the server plugins is detected by the FileChangeListener that is associated with that path.  The list of servers grows and later calls to createInstanceProperties and createInstancePropertiesWithoutUI will be successful.

This patch resolves the issue by delaying when the initialization of server registration is considered to be done...

With initialization delayed, the DeploymentFactory objects are found, by finding the children of J2EE/DeploymentPlugins (which is populated before the file listeners that are hung on J2EE/DeploymentPlugins have had a chance to fire)

Is there another way to get around this problem... YES.

While I was writing up this summary, I thought about the question 'how does the Tomcat and SJSAS plugin avoid this issue' and I found the answer...

Those two plugins register their 'default instance' by avoiding the InstanceProperties api completely.  You can see a sample of this by looking at: (see method registerServerInstanceFO) (see method registerDefaultDomain)

This avoidance tactic also appears to be used for the JBoss server, too... (see the method register)

So... it appears the root cause of this issue is in the ServerRegistry.

We can attempt to fix ServerRegistry now or I can use a similar hack to avoid using it (or actually avoid using InstanceProperties.createInstanceWithouUI.

My initial attempt at fixing server registry is about 9 lines changed.

The avoiding the call to createInstancePropertiesWithoutUI will require about 70 lines of code... most of which I can copy and adapt from InstanceProperties.  That code would be all 'in the plugin', but would be another hack that replicates code and is likely to fail in big ways if the ServerRegistry evolves.
Comment 20 Vince Kraemer 2009-11-20 15:26:12 UTC
did a bit more digging.

Creating an file object doesn't get me an InstanceProperties object.... and that is what we have to have/get at this point.
Comment 21 Vince Kraemer 2009-11-20 17:28:21 UTC
After being so deep in this issue, I kept asking myself...

Self, why doesn't tomcat exhibit the same behavior...  Since I did not know, I decided to try it out.

Here is what I did

1. build a very recent pull of web-main (without the patch)
2. used the following command to start the IDE

-J-Dorg.netbeans.modules.tomcat.autoregister.token=20091118082642 --userdir ~/nb68ud/tctestd

Note: tctestd was a new new userdir

3. immediately created a Java application project.  (don't do anything else)
4. waited for the activity level of my machine to drop back to its 'idle load'.  It took about 20 seconds on my machine.
5. attempted to create a Java Web App project.
  the wizard opens but when I get to page 3 (titled Server and Settings) the Server combo box is empty.

If I execute steps 1, 2 (with a different new userdir) and then 5, the Server combobox has an entry for Apache... the expected behavior.

Based on this result, I am going to transfer this issue to Serverplugins/infrastructure.
Comment 22 Petr Hejl 2009-11-21 03:21:48 UTC
Can't reproduce. I've tried at least 10 times. Works just fine for me with tomcat & recent build (couple of minutes ago). Both with and without wait in step 4. Are you sure you have no changes locally? Any further details?
Comment 23 Petr Hejl 2009-11-21 03:37:38 UTC
Regarding desc #19 I don't think the root cause is ServerRegistry. In steps 3i and 3iv there is now particular ordering of events in SFS, but the initialization of GF depends on such assumption.

The usage of FO for registration is not an avoidance it is just an API and creation of such FileObjects by installer is also solution jtulach would like to see in future imo.

If the ordering of your initialization is really the problem I would rather use the FO approach as 70 lines of code in serverplugin is better than 9 lines in infrastructure at this stage of development.

We can get rid of the code once installer will write such instance files...
Comment 24 Vince Kraemer 2009-11-21 08:48:05 UTC
Well.  After trying the create a FileObject directly hack, I can still replicate this issue for GF... so there must be something else I am missing.  I will keep looking.
Comment 25 Vince Kraemer 2009-11-21 08:51:12 UTC
PetrH: one quick question... do you still see an exception between step three and step 5?
Comment 26 Petr Hejl 2009-11-21 10:22:05 UTC
No I don't see any exception for Tomcat. I'll try with GF.
Comment 27 Petr Hejl 2009-11-21 10:26:28 UTC
I see an exception with GFv3 using steps in desc19.
Comment 28 Vince Kraemer 2009-11-21 10:41:31 UTC
I must have had some local change that was interfering with the TC initialization, because I just verified that I had no local changes and rebuilt.  I could not reproduce my earlier results.
Comment 29 Petr Hejl 2009-11-21 11:02:55 UTC
Something like this fixes issue with GF for me.
Comment 30 Petr Hejl 2009-11-21 11:04:05 UTC
Created attachment 91473 [details]
FO based fix
Comment 31 Petr Hejl 2009-11-21 11:08:00 UTC
This is just rough fix. I would need to ensure myself that change in addPlugin(FO) does not break anything.

I don't know whether returning null from JavaEEServerModuleFactory.createModule() has any significant effect. This happens during default instance initialization, perhaps initialization should be done outside of createModule(), not sure...

For steps in desc19 I don't see any exception and GF is available.
Comment 32 Vince Kraemer 2009-11-21 18:45:58 UTC
I have been experimenting with something similar to the fix you have proposed....

I think returning null from createModule is probably a bad thing.  I am just about to finish my check on that.
Comment 33 Petr Hejl 2009-11-22 11:38:53 UTC
Created attachment 91487 [details]
yet another patch

I think this could be a correct fix.
Comment 34 Vince Kraemer 2009-11-22 16:41:51 UTC
*** Bug 176044 has been marked as a duplicate of this bug. ***
Comment 35 Petr Hejl 2009-11-23 04:58:04 UTC
Fixed in web-main 90a4a1a6f396. Please verify.
Comment 36 Jaroslav Pospisil 2009-11-23 06:17:12 UTC
Created attachment 91530 [details]
Comment 37 Petr Hejl 2009-11-23 09:27:51 UTC
This code is required as well: web-main 4436d56d3233
Comment 38 Petr Hejl 2009-11-23 10:34:46 UTC
Working on a fix - there is still missing case :/
Comment 39 Vince Kraemer 2009-11-23 11:00:30 UTC

it looks like you will put a server into the j2eeserver registry, even if the domain did not get created successfully.

copy/paste errors -- "Cannot register the default Tomcat server"

I am still uncomfortable with the use of the FO strategy... especially when the reference to J2EE/InstalledServers is getting added to code that will execute in the Ruby IDE.

I have also noticed that the ServerRegistry usually has an invariant that there isn't an InstalledServer that doesn't have a corresponding DeploymentPlugin...
 see ServerRegistry.addInstanceImpl

This batch of patches seems to violate that constraint... though I have to admit that I do not have a patch that satisfies the following constraints:

1. only changes 'glassfish.*' code
2. doesn't violate the ServerRegistry invariant.
Comment 40 Petr Jiricka 2009-11-23 11:28:20 UTC
> I am still uncomfortable with the use of the FO strategy

So would you prefer to the the proper fix involving installer?
Comment 41 Petr Hejl 2009-11-23 11:43:56 UTC
Invariant is not broken.

There is still issue with server plugin initialized later than the call to addinstanceImpl in my patch.
Comment 42 Vince Kraemer 2009-11-23 12:32:57 UTC

Is there a j2eeserver API that we could use to determine when a plugin has finished being added to the ServerRegistry?
Comment 43 Petr Hejl 2009-11-23 12:37:32 UTC
I'll attach 2 patches. Both should solve plugin/instance ordering once forever.

The first is simple solution that will try to load all not-yet-loaded plugins when creating instance for which we don't have plugin available.

The second patch is more complicated and is trying to actively shorten the list of loaded plugins for such situation.

Both patches reverts my previous changes. In both patches when the execution order is plugin->instance new code is not called at all (so the execution path remains the same).

Vince feel free to apply the patch (I would go with the first one) and test it. I'll read emails till midnight (approx.) CET.
Comment 44 Petr Hejl 2009-11-23 12:38:38 UTC
Created attachment 91554 [details]
simple solution
Comment 45 Petr Hejl 2009-11-23 12:39:48 UTC
Created attachment 91555 [details]
complicated solution
Comment 46 Vince Kraemer 2009-11-23 13:24:45 UTC
re :

just saw these... will let you know before 10:00 pm CET...
Comment 47 Vince Kraemer 2009-11-23 14:07:25 UTC
simple solution was not effective in the 

start, create java app, create java web app case.

I ended up with a deep stack that had the v1 initialization in it... over and over again...
Comment 48 Vince Kraemer 2009-11-23 14:20:27 UTC
Petr: what are the specific issues that you have with the patch I proposed a couple days ago?
Comment 49 Petr Hejl 2009-11-23 14:32:28 UTC
Can you share that stacktrace? I tried start-java-web and start-web test cases and both worked ok with gfv3.

I was bit scared of initialization anytime somebody touches the registry. There is also a chance race condition again in case another plugin will jump in during the whole FoD stuff. But we can keep it as backup plan, although I would be more happy with code executing only for the broken case.
Comment 50 Vince Kraemer 2009-11-23 14:56:42 UTC
I had been trying some different code after I added the comment.

I am doing a clean rebuild to make sure there isn't cruft from those experiments

back in about 20 minutes
Comment 51 Vince Kraemer 2009-11-23 15:30:39 UTC
here is the status...

I did the start,web-app case against a clean userdir.  It appeared to be fine.

I then tried to do the start,java app, web app case against a different, clean userdir.

I get to the 'Activating Java Web and EE' page of the web app wizard and then the pulse starts but does not stop.  I should have said thread dump in my previous message.

After a few minutes, I trigger a thread dump, which I will attach.
Comment 52 Vince Kraemer 2009-11-23 15:32:00 UTC
Created attachment 91559 [details]
the thread dump with simple solution
Comment 53 Vince Kraemer 2009-11-23 15:34:05 UTC
The command-line that I am using...

nbbuild/netbeans/bin/netbeans -J-Dorg.glassfish.v3ee6.installRoot=/export/home/vkraemer/glassfishv3_b72 --userdir /export/home/vkraemer/nb68ud/nov23i -J-Dcom.sun.aas.installRoot=/export/home/vkraemer/glassfishv2.1.1
Comment 54 Petr Hejl 2009-11-23 15:59:38 UTC
Look like GFv2 plugin is writing instance in plugin init which in turn is trying to instantiate plugin etc.

I think it could be fixed by changing
addInstanceImpl(url, username, password, displayName, withoutUIFlag, null, true);
addInstanceImpl(url, username, password, displayName, withoutUIFlag, null, false);

I'm thinking about that. There are two methods how to register instance
1) writing FO to SFS
2) by calling InstanceProperties.create()

The first one is in fact asynchronous and depends on the time where the file gets noticed. The second is synchronous and instance is created directly. I think it is enough when only the second case will try to load the missing plugins.

Can you test/confirm that? The change in patch is true->false in mentioned method.
Comment 55 Petr Hejl 2009-11-23 16:03:28 UTC
I'm thinking about the case where somebody would call InstanceProperties.create from Server plugin initialization, but that would always cause InstanceCreationException even without the proposed change.
Comment 56 Vince Kraemer 2009-11-23 16:12:13 UTC
I was about to send you this message, but had hit a mid-air collision...

I made the following change to the 'simple solution' and cannot reproduce the situation that I hit with the thread dump...

in public void addInstance(FileObject fo), I changed 

addInstanceImpl(url, username, password, displayName, withoutUIFlag, null,true);


addInstanceImpl(url, username, password, displayName, withoutUIFlag, null,false);

So, I confirm your change as effective.

What should the next steps be and their order...

a. commit the 'revert' 
b. commit the new simple solution to web-main
c. get folks around here to try it from the hudson build of web-main
d. get additional testing from qa folks there tomorrow.
e. send out the integration request tomorrow, if testing on multiple platforms and systems seems to show that the change is effective...
Comment 57 Petr Hejl 2009-11-23 16:31:52 UTC
I agree. Vince can you do a & b? I'll ask Martin Schovanek to test it tomorrow morning.

BTW With false flag in addInstance(FO) I think it is more correct and less intrusive as new code is executed only when InstanceProperties.create... is called in situation when there is no plugin (yet).
Comment 58 Vince Kraemer 2009-11-23 16:34:25 UTC
will do.

currently running some tests from the TC, JBoss and other plugins
Comment 59 Vince Kraemer 2009-11-23 16:49:19 UTC
commit the revert:
commit modified 'simple solution':
Comment 60 Vince Kraemer 2009-11-23 18:06:57 UTC
I missed an intermediate diff in the back and forth with Petr.

I am getting it ready to integrate now.
Comment 61 Vince Kraemer 2009-11-23 18:35:28 UTC
commit the fully modified 'simple solution'...
Comment 62 Vince Kraemer 2009-11-23 18:49:55 UTC
Created attachment 91564 [details]
the diff to apply to release68
Comment 63 Vince Kraemer 2009-11-23 20:51:21 UTC
I could not reproduce the issue on Solaris with web-main and jdk 6 update 16.

I could not reproduce the issue on Mac OS X with web-main and jdk 6 update 15.

Prior to applying the changes to web-main, I had been able to reproduce the missing gfv3 combo box entry and the '0 handler' exception at will on both systems where I have been doing testing and development.
Comment 64 Vince Kraemer 2009-11-23 23:05:43 UTC
windows vista, jdk 6 update 16,

I could not reproduce the issue using the either of the test scenerios.
Comment 65 davisn 2009-11-23 23:48:58 UTC
I also try with windowXP 64bits and was not able to reproduce the problem. Was able to select gf v3 or v2.1 from the Server and Setting Panel
Build used:
jdk used:
Comment 66 Milan Kuchtiak 2009-11-24 03:07:38 UTC
The fix looks fine.
Comment 67 Martin Schovanek 2009-11-24 03:20:37 UTC
Verified by QE in web-main build. Please integrate into the release68 branch.
Comment 68 Petr Hejl 2009-11-24 04:37:03 UTC
Fixed in release68 c61e26142156.

Please verify.
Comment 69 Vince Kraemer 2009-11-24 17:02:06 UTC
added some test code for this: and
Comment 70 Quality Engineering 2009-11-24 19:04:20 UTC
Integrated into 'main-golden', will be available in build *200911241400* on (upload may still be in progress)
Log: #175932 GF v3 is missing in new Web Project wizard after activation
Comment 71 Martin Schovanek 2009-11-26 08:03:47 UTC
Verified at the release68.