Geronimo
  1. Geronimo
  2. GERONIMO-3316

warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-M6, 2.0-M7, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
    • Fix Version/s: 2.1.4, 2.2
    • Component/s: deployment
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      DeploymentContext.getCompleteManifestClassPath figures out the whole set of jars in an ear in a modules classpath. If somethings missing it throws an exception and prevents deployment. We need a switch to be more lenient, and we need to provide more info when there's a problem on which jar has the problem and how we found it.

      Thanks to David Harbige on the user list for pointing out that this is a big usability problem.

        Activity

        Hide
        David Jencks added a comment -

        Better messages, and report of all the problems at once, in rev 556119. Haven't decided how to do the warn/throw swtich yet.

        Show
        David Jencks added a comment - Better messages, and report of all the problems at once, in rev 556119. Haven't decided how to do the warn/throw swtich yet.
        Hide
        Donald Woods added a comment -

        Seems we need to revive work on this....
        First step, would be to turn the return; usage in the for loop of DeploymentContext.java into continue; so we can discover ALL of the manifest problems and report them as DeploymentExceptions, 2) allow for directories in the classpath instead of jars only, 3) add a plan option to allow for more lenient processing (which may be required for #2)

        Show
        Donald Woods added a comment - Seems we need to revive work on this.... First step, would be to turn the return; usage in the for loop of DeploymentContext.java into continue; so we can discover ALL of the manifest problems and report them as DeploymentExceptions, 2) allow for directories in the classpath instead of jars only, 3) add a plan option to allow for more lenient processing (which may be required for #2)
        Hide
        Jeff Lu added a comment -

        We need the manifest classpath to work as Donald described. It should allow directories other than jars and deployment shouldn't fail if there is an unresolvable jar. Can this be fixed soon?

        Show
        Jeff Lu added a comment - We need the manifest classpath to work as Donald described. It should allow directories other than jars and deployment shouldn't fail if there is an unresolvable jar. Can this be fixed soon?
        Hide
        David Jencks added a comment -

        I don't think there is any chance this will be fixed further in 2.0.x

        Show
        David Jencks added a comment - I don't think there is any chance this will be fixed further in 2.0.x
        Hide
        David Jencks added a comment -

        We should look at the spec a bit before allowing anything into the mfcp.... some parts of the spec are very specific about only jar files being allowed in certain places. I don't have a big problem relaxing this based on a flag, but would prefer that we keep the literal spec compliant behavior as the default.

        Show
        David Jencks added a comment - We should look at the spec a bit before allowing anything into the mfcp.... some parts of the spec are very specific about only jar files being allowed in certain places. I don't have a big problem relaxing this based on a flag, but would prefer that we keep the literal spec compliant behavior as the default.
        Hide
        Joe Bohn added a comment -

        Is there a JSR for mfcp behavior? I couldn't find one. I did take a look at the JAR Specification here: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html but I only see references to jars being included in the classpath and no mention of support for directory entries. A Sun tutorial also reinforces the jar only interpretation: http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html . Based on this I don't see anything that would support a directory only reference in the mfcp. Does anybody have any additional information?

        Show
        Joe Bohn added a comment - Is there a JSR for mfcp behavior? I couldn't find one. I did take a look at the JAR Specification here: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html but I only see references to jars being included in the classpath and no mention of support for directory entries. A Sun tutorial also reinforces the jar only interpretation: http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html . Based on this I don't see anything that would support a directory only reference in the mfcp. Does anybody have any additional information?
        Hide
        Joe Bohn added a comment -

        Can somebody (Jeff?) please clarify why support for a directory only specification rather than specific jars? Why can't you just use /lib and avoid having to code manifest classpath at all if it is a problem to specify each jar name?

        If it is directory support and other more lenient support is necessary (beyond listing all of the problems) ... can you please provide more details on what you would like to see? In addition to directory support there was another reference to permitting missing jars (presumably without error) and allowing the deployment to succeed. Are there other areas that you would like more lenient, non-spec compliant interpretation?

        If we do support this it will be via a command line param, -DXorg.apache.geronimo.deployment.LenientMFCP=true which I have on my local image rather than a plan addition ... now we have to figure out what that exactly means. Thanks.

        Show
        Joe Bohn added a comment - Can somebody (Jeff?) please clarify why support for a directory only specification rather than specific jars? Why can't you just use /lib and avoid having to code manifest classpath at all if it is a problem to specify each jar name? If it is directory support and other more lenient support is necessary (beyond listing all of the problems) ... can you please provide more details on what you would like to see? In addition to directory support there was another reference to permitting missing jars (presumably without error) and allowing the deployment to succeed. Are there other areas that you would like more lenient, non-spec compliant interpretation? If we do support this it will be via a command line param, -DXorg.apache.geronimo.deployment.LenientMFCP=true which I have on my local image rather than a plan addition ... now we have to figure out what that exactly means. Thanks.
        Hide
        Jeff Lu added a comment -

        Hi John,

        The main application jar is distributed to other apps that run outside of the Geronimo context rely on the directory references and jars in this mfcp. Some of the directory and jar references are only applied to those apps that operate independent of the Geronimo app server. Having a flag to permit the above exceptions for deployment should be suffice for our purpose.

        Thanks

        Show
        Jeff Lu added a comment - Hi John, The main application jar is distributed to other apps that run outside of the Geronimo context rely on the directory references and jars in this mfcp. Some of the directory and jar references are only applied to those apps that operate independent of the Geronimo app server. Having a flag to permit the above exceptions for deployment should be suffice for our purpose. Thanks
        Hide
        Joe Bohn added a comment -

        Based upon Jeff's response I understand the following:

        • An ear is being deployed into Geronimo
        • it contains a manifest with classpath entries primarily for use in other application servers
        • In that manifest classpath there are entries that include directory only references (again, primarily for other application server)
        • the desire is that Geronimo would:
        • Ignore errors for non-jar entries (ie. the directory entries) and deploy the application
        • It is not required that Geronimo to include jars in the classpath that are contained in the directory or other non-spec compliant content in the actual classpath.
        Show
        Joe Bohn added a comment - Based upon Jeff's response I understand the following: An ear is being deployed into Geronimo it contains a manifest with classpath entries primarily for use in other application servers In that manifest classpath there are entries that include directory only references (again, primarily for other application server) the desire is that Geronimo would: Ignore errors for non-jar entries (ie. the directory entries) and deploy the application It is not required that Geronimo to include jars in the classpath that are contained in the directory or other non-spec compliant content in the actual classpath.
        Hide
        Joe Bohn added a comment -

        I checked code into branches/2.1 rev. 713147 and trunk rev. 713156

        This will ignore directory reference in the manifest classpath and ignore jars specified that don't actually exist in the archive. An information message will be issues when exceptions to spec compliant behavior are made. This behavior is triggered if you specify the following prior to launching the server:

        JAVA_OPTS=-DXorg.apache.geronimo.deployment.LenientMFCP=true

        Show
        Joe Bohn added a comment - I checked code into branches/2.1 rev. 713147 and trunk rev. 713156 This will ignore directory reference in the manifest classpath and ignore jars specified that don't actually exist in the archive. An information message will be issues when exceptions to spec compliant behavior are made. This behavior is triggered if you specify the following prior to launching the server: JAVA_OPTS=-DXorg.apache.geronimo.deployment.LenientMFCP=true
        Hide
        Joe Bohn added a comment -

        Can one of the watchers (Jeff?) please verify the integrated fix addresses the issue and if so, close this JIRA (or at least comment back on the results of their test)?

        Show
        Joe Bohn added a comment - Can one of the watchers (Jeff?) please verify the integrated fix addresses the issue and if so, close this JIRA (or at least comment back on the results of their test)?
        Hide
        Jeff Lu added a comment -

        I will test it this week and let you know. Thank you.

        Show
        Jeff Lu added a comment - I will test it this week and let you know. Thank you.
        Hide
        Jeff Lu added a comment -

        This issue has be resolved by passing in -DXorg.apache.geronimo.deployment.LenientMFCP=true with the nightly build 2.1.4-SNAPSHOT

        Thank you Joe.

        Show
        Jeff Lu added a comment - This issue has be resolved by passing in -DXorg.apache.geronimo.deployment.LenientMFCP=true with the nightly build 2.1.4-SNAPSHOT Thank you Joe.

          People

          • Assignee:
            Joe Bohn
            Reporter:
            David Jencks
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development