1. glassfish
  2. GLASSFISH-436

Notification of incomplete application.xml


    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.0pe
    • Fix Version/s: not determined
    • Component/s: deployment
    • Labels:
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:


      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.


        No work has yet been logged on this issue.


          • Assignee:
            Hong Zhang
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: