This sounds like a bug, no? If the application is specifying user-written ValueHandlers, then doesn't OpenJPA have to use an appropriate classloader to find these application-level classes? I thought we ran into a similar situation with other user-written plugin values. Or, maybe I'm just dreaming... In any case, should a JIRA be opened for this situation?
Kevin On Thu, Oct 30, 2008 at 1:12 PM, Michael Dick <[EMAIL PROTECTED]>wrote: > Hi Jan, > > I believe installing OpenJPA as a third part persistence provider will > resolve the problem. Third party persistence providers may be loaded by the > application's classloader so the custom value handlers should be found. > > You can find the documentation on installing a third party persistence > provider at [1]. Hopefully it has sufficient information to get you > started. > If not we can try to help. > > WRT to the long term change you mentioned, I agree that we can handle it > better. As a bare minimum we could try the current thread's classloader or > the entity's classloader if we can't find the class on the property's > classloader. > > [1] > > http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ejbfep.multiplatform.doc/info/ae/ae/tejb_jpa3rdparty.html > > Regards > -mike > > > On Thu, Oct 30, 2008 at 10:53 AM, Jan Dockx <[EMAIL PROTECTED]> wrote: > > > 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. But since this is a long term > > solution, we also ask for pointers on how to work around the issuefor for > > our current WebSphere problem. > > > > > > > > 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. > > > > In the short term: how can we kick WebSphere 6.1.0.19 in a mode > (settings? > > deploy as shared lib? some init code?) where the current OpenJPA > > implementation in there will find our ValueHandler class? > > > > > > >
