Details

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

      Operating System: Mac OS X
      Platform: Macintosh

    • Issuezilla Id:
      10,496

      Description

      Glassfish v3 comes with compatibility feature: asadmin deploy --property compatibility=v2 foo.ear

      The problem: this feature is only available from the CLI. There should be global e.g. setting (in
      domain.xml) and accessible from the admin UI (EJB container node) to be set persistently. A local setting,
      e.g. in the deployment descriptor: sun-*.xml .

      Reason: a majority of GF v2 projects is using Hudson + Maven / Ant for deployment. Most of the projects,
      are not 100% Java EE compatible but can be deployed to GF v2 without any problems. The migration even
      of such projects should be as smooth, as possible.

        Activity

        Hide
        Hong Zhang added a comment -

        Taking the ownership of this. I will talk with Jerome to discuss the plan for this.

        Downgrading it to P2 as it only happens for applications which are packaging in
        an incompatible way defined by the spec.

        The reason we did this clean up in v3 is we want to encourage the compatible
        packaging by the spec.

        Show
        Hong Zhang added a comment - Taking the ownership of this. I will talk with Jerome to discuss the plan for this. Downgrading it to P2 as it only happens for applications which are packaging in an incompatible way defined by the spec. The reason we did this clean up in v3 is we want to encourage the compatible packaging by the spec.
        Hide
        abien added a comment -

        I understand your intention, but from customer perspective it causes a lot of trouble. I had to argue a lot
        why an application worked on v2, but not on v3.

        I would reverse the settings and provide a "JavaEE strict" mode, instead of setting the strict mode as
        default...

        Show
        abien added a comment - I understand your intention, but from customer perspective it causes a lot of trouble. I had to argue a lot why an application worked on v2, but not on v3. I would reverse the settings and provide a "JavaEE strict" mode, instead of setting the strict mode as default...
        Hide
        Hong Zhang added a comment -

        also adding bill and tim to the Cc

        Show
        Hong Zhang added a comment - also adding bill and tim to the Cc
        Hide
        vince kraemer added a comment -

        A reference to the sections of the spec that are being violated would be very helpful.

        Show
        vince kraemer added a comment - A reference to the sections of the spec that are being violated would be very helpful.
        Hide
        Tim Quinn added a comment -

        Read EE 8.3.x. Near the end of each container-specific section is a statement
        like this (this one is from the app client container section, EE 8.3.3):

        "Components in the application client container must not have access to the
        following classes and resources, unless such classes or resources are covered by
        one of the rules above.

        • Other classes or resources in the application package. For example, the appli-
        cation client should not have access to the classes in other application client jar
        files in the same ear file, nor should it have access to the classes in web appli-
        cations or ejb jar files in the same ear file. "

        The details vary among the different containers discussed in EE 8.3.x.

        Show
        Tim Quinn added a comment - Read EE 8.3.x. Near the end of each container-specific section is a statement like this (this one is from the app client container section, EE 8.3.3): "Components in the application client container must not have access to the following classes and resources, unless such classes or resources are covered by one of the rules above. • Other classes or resources in the application package. For example, the appli- cation client should not have access to the classes in other application client jar files in the same ear file, nor should it have access to the classes in web appli- cations or ejb jar files in the same ear file. " The details vary among the different containers discussed in EE 8.3.x.
        Hide
        ludo added a comment -

        Adam, are you talking about App Client apps or EAR apps?

        Can you add more info in the bug? Is is related to the class-path entry in the
        webapp manifest inside an ear file?
        http://www.netbeans.org/issues/show_bug.cgi?id=173195

        Show
        ludo added a comment - Adam, are you talking about App Client apps or EAR apps? Can you add more info in the bug? Is is related to the class-path entry in the webapp manifest inside an ear file? http://www.netbeans.org/issues/show_bug.cgi?id=173195
        Hide
        abien added a comment -

        Clearification:

        0. asadmin deploy --property compatibility=v2 foo.ear solved the problem
        1. It was an EAR-only deployment
        2. The app, as many others GF v2 apps were deployed in Java EE incompatible way - but worked perfectly
        in GF v2. Maven was used to build the archive the application. It ignored the class-path entries in
        manifest.mf

        The point is: it is hard to explain to the customers, why something worked with GF v2 but doesn't work
        with GF v3 any more. Suggestion: GF v3 should behave as v2, and be optionally more restrictive.

        Show
        abien added a comment - Clearification: 0. asadmin deploy --property compatibility=v2 foo.ear solved the problem 1. It was an EAR-only deployment 2. The app, as many others GF v2 apps were deployed in Java EE incompatible way - but worked perfectly in GF v2. Maven was used to build the archive the application. It ignored the class-path entries in manifest.mf The point is: it is hard to explain to the customers, why something worked with GF v2 but doesn't work with GF v3 any more. Suggestion: GF v3 should behave as v2, and be optionally more restrictive.
        Hide
        vince kraemer added a comment -

        OK. So these are Java EE 5 apps... right?

        Which part of the Java EE 5 spec were they violating?

        If they were not violating the Java EE 5 spec, then we may have another way to decide how we want to treat
        these apps, wrt to the compatibility flag...

        Java EE 6 apps should default to 'strict'. Java EE 5 and J2EE 1.4 apps should default to 'compatible'...

        Show
        vince kraemer added a comment - OK. So these are Java EE 5 apps... right? Which part of the Java EE 5 spec were they violating? If they were not violating the Java EE 5 spec, then we may have another way to decide how we want to treat these apps, wrt to the compatibility flag... Java EE 6 apps should default to 'strict'. Java EE 5 and J2EE 1.4 apps should default to 'compatible'...
        Hide
        Hong Zhang added a comment -

        I see. So it's a combination of NB/Maven which produces this type of ear packaging.

        This is what EE5 spec defined for the bundled libraries:

        Section 8.2.1 Bundled Libraries

        2. A .ear file may contain a directory that contains libraries packaged in JAR
        files. The library-directory element of the .ear file’s deployment descriptor
        contains the name of this directory. If a library-directory element isn’t spec-
        ified, or if the .ear file does not contain a deployment descriptor, the
        directory named lib is used. An empty library-directory element may be used to
        specify that there is no library directory.
        All files in this directory (but not subdirectories) with a .jar extension
        must be made available to all components packaged in the EAR file, including
        application clients. These libraries may reference other libraries, either bun-
        dled with the application or installed separately, using any of the techniques
        described herein.

        Show
        Hong Zhang added a comment - I see. So it's a combination of NB/Maven which produces this type of ear packaging. This is what EE5 spec defined for the bundled libraries: Section 8.2.1 Bundled Libraries 2. A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file’s deployment descriptor contains the name of this directory. If a library-directory element isn’t spec- ified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory. All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bun- dled with the application or installed separately, using any of the techniques described herein.
        Hide
        Bill Shannon added a comment -

        The app was non-portable. It depended on behavior that was not specified
        by the Java EE 5 spec, and was not specified by the GlassFish documentation,
        but which happened to work in earlier versions of GlassFish. This was not
        a "Java EE 5 app". At best it was a "GlassFish v2 app". If there's a way
        to know from the packaging of the app that it intends to depend on GlassFish
        v2 behavior, we could use that to control the compatibility mode.

        Really, this is a bug in GlassFish v2 that was fixed in GlassFish v3 to align
        with a more complete specification of this behavior in Java EE 6.

        Show
        Bill Shannon added a comment - The app was non-portable. It depended on behavior that was not specified by the Java EE 5 spec, and was not specified by the GlassFish documentation, but which happened to work in earlier versions of GlassFish. This was not a "Java EE 5 app". At best it was a "GlassFish v2 app". If there's a way to know from the packaging of the app that it intends to depend on GlassFish v2 behavior, we could use that to control the compatibility mode. Really, this is a bug in GlassFish v2 that was fixed in GlassFish v3 to align with a more complete specification of this behavior in Java EE 6.
        Hide
        vince kraemer added a comment -

        regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc10

        You seem to have ignored EE 8.2.1 (item 1), which is the way NetBeans configures
        modules in an ear to reference bundled libraries.

        regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc11

        there is plenty of evidence that an app might have deployed and run on v2...
        the doctype of any sun-*.xml files
        the doctype or version of any platform descriptors that are in the app
        the absence of any Java EE 6 apis

        You are right. This is a bug in our servers that appears to have been 'in
        place' way back in the SJSAS 8.x days. We need to clean up our act. I am not
        sure we want to force users to clean up their apps that are 'done' (not under
        active development)

        Show
        vince kraemer added a comment - regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc10 You seem to have ignored EE 8.2.1 (item 1), which is the way NetBeans configures modules in an ear to reference bundled libraries. regarding https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc11 there is plenty of evidence that an app might have deployed and run on v2... the doctype of any sun-*.xml files the doctype or version of any platform descriptors that are in the app the absence of any Java EE 6 apis You are right. This is a bug in our servers that appears to have been 'in place' way back in the SJSAS 8.x days. We need to clean up our act. I am not sure we want to force users to clean up their apps that are 'done' (not under active development)
        Hide
        Tim Quinn added a comment -

        Just a minor point of clarification... The "allow visibility to the top-level
        JARs" behavior, as I understand it, originated in Sun Java System App Server 8.x
        – long before the library-directory concept appeared in Java EE 5 – and was an
        implementation-specific way to accomplish essentially the same thing. As such
        it seems to have started as a "feature," evolved into an "artifact" in the
        GlassFish v2/Java EE 5 timeframe, and now seems to have graduated to "bug" status!

        The Java EE 5 spec language listed approved ways of constructing references to
        other JARs in the app but did not state that other ways of doing so were
        forbidden or needed some explicit mechanism to do so. Java EE 6 has added this
        restriction. (In each EE 8.3.x section is wording to this effect about
        visibility of "other" JARs:

        "Other classes or resources contained in the application package, and specified
        by an explicit use of an extension not defined by this specification."

        )

        The --property compatibility=v2 feature is such an explicit, platform-specific
        mechanism to which the spec refers. So would a possible addition to
        sun-application.xml.

        IMO checking the DTD or schema versions declared in descriptors does not meet
        the requirement in the EE 6 spec for an explicit extension provided by the app
        server implementation.

        Show
        Tim Quinn added a comment - Just a minor point of clarification... The "allow visibility to the top-level JARs" behavior, as I understand it, originated in Sun Java System App Server 8.x – long before the library-directory concept appeared in Java EE 5 – and was an implementation-specific way to accomplish essentially the same thing. As such it seems to have started as a "feature," evolved into an "artifact" in the GlassFish v2/Java EE 5 timeframe, and now seems to have graduated to "bug" status! The Java EE 5 spec language listed approved ways of constructing references to other JARs in the app but did not state that other ways of doing so were forbidden or needed some explicit mechanism to do so. Java EE 6 has added this restriction. (In each EE 8.3.x section is wording to this effect about visibility of "other" JARs: "Other classes or resources contained in the application package, and specified by an explicit use of an extension not defined by this specification." ) The --property compatibility=v2 feature is such an explicit, platform-specific mechanism to which the spec refers. So would a possible addition to sun-application.xml. IMO checking the DTD or schema versions declared in descriptors does not meet the requirement in the EE 6 spec for an explicit extension provided by the app server implementation.
        Hide
        vince kraemer added a comment -

        re: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc13

        a little bit of further clarification... as far as I know, the 'standard'
        NetBeans EAR project (based on ANT) has never leveraged 'The "allow visibility
        to the top-level JARs" behavior' and has used the spec prescribed method (EE
        8.2.1 (number 1) [in the Java EE 6 spec] of referencing other jars since that
        method first appeared in the J2EE 1.4 spec...

        Show
        vince kraemer added a comment - re: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496#desc13 a little bit of further clarification... as far as I know, the 'standard' NetBeans EAR project (based on ANT) has never leveraged 'The "allow visibility to the top-level JARs" behavior' and has used the spec prescribed method (EE 8.2.1 (number 1) [in the Java EE 6 spec] of referencing other jars since that method first appeared in the J2EE 1.4 spec...
        Hide
        Hong Zhang added a comment -

        Right, from the further information provided by the user, the NB (ant) is doing
        the right packaging (item 1 of Section 8.2.1). The user case was NB (maven).

        Show
        Hong Zhang added a comment - Right, from the further information provided by the user, the NB (ant) is doing the right packaging (item 1 of Section 8.2.1). The user case was NB (maven).
        Hide
        Hong Zhang added a comment -

        I have checked in the changes to add a compatibility element in the
        sun-application.xml. This will provide a way for autodeploy/JSR88 to set the
        compatibility flag to have v2 jar visibility behavior. I will keep the issue
        open but downgrade to P3 for further enhancements on providing useful warning
        messages for the cases where we could detect such packaging.

        Show
        Hong Zhang added a comment - I have checked in the changes to add a compatibility element in the sun-application.xml. This will provide a way for autodeploy/JSR88 to set the compatibility flag to have v2 jar visibility behavior. I will keep the issue open but downgrade to P3 for further enhancements on providing useful warning messages for the cases where we could detect such packaging.
        Hide
        Hong Zhang added a comment -

        One more request that's related to this property came from this forum thread:
        http://forums.java.net/jive/post!reply.jspa?messageID=375716

        Seems in v2, we also added module root level jars to the classpath, we should
        probably also provide this jar visibility through the property in v3.1

        Show
        Hong Zhang added a comment - One more request that's related to this property came from this forum thread: http://forums.java.net/jive/post!reply.jspa?messageID=375716 Seems in v2, we also added module root level jars to the classpath, we should probably also provide this jar visibility through the property in v3.1
        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
        erpomata added a comment -

        Any new about this issue?

        Show
        erpomata added a comment - Any new about this issue?

          People

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

            Dates

            • Created:
              Updated: