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? > > >
