Sorry, with the latest bits, I can't reproduce.
Looking at the stack trace, it's hard to understand how it could happen unless there is a threading bug, as
DatabaseNodeInfo calls add with a new node array instantiated with a node that it checked to see was not null. But when
Children.java hits it, the node is null.
I am suspecting this is related to your other issues with managing connections which have appeared to have gone away
with the latest bits. I will close with WORKSFORME, and please re-open if you see it again.

I am hitting this issue again in build 770 from deadlock. For me, the steps to reproduce are:
1. Create a new web project
2. From the first panel of the wizard, choose Add server (I used the zip build so there are no servers to start with)
3. Add GlassFish v2 using the Add Server wizard
4. On finishing the wizard and returning back to the new web project wizard, I got the exception, see new stack trace in
the attachment.

I am noticing that these issues seem to arise when using J2EE/Visualweb functionality. So I am suspicious that I am not
seeing this because I am running with the 'basic' configuration. Building with the 'standard' cluster configuration
and will see if I can reproduce.
Meanwhile while the build's going on I'll look at the code and see if I can determine the cause through inspection.

Unable to reproduce on startup with clean userdir and a fresh build from main. Am downloading Glassfish V2 to see if I
can reproduce that way.
mmirolivic, can you please give me the following information:
- which build are you using - standard build, basic build, full build or something else?
- which VM are you using? I can't tell if "Java HotSpot(TM) Client VM, 10.0-b19" which VM this is - Java 5 or Java 6
Thanks.

Further inspection of the stack trace is uncovering the cause to me - it happens when registering Java DB that is
discovered in JDK 6 or when Glassfish is registered.
I'll install JDK 6 and see if I can reproduce that way.

Further inspection of the stack trace is uncovering the cause to me - it happens when registering Java DB that is
discovered in JDK 6 or when Glassfish is registered.
I'll install JDK 6 and see if I can reproduce that way.

David,
> mmirolivic, can you please give me the following information:
> - which build are you using - standard build, basic build, full build or something else?
as you can see in my original report, I am using Java SE distribution
> - which VM are you using? I can't tell if "Java HotSpot(TM) Client VM, 10.0-b19" which VM this is - Java 5 or Java 6
jdk 1.6.0_04

Update: this is a Heisenbug. Due to a threading conflict that I have yet to unravel, the Java DB node gets added twice,
and this causes subsequent corruptions in the node hierarchy that results in the NPE.
Stepping through in the debugger and/or adding log statements that print out stack traces to track down what threads are
participating in the problem makes the behavior go away.
Now attempting to track down without the use of log statements or the debugger. Are we having fun yet?

I can't argue about the correctness of the changes because the threading model of DatabaseNodeChildren was already
incomprehensible. To quote a comment at the end of the file, which is about five years old, "this entire class is junk".
It should have been thrown away a long time ago, and it is quite dissapointing that someone still has to struggle
maintaining it.
That being said, David's changes do seem to improve the current state, so I agree with them. Unfortunately, I don't
think they are the correct fix, which would be to "have a sensible data model independent of nodes and display it using
Children.Keys [...] and everything would be much easier" (to quote from the class again). However, that fix would
require heavy changes to the DB Explorer, changes that have always been unpopular. Again, it is quite demotivating (to
me at least) to see how we focus on better database support without addressing the infrastructure issues first.
A nitpick (not intended to block the integration into the beta branch): synchronization is not needed on getProperty()
and getBooleanProperty() in MySQLOptions. Similarly, it is not needed on ServerNodeProvider.getNodes().

Just few hints (probably not necessary for beta).
- Is there real need for usage of three different loggers in single class (DatabaseNodeChildren.java)?
- No need to synchronize static MySQLOptions.getDefault()
- MySQLOptions listeners are not thread safe, use CopyOnWriteArrayList
- Some unit test case should be prepared to avoid future regressions
- It is always good idea to document which lock is used for the field being synchronized

Thanks for your comments, your suggested changes are very useful; I have made the changes and will push into main (not
beta branch).
Petr, regarding your comment on unit tests, I am well aware of this. I had to set this aside as I had features that I
wanted to get in for beta. Unit tests are my main task for the beta period (aside from fixing P1s/P2s).
David