glassfish
  1. glassfish
  2. GLASSFISH-5224

ACC wants to find connector classes in classpath

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 9.1peur1
    • Fix Version/s: 9.1.1_dev
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5,224
    • Status Whiteboard:
      Hide

      911Approved

      Show
      911Approved

      Description

      The ACC wants to find connector classes in the classpath, what it a showstopper
      for us. We are an ISV and ship one EAR that shall run on all applications
      servers, so there should be no vendor specific work arounds in the EAR. But
      without such a workaround (which btw bloats up the Client.jar by far and makes
      performance of ACC startup a mess) our correct EAR will not run on GlassFish.
      Since GlassFish is the RI for Java EE 5, we want to please Sun Microsystems to
      provide a fix ASAP, since currently the RI just proofs that it does not behave
      like the spec wants it to be.

      See this thread:
      https://glassfish.dev.java.net/servlets/ReadMsg?listName=users&msgNo=19483

      Especially see this answer:
      https://glassfish.dev.java.net/servlets/ReadMsg?list=users&msgNo=19556

      With the workaround (putting the RA's implementation into the client.jar) the
      ACC needs so long to start up (due to the lots of additional classes) that it
      makes really no more fun to work with.

      To express how severe this problem is for us, we have marked it as P1.

      We understand that Sun Microsystems cannot provide a real fix in short term, but
      we expect that there is a real solution that makes the workaround obsolete to be
      published FAR BEFORE GlassFishv3.

      We want to distribute GlassFish (and service contracts from Sun Microsystems) to
      our enterprise customers, but we cannot do that as long as the product is not
      behaving according to the spec.

        Activity

        Hide
        Hong Zhang added a comment -

        Tim has already started to look into this.

        Show
        Hong Zhang added a comment - Tim has already started to look into this.
        Hide
        harpreet added a comment -

        Approved for v2.1

        Show
        harpreet added a comment - Approved for v2.1
        Hide
        Tim Quinn added a comment -

        I have checked in the changes and additions shown below. I am doing some
        follow-up testing to ensure that the fix fully resolves the problem.

        Fixes checked in

        appserv-commons/src/java/com/sun/enterprise/deployment/archivist/GeneratedAppClientJarArchivist.java
        appserv-commons/src/java/com/sun/enterprise/deployment/util/ApplicationValidatorACC.java
        appserv-core/src/java/com/sun/enterprise/appclient/AppClientInfoFactory.java

        Fix for 5224 - ACC wants to find connector classes in classpath
        Because the generated app client JAR is packaged very much like an EAR and
        because the ACC used the normal archivist classes to open it, the open would
        trigger validation of the "EAR" including validation of any bundled EJB module
        (which is packaged with the app client for historical reasons of backward
        compabitility). If an EJB happens to rely on a resource adapter submodule that
        is part of the same real EAR on the server, the client-side validation would
        fail because bundled resource adapters are not packaged in the generated app
        client JAR file. This would prevent the app client container from opening the
        client JAR, preventing the client from running. This check-in provides an
        alternative archivist for use only by the ACC to open the generated app client
        JAR, and a special-purpose validator to skip the EJB validation.
        Tests: QL PE and EE; CTS smoke tests
        Approved: Harpreet

        Show
        Tim Quinn added a comment - I have checked in the changes and additions shown below. I am doing some follow-up testing to ensure that the fix fully resolves the problem. Fixes checked in appserv-commons/src/java/com/sun/enterprise/deployment/archivist/GeneratedAppClientJarArchivist.java appserv-commons/src/java/com/sun/enterprise/deployment/util/ApplicationValidatorACC.java appserv-core/src/java/com/sun/enterprise/appclient/AppClientInfoFactory.java Fix for 5224 - ACC wants to find connector classes in classpath Because the generated app client JAR is packaged very much like an EAR and because the ACC used the normal archivist classes to open it, the open would trigger validation of the "EAR" including validation of any bundled EJB module (which is packaged with the app client for historical reasons of backward compabitility). If an EJB happens to rely on a resource adapter submodule that is part of the same real EAR on the server, the client-side validation would fail because bundled resource adapters are not packaged in the generated app client JAR file. This would prevent the app client container from opening the client JAR, preventing the client from running. This check-in provides an alternative archivist for use only by the ACC to open the generated app client JAR, and a special-purpose validator to skip the EJB validation. Tests: QL PE and EE; CTS smoke tests Approved: Harpreet

          People

          • Assignee:
            Tim Quinn
            Reporter:
            mkarg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: