OpenJPA
  1. OpenJPA
  2. OPENJPA-2229

Persistence entities not recognized when deploying on JBoss AS 7.1

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0, 2.2.1, 2.3.0
    • Fix Version/s: 2.3.0
    • Component/s: kernel
    • Labels:
      None
    • Environment:
      JBoss AS 7.1.1-Final
    • Patch Info:
      Patch Available

      Description

      I've found this guide [1] about using OenJPA 2.2.0 and JBoss 7.1: I had some minor issues (already reported on that page) easily solved, but then I came to this exception, thrown at every JPA query:

      <openjpa-2.2.0-r422266:1244990 nonfatal user error> org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter "SELECT e FROM ExternalResource e". Error message: The name "ExternalResource" is not a recognized entity or identifier. Perhaps you meant ExternalResource, which is a close match. Known entity names: [ExternalResource, AbstractSchema, RAttrUniqueValue, AbstractVirAttr, Membership, TaskExec, SyncopeConf, Report, RAttr, AbstractExec, SyncopeLogger, USchema, MAttr, PasswordPolicy, RSchema, MSchema, MAttrValue, MAttrUniqueValue, AbstractAttr, AbstractDerSchema, AbstractVirSchema, UAttr, AccountPolicy, RAttrValue, UAttrValue, ReportExec, SyncopeUser, Notification, ConnInstance, AbstractDerAttr, AbstractAttrValue, SyncopeRole, SyncPolicy, Policy, ReportletConfInstance, Task, UAttrUniqueValue, Entitlement, SchemaMapping, UserRequest]
      at org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:194) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:167) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:242) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:212) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:205) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:80) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2417) [openjpa-kernel-2.2.0.jar:2.2.0]
      at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:61) [openjpa-kernel-2.2.0.jar:2.2.0]

      After some deeper investigation, I've found that the problem resides in the vfs: JBoss URLs, currently not managed.

      [1] https://community.jboss.org/thread/201329

      1. jboss-vfs.patch
        3 kB
        Francesco Chicchiriccò

        Issue Links

          Activity

          Hide
          Francesco Chicchiriccò added a comment -

          This patch makes AbstractCFMetaDataFactory handle vfs: URLs.

          Since the JBoss library for managing such URLs is LGPL, I've preferred to implement these calls using Java reflections in order to avoid pushing any additional dependency.

          I've tested this patch by deploying Apache Syncope on JBoss AS 7.1.1.Final and found no issues.

          Show
          Francesco Chicchiriccò added a comment - This patch makes AbstractCFMetaDataFactory handle vfs: URLs. Since the JBoss library for managing such URLs is LGPL, I've preferred to implement these calls using Java reflections in order to avoid pushing any additional dependency. I've tested this patch by deploying Apache Syncope on JBoss AS 7.1.1.Final and found no issues.
          Hide
          Rick Curtis added a comment -

          Francesco -

          Your patch looks pretty good... I think a few small modifications will be required, but I should be able to handle those. I'll try to get around to committing this patch to trunk late today or early tomorrow.

          Thanks,
          Rick

          Show
          Rick Curtis added a comment - Francesco - Your patch looks pretty good... I think a few small modifications will be required, but I should be able to handle those. I'll try to get around to committing this patch to trunk late today or early tomorrow. Thanks, Rick
          Hide
          Francesco Chicchiriccò added a comment -

          Hi Rick,
          this sounds very nice!

          Once you'll apply the patch and commit, will the updated Maven artifacts be published immediately? I'd love to be able to have it with 2.2.1-SNAPSHOT

          Thanks.

          Show
          Francesco Chicchiriccò added a comment - Hi Rick, this sounds very nice! Once you'll apply the patch and commit, will the updated Maven artifacts be published immediately? I'd love to be able to have it with 2.2.1-SNAPSHOT Thanks.
          Hide
          Mark Struberg added a comment -

          Hi!

          This is only ONE of n known problems with URL.

          The problem is most times that URL.toExternalForm() and new URL() are not commutative. There is a long thread over at commons for classpath scanning. The problem with the JBoss VFS is a well known issue not only for JPA but other frameworks. There is not only vfs:// but e.g. wsjar:// and tons of other possible URLs. You can read more about this in this thread:
          http://apache-commons.680414.n4.nabble.com/classscan-new-URL-xxx-and-it-s-problems-td4634723.html#a4634734

          The only way to solve this right is a plugable archive mechanism like proposed and implemented by David Blevins in xbean-finder.

          Show
          Mark Struberg added a comment - Hi! This is only ONE of n known problems with URL. The problem is most times that URL.toExternalForm() and new URL() are not commutative. There is a long thread over at commons for classpath scanning. The problem with the JBoss VFS is a well known issue not only for JPA but other frameworks. There is not only vfs:// but e.g. wsjar:// and tons of other possible URLs. You can read more about this in this thread: http://apache-commons.680414.n4.nabble.com/classscan-new-URL-xxx-and-it-s-problems-td4634723.html#a4634734 The only way to solve this right is a plugable archive mechanism like proposed and implemented by David Blevins in xbean-finder.
          Hide
          Francesco Chicchiriccò added a comment -

          Mark,
          for the (little) extent of my knowledge of OpenJPA internals, I agree with you: the attached patch is definitely not the ending solution for URL handling issues; anyway, it could be a temporary fix that allows to cover some more use cases.
          This, of course, to be refactored as soon as the new URL scanning mechanism will be in place.
          WDYT?

          Show
          Francesco Chicchiriccò added a comment - Mark, for the (little) extent of my knowledge of OpenJPA internals, I agree with you: the attached patch is definitely not the ending solution for URL handling issues; anyway, it could be a temporary fix that allows to cover some more use cases. This, of course, to be refactored as soon as the new URL scanning mechanism will be in place. WDYT?
          Hide
          Mark Struberg added a comment -

          perfectly fine. I just wanted to raise the awareness that this might hit us in other situations as well. Not only with other url prefixes, but also in other locations in the OpenJPA codebase. It would be perfect if we can move this to a common helper class somehow.

          Show
          Mark Struberg added a comment - perfectly fine. I just wanted to raise the awareness that this might hit us in other situations as well. Not only with other url prefixes, but also in other locations in the OpenJPA codebase. It would be perfect if we can move this to a common helper class somehow.
          Hide
          Rick Curtis added a comment -

          Francesco -

          Since I have zero JBoss experience I committed your patch some some minor modifications to trunk without new tests. Please verify the patch works as expected when you get a chance.

          > It would be perfect if we can move this to a common helper class somehow.
          Agreed, but I don't see that happening until someone really screams and ponies up some cycles.

          Show
          Rick Curtis added a comment - Francesco - Since I have zero JBoss experience I committed your patch some some minor modifications to trunk without new tests. Please verify the patch works as expected when you get a chance. > It would be perfect if we can move this to a common helper class somehow. Agreed, but I don't see that happening until someone really screams and ponies up some cycles.
          Hide
          Francesco Chicchiriccò added a comment -

          Hi Rick,
          I've taken a look at the code modification on trunk: did not think to that AccessController.doPrivileged()!

          I made my patch against 2.2.x branch because my application (Apache Syncope) is based on 2.2.0: I've tried to quickly test Syncope on JBoss with 2.3.0-SNAPSHOT artifacts (after a fresh 'mvn clean install' from updated OpenJPA trunk source tree), unfortunately with no luck.

          Then I backported the AbstractCFMetaDataFactory class from trunk to branch 2.2.x, did another 'mvn clean install', then switch Syncope POMs to 2.2.1-SNAPSHOT: it worked.

          Baseline: the applied patch is working, but I am not (currently) able to test it with trunk (2.3.0-SNAPSHOT).

          Show
          Francesco Chicchiriccò added a comment - Hi Rick, I've taken a look at the code modification on trunk: did not think to that AccessController.doPrivileged()! I made my patch against 2.2.x branch because my application (Apache Syncope) is based on 2.2.0: I've tried to quickly test Syncope on JBoss with 2.3.0-SNAPSHOT artifacts (after a fresh 'mvn clean install' from updated OpenJPA trunk source tree), unfortunately with no luck. Then I backported the AbstractCFMetaDataFactory class from trunk to branch 2.2.x, did another 'mvn clean install', then switch Syncope POMs to 2.2.1-SNAPSHOT: it worked. Baseline: the applied patch is working, but I am not (currently) able to test it with trunk (2.3.0-SNAPSHOT).
          Hide
          Rick Curtis added a comment -

          Committed revision 1361564 to trunk.

          Show
          Rick Curtis added a comment - Committed revision 1361564 to trunk.
          Hide
          Heath Thomann added a comment -

          HI! Please note that part of this fix (Revision 1369042) was incorrectly listed under JIRA OPENJPA-2229.....the commit was meant for JIRA OPENJPA-2247.

          Thanks,

          Heath

          Show
          Heath Thomann added a comment - HI! Please note that part of this fix (Revision 1369042) was incorrectly listed under JIRA OPENJPA-2229 .....the commit was meant for JIRA OPENJPA-2247 . Thanks, Heath

            People

            • Assignee:
              Rick Curtis
              Reporter:
              Francesco Chicchiriccò
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development