glassfish
  1. glassfish
  2. GLASSFISH-436

Notification of incomplete application.xml

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      436

      Description

      Background:
      -----------
      With reference to
      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6359192
      and
      https://glassfish.dev.java.net/issues/show_bug.cgi?id=71

      Problem:
      --------
      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!

      Solution:
      ---------
      Either provide some option to restore the scanning behaviour (i.e. change the spec)
      OR
      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.

        Activity

        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Hide
        Hong Zhang added a comment -

        assign to myself

        Show
        Hong Zhang added a comment - assign to myself
        Hide
        Hong Zhang added a comment -

        will revisit this for v3/JavaEE 6.

        Show
        Hong Zhang added a comment - will revisit this for v3/JavaEE 6.
        Hide
        Bill Shannon added a comment -

        I guess the reason we didn't include a metadata-complete attribute in the
        application.xml file is that it didn't seem that useful. There's very little
        in the application.xml file that you would want to override. We assumed
        developers would choose one style or the other and work within that style.

        For example, to change the context root of a web application with no
        application.xml, simply rename the war file.

        You're right that the AVK and other tools should help by reporting any
        "unaccounted for" artifacts in the ear file. And a tool to produce an
        application.xml for a directory structure would also be useful.

        Still, there may be use cases where it would be helpful to be able to
        combine information in the application.xml with information discovered
        by looking at files. This is something we can consider for the next
        release.

        Bill Shannon
        Java EE 5 Spec Lead

        Show
        Bill Shannon added a comment - I guess the reason we didn't include a metadata-complete attribute in the application.xml file is that it didn't seem that useful. There's very little in the application.xml file that you would want to override. We assumed developers would choose one style or the other and work within that style. For example, to change the context root of a web application with no application.xml, simply rename the war file. You're right that the AVK and other tools should help by reporting any "unaccounted for" artifacts in the ear file. And a tool to produce an application.xml for a directory structure would also be useful. Still, there may be use cases where it would be helpful to be able to combine information in the application.xml with information discovered by looking at files. This is something we can consider for the next release. Bill Shannon Java EE 5 Spec Lead
        Hide
        stvconsultants added a comment -

        Well fair enough, maybe it's just, in my view, one piece of the spec that leaves
        a bad taste in your mouth.

        All the other deployment descriptors have a mechanism to say that they are the
        full deployment descriptor and ensure that the application server does not go
        and infer anything else. Why should application.xml be the special one that
        does not have this type of behaviour?

        Show
        stvconsultants added a comment - Well fair enough, maybe it's just, in my view, one piece of the spec that leaves a bad taste in your mouth. All the other deployment descriptors have a mechanism to say that they are the full deployment descriptor and ensure that the application server does not go and infer anything else. Why should application.xml be the special one that does not have this type of behaviour?
        Hide
        qouyang added a comment -

        I think all of your concerns should be addressed by tools, and not deployment
        process itself. If you want to know what's inside of an application after
        deployment, you could login to admin gui and see it on display. If you are
        given an ear file without any descriptors before deployment, I suppose you can
        also open it up in some gui tool so you can inspect it visually. I am not aware
        of any tools that does that now. But I'd recommand that you try it out with the
        NetBeans. If they don't do it, file a bug. :-P

        Show
        qouyang added a comment - I think all of your concerns should be addressed by tools, and not deployment process itself. If you want to know what's inside of an application after deployment, you could login to admin gui and see it on display. If you are given an ear file without any descriptors before deployment, I suppose you can also open it up in some gui tool so you can inspect it visually. I am not aware of any tools that does that now. But I'd recommand that you try it out with the NetBeans. If they don't do it, file a bug. :-P
        Hide
        stvconsultants added a comment -

        Actually, as I think about this more, it is more serious than I initially thought.

        The general theme for JavaEE5 is that the .xml files should become optional. We
        may not have an .xml descriptor in the ejb jars so how do I tell just by looking
        at them (without being a JavaEE developer) that they contain ejbs

        How do I tell that a .jar is an application client other than by opening up the
        manifest.

        I am beginning to think that scanning the ear for ejbs and application clients
        should be the default behaviour even when an application.xml file is provided
        and that the scanning should be turned off with a <exclude-unlisted-modules/>
        element much like the <exclude-unlisted-classes/> element from persistence.xml

        Show
        stvconsultants added a comment - Actually, as I think about this more, it is more serious than I initially thought. The general theme for JavaEE5 is that the .xml files should become optional. We may not have an .xml descriptor in the ejb jars so how do I tell just by looking at them (without being a JavaEE developer) that they contain ejbs How do I tell that a .jar is an application client other than by opening up the manifest. I am beginning to think that scanning the ear for ejbs and application clients should be the default behaviour even when an application.xml file is provided and that the scanning should be turned off with a <exclude-unlisted-modules/> element much like the <exclude-unlisted-classes/> element from persistence.xml

          People

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

            Dates

            • Created:
              Updated: