glassfish
  1. glassfish
  2. GLASSFISH-10775

JMSJCA application cannot access singleton objects created by JMSRA

    Details

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

      Operating System: All
      Platform: PC

      Description

      It appears that a deployed application using the JMSJCA RA cannot access
      singleton objects created by the JMSRA system RA.

      This can be seen if you deploy an application that uses JMSJCA to connect to an
      embedded MQ broker using MQ's direct mode client rather than the longstanding
      TCP mode client.

      If you do this, the application fails because it thinks that the embedded broker
      is not running. This is because the singleton class used for the two to connect
      is being loaded by different class loaders, leading to their being two instances
      of this singleton object.

      This is a regression from Glassfish 2.1.1, in which JMSJCA+direct mode works
      just fine.

      I have written a simple EJB application to demonstrate the issue.

      1. Deploy the attached JMSJCA resource adapter.

      Please deploy using --libraries
      $GLASSFISH/glassfish/lib/install/applications/jmsra/imqjmsra.jar,$GLASSFISH/glassfish/lib/install/applications/jmsra/imqbroker.jar
      where $GLASSFISH is the root of your glassfish installation (the top-level
      directory containing glassfish and mq)

      2. Deploy the attached EnterpriseApplicationJMSJCA-ejb.zip

      This is a Stateless session bean with one business method, doCase(int x). Call
      this with x=1 to execute the test case. It does this:
      Connection connection1 =
      enterpriseApplicationJMSJCAConnectionFactory.createConnection();
      Session session1 = connection1.createSession(false, Session.AUTO_ACKNOWLEDGE);

      MessageProducer messageProducer =
      session1.createProducer(enterpriseApplicationJMSJCAQueue);
      messageProducer.send(createJMSMessageForjmsTestQueue(session1, "Hello"));

      connection1.close();

      where the connection factory and destination are defined in sun-resources.xml

      3. Deploy the attached EnterpriseApplicationJMSJCA-war.zip

      This is a simple servlet which invokes the session bean.

      4. Start the embedded broker

      Make sure the JMSRA is has been lazily started by invoking "asadmin jms-ping"

      5. Run the test case

      To run the test case, install the RA and use Netbeans to deploy both
      applications (Netbeans should create the required resources).

      Then use a web browser to goto
      http://localhost:8080/EnterpriseApplicationJMSJCA-war/TestServlet?param=1

      Look at the server log. This will show the errors:

      WARNING: [I500]: Caught JVM Exception: java.lang.RuntimeException: Direct broker
      not initialized for this client runtime.
      WARNING: [C4003]: Error occurred on connection creation [mq://localhost/direct].

      • cause: javax.jms.JMSException: Direct broker not initialized for this client
        runtime.

      5. More information

      I believe the reason for this error is that I am getting duplicate classes
      com.sun.messaging.jmq.jmsclient.runtime.impl.ClientRuntimeImpl and
      com.sun.messaging.jmq.jmsclient.runtime.impl.ClientRuntime
      which mean I get duplicate copies of each class's singleton instance.

      These classes can be found in the following jars:

      $GLASSFISH/mq/lib/imq.jar
      $GLASSFISH/glassfish/lib/install/applications/jmsra/imqjmsra.jar

      (though I got the same error even if I removed the relevant classes from
      imqjmsra.jar and copied imq.jar into $GLASSFISH/glassfish/lib/install/applications)

      One instance is created when JMSRA is started and is loaded by EJBClassLoader.

      The other instance is created when the application is run, and is loaded by
      com.sun.enterprise.v3.server.AppLibClassLoaderServiceImpl$URLClassFinder

      6. Workaround attemts

      I had several attemots at working round this issue:

      6A: I left sun-jms-adapter deployed using the --libraries option and added the
      same jars to "classpath-suffix". This made no difference, the tests still failed
      with the duplicate class problem. (I did the same for classpath-prefix).

      6B: I then removed the --libraries option and repeated the test. Now the test
      failed with a class not found error: sun-jms-adapter could not find the MQ
      client classes, despite the jars being included in in the jars added by
      classpath-suffix.

      6C: If I simply add the jars to domains/domain1/lib everything passes fine.
      Obviously this is not a solution, but it shows how this is a classpath/class
      loader issue.

        Activity

        Hide
        Nigel Deakin added a comment -

        Created an attachment (id=3754)
        sun-jms-adapter.rar

        Show
        Nigel Deakin added a comment - Created an attachment (id=3754) sun-jms-adapter.rar
        Hide
        Nigel Deakin added a comment -

        Created an attachment (id=3755)
        EnterpriseApplicationJMSJCA-ejb.zip

        Show
        Nigel Deakin added a comment - Created an attachment (id=3755) EnterpriseApplicationJMSJCA-ejb.zip
        Hide
        Nigel Deakin added a comment -

        Created an attachment (id=3756)
        EnterpriseApplicationJMSJCA-war.zip

        Show
        Nigel Deakin added a comment - Created an attachment (id=3756) EnterpriseApplicationJMSJCA-war.zip
        Hide
        jthoennes added a comment -

        ...

        Show
        jthoennes added a comment - ...
        Hide
        Jagadish added a comment -

        After evaluating the issue by having discussions over email, we do not see an
        issue with GlassFish's connector classloading behavior.

        Following changes can be made in the resource-adapter so as to achieve the
        requirement of sharing same class across resource-adapters.

        1) Generate a library so that it can be shared across resource-adapters.
        2) Use Installed libraries support provided in V3.
        ie., deploy the .rar with --libraries support or
        via EXTENSION_LIST in MANIFEST.MF of .rar
        3) Use EXTENSION_LIST in MANIFEST.MF or jmsra to refer the the library that need
        to be shared.

        I have provided installed libraries support (EXTENSION_LIST) for system-resource
        adapters now ( issue 10861 ).

        Transferring to Nigel for further investigation.

        For a sample, refer the following tests under :
        https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/v3

        <ant dir="installed-libraries" target="all-ext"/>
        <ant dir="installed-libraries" target="all--libraries"/>
        <ant dir="installed-libraries-embedded" target="all"/>
        <ant dir="installed-libraries-embedded" target="all-ext"/>

        Refer :
        https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/README.txt
        for general instructions.

        Show
        Jagadish added a comment - After evaluating the issue by having discussions over email, we do not see an issue with GlassFish's connector classloading behavior. Following changes can be made in the resource-adapter so as to achieve the requirement of sharing same class across resource-adapters. 1) Generate a library so that it can be shared across resource-adapters. 2) Use Installed libraries support provided in V3. ie., deploy the .rar with --libraries support or via EXTENSION_LIST in MANIFEST.MF of .rar 3) Use EXTENSION_LIST in MANIFEST.MF or jmsra to refer the the library that need to be shared. I have provided installed libraries support (EXTENSION_LIST) for system-resource adapters now ( issue 10861 ). Transferring to Nigel for further investigation. For a sample, refer the following tests under : https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/v3 <ant dir="installed-libraries" target="all-ext"/> <ant dir="installed-libraries" target="all--libraries"/> <ant dir="installed-libraries-embedded" target="all"/> <ant dir="installed-libraries-embedded" target="all-ext"/> Refer : https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/README.txt for general instructions.
        Hide
        Nigel Deakin added a comment -

        Adding v3_exclude

        Show
        Nigel Deakin added a comment - Adding v3_exclude
        Hide
        kumara added a comment -

        Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
        issues submitted on v2.x release because they might not apply to v3.next release.

        Show
        kumara added a comment - Setting target release for unresolved issues submitted on v3 release to the next release. Not changing issues submitted on v2.x release because they might not apply to v3.next release.
        Hide
        Nigel Deakin added a comment -

        Setting keyword 3.1-exclude.

        Although this is a genuine issue, it doesn't need to be fixed for 3.1 because
        the use of JMSJCA with direct mode was never formally supported (though it would
        work with Glassfish 3 if it weren't for this issue), and since JMSJCA is in
        sustaining mode this can't be considered a priority.

        Show
        Nigel Deakin added a comment - Setting keyword 3.1-exclude. Although this is a genuine issue, it doesn't need to be fixed for 3.1 because the use of JMSJCA with direct mode was never formally supported (though it would work with Glassfish 3 if it weren't for this issue), and since JMSJCA is in sustaining mode this can't be considered a priority.
        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.

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: