It's called "classloader magic"... :-) Seriously, if you follow the InfoCenter instructions posted by Mike, this third party persistence provider shared library will be accessed before the corresponding provider that we ship. When using a replacement version of OpenJPA, this gets a little more complicated in v6.1 since you need to modify the classloader order. In v7, WebSphere has a new feature called "isolated shared libraries" which makes the configuration and usage a bit simplified.
Kevin On Thu, Oct 30, 2008 at 6:17 PM, Jan Dockx <[EMAIL PROTECTED]> wrote: > Hello mike. Thanks for the response. > > Your suggestion sounds like a path to investigate. Quick question though: > how will WebSphere know to inject an EntityManager of the "third party > persistence provider", instead of its own, where it finds > @PersistenceContext? > > > > On 30-okt-08, at 19:12, Michael Dick 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? >>> >>> >>> >>> >
