With reference to
I know that the spec for deployment says:
The deployment tool must first read the Java EE application deployment
descriptor from the application .ear file (META-INF/application.xml). If the
deployment descriptor is present, it fully specifies the modules included in the
application. If no deployment descriptor is present, the deployment tool uses
the following rules to determine the modules included in the application.
And that therefore one should either include a fully specified application.xml
or not include an application.xml file at all.
This is not exactly friendly deployment behaviour. Take the example of having an
enterprise application with no application.xml and I want to change the context
root of one web application. Now I have to figure out all the modules and
resource connectors, etc that the application server has been inferring for me.
This may not be the worlds biggest problem, since it should be just a case of:
adding references for all the root level rars and wars; adding the lib directory
if present; and, oh, figuring out whether the jars are application clients, ejb
modules or just plain fluff to be ignored...
Now consider that the .ear is one that I've been given to maintain, I'm no
JavaEE expert, but the users want the web context over-ridden, so I open up the
.ear to add an application.xml.
How is the non-developer to know which .jars are app clients, which .jars are
ejbs and which .jars are fluff!
Either provide some option to restore the scanning behaviour (i.e. change the spec)
Provide warning on deployment that there appear to be ejb modules and app-client
modules which are not defined in application.xml
I can see that we don't want the spec to be changed such that scanning always
happens since somebody may want to (for example) disable the application client
jar without un-packaging it. But some sort of <infer-other-modules/> element
added to the application.xml schema would be good.