I did a quick look at this.

Here is what I see (when the page opens blank [due to an NPE at 
org.netbeans.modules.j2ee.deployment.config.ConfigurationStorage.java
(line 132)...

Line 132 is a trivial NPE due to not checking for null.

Line 131 is where things are interesting:

        ModuleDeploymentSupport mds = (ModuleDeploymentSupport)
moduleMap.get(module.getUrl());


module is an instance of ProjectWebModule.
getUrl() returns "".
This return value is hard-coded last I checked.

Looks like Nam,Pavel and (maybe) I need to dig into this.

I tested an app with an ejb module (and saw the same issue/result).

See attached traces for more information.

If the steps above are followed verbatim, there is a NPE in the log in
ConfigBeanStorage during creation of the config editor (see Vince's
comment above.)

If the projects are closed and then reopened (possibly requiring a new
IDE session), and the user attempts to merely open sun-application.xml
directly, the NPE above is gone and either an ArrayStoreException or
an IllegalStateException are thrown during node manipulation while
creating the config editor.

Created attachment 18110 [details]
stack traces.

This is a bug in configBeanTopComponent.  I will fix it.  The arguemnt
to getNodes should be changed to the url where the j2eemodulecontainer
know the right value.

We are back to the confusion of J2eeModule.get/setUrl().  The javadoc
of setUrl(String) says the value should be "/" for stand-alone module
and "/moduleArchiveName" for child module.  So the API seems to
dictate that of a module should be either stand-alone or part of a
j2eeapp, not both nor reused in different j2ee app with different url
value.  I think that this restriction is not reasonable and not necessary.

However, due to time contraint, as part of resolution last time, we
agree that setUrl() would be ignored and getUrl should return a
non-null value of the default url value that the j2eemodule project
would use when building the archive.  The value will be ignored when
the module is stand-alone.

Based on this resolution, this bug should be fixed by web and ejb
project implemementation of J2eeModule.getUrl().  I will update the
API javadoc, fix getUrl in ProjectWebModule (Pavel, you are wellcomed
to volunteer).  Maybe Chris or Rajeshwar will do it in ejb project.

We've had many issues in this area, so please be extra careful!

The Servlet 2.4 specification clearly states in section SRV.4.4, in
the paragraph about Context Path, that:

"If this context is the "default" context rooted at the base of
the Web server's URL name space, this path will be an empty string.
Otherwise, if the context is not rooted at the root of the server's
name space, the path starts with a '/' character but does not end with
a '/' character."

This is the only correct behavior; any other semantics will lead to
problems in other parts of the IDE.

The cause are:
1. NPE due to EarProject has not implemented addModuleListener(): I have
implement the check for null in getNodes and do the addModule to add
the mds to
the moduleMap.  This improve tolerance, but EarProject still need to
make sure
events would be fired on module added/removed.  Implemantation of
J2eeModuleContainer.getModules() need to add module listener.  (Vince,
please
take care of this).

2. Other times, there are a ArrayStoreException in
ConfigBeanTopCOmponent.  I will fix the ArrayStoreException and make
sure ProjectWebModule.getUrl and EjbJarProvider.getUrl return the
expected url value: /<archive.name>

I guess for the development modules we are going to assume the url
relative to the root of the ear is going to the ModuleName.jar.
Otherwise, the application or caller of the J2eeModule provider would
need to use setURL. I am also not clear on how a module would know
whether it should return "/" as part of standalone deployment or
"/ModuleName.extension" if it part of the ear file. Seems like the
module implementation would just always return the name of the
distribution and j2ee server would handle the standalone deployment
scenario.

Petr,
Just clarification to address your concern.  J2eeModule.getUrl is
purely used for J2eeApp packaging and not related to a webapp context
path.

Ok, thanks!

Fixed in=38927.
Open separate issue 50133 to track j2eeapp complete implementation of
J2eeModuleContainer.getModules() and ModuleListener support.

v.