openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: ValueHandlers on WebSphere 6.1
Date Thu, 30 Oct 2008 19:19:44 GMT
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 <michael.d.dick@gmail.com>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 <jandockx@gmail.com> 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?
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message