glassfish
  1. glassfish
  2. GLASSFISH-18649

Bad metadata in eclipselink causing failure during loading of HermesParser

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b33
    • Fix Version/s: None
    • Component/s: entity-persistence
    • Labels:
      None

      Description

      org.eclipse.persistence.core.jpql.jar is a fragment to org.eclipse.persistence.core.jar. At runtime, the host tries to load a
      class called org.eclipse.persistence.internal.jpa.jpql.HermesParser which is part of the fragment, so if the fragment is not attached, it fails. The relevant code that does this loading is:

      org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.java:
      protected JPAQueryBuilder buildDefaultQueryBuilder()
      {
      String queryBuilderClassName = (String)getProperty("eclipselink.jpql.parser");
      if (queryBuilderClassName == null)

      { queryBuilderClassName = "org.eclipse.persistence.internal.jpa.jpql.HermesParser"; }

      ...

      Mitesh tells me that "org.eclipse.persistence.queries.ANTLRQueryBuilder" is the traditional query builder. Use of this Antlr based query builder does not suffer from this problem, because the class is part of the host bundle itself. So, I am suggesting the following patch to in our codebase until EclipseLink fixes their metadata.

      — a/appserver/persistence/jpa-container/src/main/java/org/glassfish/persistence/jpa/PersistenceUnitLoader.java
      +++ b/appserver/persistence/jpa-container/src/main/java/org/glassfish/persistence/jpa/PersistenceUnitLoader.java
      @@ -451,6 +451,9 @@ public class PersistenceUnitLoader {
      final String TOPLINK_SERVER_PLATFORM_CLASS_NAME_PROPERTY = "toplink.target-server"; // NOI18N
      props.put(TOPLINK_SERVER_PLATFORM_CLASS_NAME_PROPERTY,
      System.getProperty(TOPLINK_SERVER_PLATFORM_CLASS_NAME_PROPERTY, "SunAS9")); // NOI18N
      + // Eclipselink module metadata is not correctly setup to load HermesParser, so we set it to
      + // ANTLRQueryBuilder which is part of the core.jar.
      + props.put("eclipselink.jpql.parser", "org.eclipse.persistence.queries.ANTLRQueryBuilder"); // NOI18N

      // Hibernate specific properties:
      final String HIBERNATE_TRANSACTION_MANAGER_LOOKUP_CLASS_PROPERTY = "hibernate.transaction.manager_lookup_class"; // NOI18N

        Activity

        Hide
        Mitesh Meswani added a comment -

        Assigning to Mat to remove the workaround after EclipseLink fixes the issue on their side.

        Show
        Mitesh Meswani added a comment - Assigning to Mat to remove the workaround after EclipseLink fixes the issue on their side.
        Hide
        Sanjeeb Sahoo added a comment -

        I have applied the suggested workaround in following svn revision:
        r53595 | ss141213 | 2012-04-21 04:49:18 +0530 (Sat, 21 Apr 2012) | 3 lines

        GLASSFISH-18649: Bad metadata in eclipselink causing failure during loading of HermesParser.
        Switching to Antlr based query builder as a workaround until eclipselink is fixed.

        Remove it when we upgrade to a version of eclipselink that does not have this problem. It will be good to have a bug created in eclipselink JIRA and reference the same here.

        Show
        Sanjeeb Sahoo added a comment - I have applied the suggested workaround in following svn revision: r53595 | ss141213 | 2012-04-21 04:49:18 +0530 (Sat, 21 Apr 2012) | 3 lines GLASSFISH-18649 : Bad metadata in eclipselink causing failure during loading of HermesParser. Switching to Antlr based query builder as a workaround until eclipselink is fixed. Remove it when we upgrade to a version of eclipselink that does not have this problem. It will be good to have a bug created in eclipselink JIRA and reference the same here.
        Hide
        tware added a comment -

        The core issue has been resolved in the latest EclipseLink nightlies.

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=377641

        Show
        tware added a comment - The core issue has been resolved in the latest EclipseLink nightlies. https://bugs.eclipse.org/bugs/show_bug.cgi?id=377641
        Hide
        Sanjeeb Sahoo added a comment -

        To make sure that the new eclipselink indeed works with our new provisioning system, one can run QL in this mode by following this additional step before executing QL:

        cd .../glassfish3/glassfish/; sed -i s/glassfish.osgi.ondemand=false/glassfish.osgi.ondemand=true/g config/osgi.properties

        Pl. do this before removing the workaround from our code.

        Show
        Sanjeeb Sahoo added a comment - To make sure that the new eclipselink indeed works with our new provisioning system, one can run QL in this mode by following this additional step before executing QL: cd .../glassfish3/glassfish/; sed -i s/glassfish.osgi.ondemand=false/glassfish.osgi.ondemand=true/g config/osgi.properties Pl. do this before removing the workaround from our code.
        Hide
        Mitesh Meswani added a comment -

        Fix checked in - rev 54236

        Show
        Mitesh Meswani added a comment - Fix checked in - rev 54236

          People

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

            Dates

            • Created:
              Updated:
              Resolved: