glassfish
  1. glassfish
  2. GLASSFISH-18476

Deployment Fails If EclipseLink Cache Coordination Is Configured

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.1
    • Component/s: entity-persistence
    • Labels:
      None

      Description

      Glassfish 3.1.2 introduced early validation of JPA persistence units on DAS.
      For this reason DAS creates and entity manager during deployment which will fail with EclipseLink Cache Coordination configured because the required resources are missing on the DAS server.

      For JMSTopicTransportManager this would be the TopicConnectionFactory and Topic.
      For RMITransportManager this would be java system properties that I usually setup for each individual server instance and read in a session customizer to build the rmi url for the current server instance.

      Workaround:
      In both cases the problem can be worked around by checking whether the resources are available in a session customizer.
      Cache Coordination should be switched off if the resources, e.g. the TopicConnectionFactory is not available.

      public class JMSSessionCustomizerGF312 implements SessionCustomizer {

      @Override
      public void customize(Session session) throws Exception {
      session.getLog().write("############################## SESSION CUSTOMIZER ##############################");
      Server server = (Server) session;
      RemoteCommandManager commandMgr = (RemoteCommandManager) server
      .getCommandManager();
      JMSTopicTransportManager transportManager = (JMSTopicTransportManager) commandMgr
      .getTransportManager();
      String connectionFactoryName = transportManager.getTopicConnectionFactoryName();
      try

      { TopicConnectionFactory connectionFactory = (TopicConnectionFactory) new InitialContext().lookup(connectionFactoryName); }

      catch(Exception ex)

      { session.getLog().write("Lookup of TopicConnectionFactory \"" + connectionFactoryName + "\" failed."); server.setCommandManager(null); server.setShouldPropagateChanges(false); }

      session.getLog().flush();

      if (server.isConnected())

      { server.getCommandManager().initialize(); }

      else

      { server.login(); }

      }
      }

      I have uploaded an example that can be used to reproduce the problem and it does also include the workaround.

      To reproduce the problem configure the following in project.properties:
      eclipselink.transport.protocol=jms-el22

      To work around the problem configure the following in project.properties:
      eclipselink.transport.protocol=jms-gf312

        Activity

        Hide
        Mitesh Meswani added a comment -

        Not targeting for RI

        Show
        Mitesh Meswani added a comment - Not targeting for RI
        Hide
        Hong Zhang added a comment -

        Assign to Mitesh for evaluation as it's related to entity persistence.

        Show
        Hong Zhang added a comment - Assign to Mitesh for evaluation as it's related to entity persistence.
        Hide
        rgirsten added a comment -

        I have added a test case to the bug which allows to reproduce the problem. For sure the deployment should work if the resources required for cache coordination are available from the DAS instance. The deployment will fail if this resources are not available.

        Show
        rgirsten added a comment - I have added a test case to the bug which allows to reproduce the problem. For sure the deployment should work if the resources required for cache coordination are available from the DAS instance. The deployment will fail if this resources are not available.
        Hide
        ymajoros added a comment -

        FYI, we have working jms cache coordination on GF 3.1.2.2 and did nothing special for that to work. It worked in GF 3.1, too; we just upgraded.

        Show
        ymajoros added a comment - FYI, we have working jms cache coordination on GF 3.1.2.2 and did nothing special for that to work. It worked in GF 3.1, too; we just upgraded.

          People

          • Assignee:
            Mitesh Meswani
            Reporter:
            rgirsten
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: