You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Jan Dockx <ja...@gmail.com> on 2008/10/30 16:53:51 UTC
ValueHandlers on WebSphere 6.1
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?
Re: ValueHandlers on WebSphere 6.1
Posted by Kevin Sutter <kw...@gmail.com>.
Olivier,
Thanks for the additional information. Can you refresh me on your execution
environment? I know you are using WAS 6.1.0.19, but are you using the EJB3
Feature Pack? Or, are you just trying to use OpenJPA as a "utility
library"? If the latter, are you installing it as a shared library? Or,
packaged as part of the application? Also, are you using the 1.2.x branch
(WAS v7) or the 1.0.x branch (WAS v6.1 EJB3 FeP)?
Thanks,
Kevin
On Wed, Nov 12, 2008 at 4:33 AM, Olivier Sinnaeve <
oliviersinnaeve@java-developer.be> wrote:
>
> Hoi,
>
> I'm a colleague of Jan and tested all the suggested methods.
> The thing is that openJPA executes a piece of code
>
> Class c = JavaTypes.classForName(name, val,
> (ClassLoader) AccessController.doPrivileged(
> J2DoPrivHelper.getClassLoaderAction(FieldStrategy.class)));
>
> and the getClassLoaderAction executes the following
>
> public static final PrivilegedAction getClassLoaderAction(final Class
> clazz)
> {
> return new PrivilegedAction() {
> public Object run() {
> return clazz.getClassLoader();
> }
> };
> }
>
> and the classloader of the FieldStrategy class returns
>
> "org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader"
>
> this is not the classloader we expect. Even if set PARENT_LAST or we
> provide
> the openJpa version our self we still recieve the eclipse classloader.
>
> Regards,
>
> Olivier
>
>
>
>
> Kevin Sutter wrote:
> >
> > 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 <ja...@gmail.com> wrote:
> >
> >> 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 <ja...@gmail.com> 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 <ja...@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?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> >
> >
>
> --
> 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.
>
>
Re: ValueHandlers on WebSphere 6.1
Posted by Olivier Sinnaeve <ol...@java-developer.be>.
Hoi,
I'm a colleague of Jan and tested all the suggested methods.
The thing is that openJPA executes a piece of code
Class c = JavaTypes.classForName(name, val,
(ClassLoader) AccessController.doPrivileged(
J2DoPrivHelper.getClassLoaderAction(FieldStrategy.class)));
and the getClassLoaderAction executes the following
public static final PrivilegedAction getClassLoaderAction(final Class clazz)
{
return new PrivilegedAction() {
public Object run() {
return clazz.getClassLoader();
}
};
}
and the classloader of the FieldStrategy class returns
"org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader"
this is not the classloader we expect. Even if set PARENT_LAST or we provide
the openJpa version our self we still recieve the eclipse classloader.
Regards,
Olivier
Kevin Sutter wrote:
>
> 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 <ja...@gmail.com> wrote:
>
>> 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 <ja...@gmail.com> 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 <ja...@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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
>
--
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.
Re: ValueHandlers on WebSphere 6.1
Posted by Kevin Sutter <kw...@gmail.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 <ja...@gmail.com> wrote:
> 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 <ja...@gmail.com> 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 <ja...@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?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: ValueHandlers on WebSphere 6.1
Posted by Jan Dockx <ja...@gmail.com>.
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 <ja...@gmail.com> 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 <ja...@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?
>>>>
>>>>
>>>>
>>>>
>>
Re: ValueHandlers on WebSphere 6.1
Posted by Kevin Sutter <kw...@gmail.com>.
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 <ja...@gmail.com> 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 <ja...@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?
>>>
>>>
>>>
>>>
>
Re: ValueHandlers on WebSphere 6.1
Posted by Jan Dockx <ja...@gmail.com>.
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 <ja...@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?
>>
>>
>>
Re: ValueHandlers on WebSphere 6.1
Posted by Jan Dockx <ja...@gmail.com>.
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 <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 <ja...@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?
>>>
>>>
>>>
>>
Re: ValueHandlers on WebSphere 6.1
Posted by Kevin Sutter <kw...@gmail.com>.
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 <mi...@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 <ja...@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?
> >
> >
> >
>
Re: ValueHandlers on WebSphere 6.1
Posted by Michael Dick <mi...@gmail.com>.
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 <ja...@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?
>
>
>