cation, 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?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/ValueHandlers-on-WebSphere-6.1-tp1399186p1489134.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
s. 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
>
--
View this message in context:
http://n2.nabble.com/ValueHandlers-on-WebSphere-6.1-tp1399186p1489134.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
I would recommend using the 1.2.x branch of OpenJPA that corresponds with
the WebSphere v7 release. There are several improvements especially in the
area of performance.
On Fri, Oct 31, 2008 at 9:53 AM, Jan Dockx <[EMAIL PROTECTED]> wrote:
> Oookay ... if you say so :-)
>
> Next question: wh
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 applicat
Oookay ... 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
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 c
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, Mic
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
dreami
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
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 sol
10 matches
Mail list logo
