Oookaaaaay ... if you say so :-)
Next question: which version of OpenJPA do you suggest we use then?
1.0.3, like what is in WS 6.1 + feature pack now? Or 1.2? Which
version is used in WAS 7?
My reasoning: if there is no reason not to go to the latest release,
use the latest release (1.2.0). Any reasons why not?
On 31-okt-08, at 14:56, Kevin Sutter wrote:
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?
