[ https://issues.apache.org/jira/browse/OPENJPA-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650305#action_12650305 ]
Kevin Sutter commented on OPENJPA-758: -------------------------------------- Hi, Just to ensure that I have discovered the same situation that you experienced, could you validate the following? During my recent experimentation with ValueHandlers and FieldStrategies [1], I came across the situation that you describe in this JIRA. The classloading in question is in the namedHandler method on the MappingRepository class: name = Configurations.getClassName(name); try { Class c = JavaTypes.classForName(name, val, (ClassLoader) AccessController.doPrivileged( J2DoPrivHelper.getClassLoaderAction(ValueHandler.class))); I agree that a user-supplied class, such as a ValueHandler, should not depend on the classloader of the ValueHandler class. But, I wanted to verify that we're talking about the same area of the code. Thanks, Kevin [1] http://n2.nabble.com/ValueHandlers-vs-FieldStrategies-td1573427.html > OpenJPA doesn't find ValueHandlers with an applicable class loader > ------------------------------------------------------------------ > > Key: OPENJPA-758 > URL: https://issues.apache.org/jira/browse/OPENJPA-758 > Project: OpenJPA > Issue Type: Improvement > Affects Versions: 1.0.3 > Environment: WebSphere 6.1, any other, 1.0.3 and probably all > existing others > Reporter: Jan Dockx > Priority: Blocker > Original Estimate: 72h > Remaining Estimate: 72h > > We are working with ValueHandlers for enterprise applications that > will be deployed on WebSphere, currently 6.1.0.19. We believe that the > current OpenJPA implementation has made a less than stellar choice in > how to load value handlers, and suggest a change > ValueHandlers are naturally (or so we find) specific for certain value > types, that are often dependent on the semantics of your business, and > thus are part of the application, in some way bundled in the ear you > are deploying. We do unit testing out of the container with OpenJPA > 1.0.3, and everything works like a charm. > When we deploy on WebSphere however, nothing works. OpenJPA does not > find our value handlers. > Luckily OpenJPA is open source :-), so we found with certainty that > the reason is that OpenJPA tries to load the value handler with the > class loader that loaded the meta information for the property. The > class of that object is part of OpenJPA, and inside WebSphere, OpenJPA > is loaded with a class loader that has no access to the application > code, the code in the ear. So, ClassNotFoundException. Bummer. > The long term solution, we believe, is not to use the classloader > associated with the meta information for the property (i.e., the > OpenJPA class loader), but instead the class loader of the entity for > which we are working (which is also reachable via the parameters of > the method that does the loading). Using the class loader of the > actual value we want to handle is not an option, since the value can > be null. The entity however is normally also part of the application, > the ear, and cannot be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.