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?
