openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Dockx <jando...@gmail.com>
Subject Re: ValueHandlers on WebSphere 6.1
Date Fri, 31 Oct 2008 15:09:45 GMT
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 <jandockx@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?
>>>
>>>
>>>
>>


Mime
View raw message