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 <[EMAIL PROTECTED]> 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 <[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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
>
--
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.
