openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
Date Thu, 29 Nov 2007 18:05:37 GMT

On Nov 29, 2007, at 9:45 AM, Kevin Sutter wrote:

> Marc and Mike,
> I don't agree with the Mike's patch and I don't agree with the Marc's
> backing-out of the original fix.
> Mike's original change went into the 1.0.x service stream as well as
> 1.1.0trunk.  The JIRA Issue and dev mailing list discussions attempted
> to
> determine if there was a problem with the proposed classloader  
> ordering.
> Since all of our existing tests passed (both with OpenJPA and  
> WebSphere),
> Mike went ahead with the changes.
> Now, if we just back out Mike's change without resolving it, then we  
> have a
> disconnect between the 1.0.x service stream and the 1.1.0 trunk.  Any
> customers currently using the 1.0.x version of OpenJPA may be  
> surprised when
> they move to 1.1.0 and their use of the MappingTool no longer  
> works.  Thus,
> we can't just revert Mike's change without a solution to both  
> problems.

Note that I didn't back out Mike's change ... I merely re-ordered the  
multiple class loaders that he put in place. This is why I asked to  
see if the problem still existed after my change.

> Mike attempted to resolve this problem via the option to turn on/off  
> the
> temporary class loader.  Although this makes it more consistent with  
> the
> PCEnhancer usage of the TemporaryClassLoader, it still introduces a
> release-to-release usage incompatibility.
> Granted, there may be cases where we have to introduce  
> incompatibilities,
> but I don't believe this is one of them.  We need to figure out  
> what's the
> problem with the usage of this TemporaryClassLoader (and the  
> ordering of the
> classloaders).
> Also, I am quite interested in this discussion and resolution since  
> it seems
> that this Issue may be related to my IBM JDK Issue (OPENJPA-429)  
> with the
> PCEnhancer's usage of the TCL.  OpenJPA's TCL seems to have some  
> issues in
> the IBM environment (WebSphere, JDK, DB2, etc).  There must be some
> interpretation or implementation differences that causes these  
> hiccups.
> Marc, on a similar vein, can you explain what exactly the TCL buys  
> us?  As
> you can read here, we're hitting several situations where the TCL is  
> causing
> some issues.  But, if we turn it off or change or the order or  
> otherwise
> change the way we use it, the issues go away.  Looking at the code, I
> haven't determined the exact benefit of the TCL.  Can you expand on  
> that?

The TCL has always been a little sketchy, and has led to weird  
problems. For that matter, so has the MultiClassLoader: for a  
MultiClassLoader x the following observation has been known to cause  
issues: x.loadClass("foo").getClassLoader() != x

The reason we need to use the TemporaryClassLoader in the PCEnhancer  
is because before enhancing a class, we load it in order to gather  
some information via introspection. We then enhance the bytecode, but  
since the class is already loaded, the newly enhanced code won't be re- 
loaded. This is a problem if you want to use the enhanced class in the  
same JVM (e.g., for when you are enhancing at runtime, or when you  
want to enhance and run the mappingtool in the same ant process).  
Using the TemporaryClassLoader allows us to load the class in the TCL  
for introspection purposes, and then toss it away so we can then load  
the newly-enhanced class.

Ideally, we would get rid of the TemporaryClassLoader altogether, and  
just use bytecode analysis to extract the required information. I  
looked into doing this a couple years ago, and it was daunting enough  
that we instead threw in the flag to disable use the TCL to work  
around the particular problem we were seeing at the time. However,  
these recent issues might justify some additional investigation into  
the area.

Finally, at the risk of digressing, it would be nice if we could get  
rid of our omnibus MultiClassLoaders, and instead have separate  
compartmentalized ClassLoaders: one that is used for resolving  
Entities, one that is used for locating plug-ins, one that is used for  
loading dependencies (like JDBC, JNDI, and JMS drivers), etc. However,  
messing around with any of that stuff can be hairy, and is very prone  
to obscure breakage, especially when run in various different  

> Thanks,
> Kevin
> On Nov 29, 2007 11:16 AM, Michael Dick (JIRA) <> wrote:
>>    [

>> ]
>> Michael Dick updated OPENJPA-401:
>> ---------------------------------
>>   Attachment: OPENJPA-401.patch.txt
>> Unfortunately I do still see the problem. I haven't re-verified  
>> that it
>> only occurs with the IBM JDK though (I'll try that later).
>> In the mean time I wrote a quick patch which adds a configuration  
>> option
>> to disable the temporary classloader for the mappingToolTask -  
>> which might
>> be a palatable interim solution.
>>> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
>>> -------------------------------------------------------------------
>>>                Key: OPENJPA-401
>>>                URL: 
>>> OPENJPA-401
>>>            Project: OpenJPA
>>>         Issue Type: Bug
>>>   Affects Versions: 1.0.0
>>>           Reporter: Michael Dick
>>>           Assignee: Michael Dick
>>>           Priority: Minor
>>>            Fix For: 1.0.1, 1.1.0
>>>        Attachments: OPENJPA-401.patch.txt
>>> The MappingToolTask's class resolver loads classes from a temporary
>> classloader before loading them in the "normal" classloader. This  
>> can cause
>> problems if the JDBC driver requires access to native libraries  
>> (which can
>> only be loaded once).
>>> I've seen errors like this when using the DB2 JCC driver and the  
>> :
>>>  [mapping] 608  persistence-tests  INFO   [main] openjpa.Tool -
>> Recording mapping and schema changes.
>>>  [mapping] java.lang.UnsatisfiedLinkError:
>> com/ibm/jvm/Trace.initTrace([Ljava/lang/String;[Ljava/lang/String;)V
>>>  [mapping]     at
>>>  [mapping]     at<clinit>(
>>>  [mapping]     at java.lang.J9VMInternals.initializeImpl(Native  
>>> Method)
>>>  [mapping]     at  
>>> java.lang.J9VMInternals.initialize(
>> :192)
>>>  [mapping]     at java.lang.Class.forNameImpl(Native Method)
>>>  [mapping]     at java.lang.Class.forName(
>>>  [mapping]     at
>>>  [mapping]     at<clinit>(
>>>  [mapping]     at java.lang.J9VMInternals.initializeImpl(Native  
>>> Method)
>>>  [mapping]     at  
>>> java.lang.J9VMInternals.initialize(
>> :192)
>>>  [mapping]     at java.lang.Class.forNameImpl(Native Method)
>>>  [mapping]     at java.lang.Class.forName(
>>>  [mapping]     at$( 
>>> 48)
>>>  [mapping]     at  
>>>  [mapping]     at java.lang.J9VMInternals.initializeImpl(Native  
>>> Method)
>>>  [mapping]     at  
>>> java.lang.J9VMInternals.initialize(
>> :192)
>>>  [mapping]     at java.lang.Class.forNameImpl(Native Method)
>>>  [mapping]     at java.lang.Class.forName(
>>>  [mapping]     at
>> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(
>>> <snip>
>>> Note that this does not occur with the Sun JDK (or at least I  
>>> haven't
>> hit the problem.
>>> A potential solution is to change the order of the classloaders  
>>> used in
>> MappingToolTask.
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.

View raw message