I created the JIRA issue: https://issues.apache.org/jira/browse/OPENJPA-758
On 30-okt-08, at 20:19, Kevin Sutter wrote:
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?
