You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Michael Dick (JIRA)" <ji...@apache.org> on 2007/10/12 17:35:54 UTC
[jira] Created: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
-------------------------------------------------------------------
Key: OPENJPA-401
URL: https://issues.apache.org/jira/browse/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
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 IBM JDK :
[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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
[mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
[mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
[mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
[mapping] at java.lang.Class.forNameImpl(Native Method)
[mapping] at java.lang.Class.forName(Class.java:130)
[mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
[mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
[mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
[mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
[mapping] at java.lang.Class.forNameImpl(Native Method)
[mapping] at java.lang.Class.forName(Class.java:130)
[mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
[mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
[mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
[mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
[mapping] at java.lang.Class.forNameImpl(Native Method)
[mapping] at java.lang.Class.forName(Class.java:163)
[mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
<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.
Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
Posted by Kevin Sutter <kw...@gmail.com>.
Marc,
Thanks for the reply. More comments below... Sounds like we could have a
"mess" with this classloading issue and I am by no means an expert in this
area. :-)
On Nov 29, 2007 12:05 PM, Marc Prud'hommeaux <mp...@apache.org> wrote:
> Kevin-
>
> 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.
>
Sorry if I misinterpretted the changes, but the svn changes attached to
OPENJPA-401 seemed to show the ordering was changed by both of you. I may
have looked at the changes too quickly though... No big deal. We still
have the issue to resolve...
>
> > 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
I agree. I just ran into this situation the other day while debugging the
PCEnhancer problem.
>
>
> 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.
This makes sense. And, now that you explain it, I see there are similar
comments in the code. They just weren't registering with me...
>
> 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
> containers.
Although I agree with the proposal, I am not the guy you want messing with
the classloaders... :-)
Kevin
>
>
>
> > Thanks,
> > Kevin
> >
> > On Nov 29, 2007 11:16 AM, Michael Dick (JIRA) <ji...@apache.org> wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >> ]
> >>
> >> 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: https://issues.apache.org/jira/browse/
> >>> 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
> >>> IBM JDK
> >> :
> >>> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> >>> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> >>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
> >>> Method)
> >>> [mapping] at
> >>> java.lang.J9VMInternals.initialize(J9VMInternals.java
> >> :192)
> >>> [mapping] at java.lang.Class.forNameImpl(Native Method)
> >>> [mapping] at java.lang.Class.forName(Class.java:130)
> >>> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> >>> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> >>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
> >>> Method)
> >>> [mapping] at
> >>> java.lang.J9VMInternals.initialize(J9VMInternals.java
> >> :192)
> >>> [mapping] at java.lang.Class.forNameImpl(Native Method)
> >>> [mapping] at java.lang.Class.forName(Class.java:130)
> >>> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:
> >>> 48)
> >>> [mapping] at
> >>> com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> >>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
> >>> Method)
> >>> [mapping] at
> >>> java.lang.J9VMInternals.initialize(J9VMInternals.java
> >> :192)
> >>> [mapping] at java.lang.Class.forNameImpl(Native Method)
> >>> [mapping] at java.lang.Class.forName(Class.java:163)
> >>> [mapping] at
> >> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(
> >> DataSourceFactory.java:82)
> >>> <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.
> >>
> >>
>
>
Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Kevin-
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
containers.
> Thanks,
> Kevin
>
> On Nov 29, 2007 11:16 AM, Michael Dick (JIRA) <ji...@apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> 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: https://issues.apache.org/jira/browse/
>>> 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
>>> IBM JDK
>> :
>>> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
>>> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
>>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
>>> Method)
>>> [mapping] at
>>> java.lang.J9VMInternals.initialize(J9VMInternals.java
>> :192)
>>> [mapping] at java.lang.Class.forNameImpl(Native Method)
>>> [mapping] at java.lang.Class.forName(Class.java:130)
>>> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
>>> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
>>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
>>> Method)
>>> [mapping] at
>>> java.lang.J9VMInternals.initialize(J9VMInternals.java
>> :192)
>>> [mapping] at java.lang.Class.forNameImpl(Native Method)
>>> [mapping] at java.lang.Class.forName(Class.java:130)
>>> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:
>>> 48)
>>> [mapping] at
>>> com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
>>> [mapping] at java.lang.J9VMInternals.initializeImpl(Native
>>> Method)
>>> [mapping] at
>>> java.lang.J9VMInternals.initialize(J9VMInternals.java
>> :192)
>>> [mapping] at java.lang.Class.forNameImpl(Native Method)
>>> [mapping] at java.lang.Class.forName(Class.java:163)
>>> [mapping] at
>> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(
>> DataSourceFactory.java:82)
>>> <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.
>>
>>
Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
Posted by Kevin Sutter <kw...@gmail.com>.
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.
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?
Thanks,
Kevin
On Nov 29, 2007 11:16 AM, Michael Dick (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> 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: https://issues.apache.org/jira/browse/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 IBM JDK
> :
> > [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> > [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> > [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> > [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java
> :192)
> > [mapping] at java.lang.Class.forNameImpl(Native Method)
> > [mapping] at java.lang.Class.forName(Class.java:130)
> > [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> > [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> > [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> > [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java
> :192)
> > [mapping] at java.lang.Class.forNameImpl(Native Method)
> > [mapping] at java.lang.Class.forName(Class.java:130)
> > [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> > [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> > [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> > [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java
> :192)
> > [mapping] at java.lang.Class.forNameImpl(Native Method)
> > [mapping] at java.lang.Class.forName(Class.java:163)
> > [mapping] at
> org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(
> DataSourceFactory.java:82)
> > <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.
>
>
[jira] Reopened: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marc Prud'hommeaux reopened OPENJPA-401:
----------------------------------------
I'm reopening this because the fix was causing intermittent failures in loading metadata. E.g.:
[mappingtool] <openjpa-1.1.0-SNAPSHOT-r420667:598829 fatal user error> org.apache.openjpa.util.MetaDataException: Type "class kodo.performance.PerfMultiA" does not have persistence metadata.
[mappingtool] at org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:679)
[mappingtool] at org.apache.openjpa.jdbc.meta.MappingTool.refresh(MappingTool.java:716)
[mappingtool] at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:641)
[mappingtool] at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
[mappingtool] at org.apache.openjpa.jdbc.ant.MappingToolTask.executeOn(MappingToolTask.java:197)
[mappingtool] at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:172)
I've committed revision #599178 which swaps the order in which the child loaders are added to the MultiLoaderClassResolver, which seems to fix the problem, but I don't know if it will re-introduce the original symptoms reported in the bug. Michael, can you check with this new revision to see if it still works with your DB2 native driver?
> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
> -------------------------------------------------------------------
>
> Key: OPENJPA-401
> URL: https://issues.apache.org/jira/browse/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
>
>
> 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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.
[jira] Commented: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564138#action_12564138 ]
Patrick Linskey commented on OPENJPA-401:
-----------------------------------------
What's the status of this issue?
> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
> -------------------------------------------------------------------
>
> Key: OPENJPA-401
> URL: https://issues.apache.org/jira/browse/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.0.2, 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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.
[jira] Closed: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick closed OPENJPA-401.
--------------------------------
Resolution: Fixed
> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
> -------------------------------------------------------------------
>
> Key: OPENJPA-401
> URL: https://issues.apache.org/jira/browse/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
>
>
> 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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.
[jira] Closed: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick closed OPENJPA-401.
--------------------------------
Resolution: Fixed
The MappingToolTask now includes a flag which can be used to disable the temporary classloader, similarly to the PCEnhancerTask. If the flag is not specified then we'll use the temporary classloader (original behavior).
> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
> -------------------------------------------------------------------
>
> Key: OPENJPA-401
> URL: https://issues.apache.org/jira/browse/OPENJPA-401
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Michael Dick
> Assignee: Michael Dick
> Priority: Minor
> Fix For: 1.0.2, 1.1.0, 1.0.1
>
> 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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.
[jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-401:
------------------------------------
Fix Version/s: 1.0.2
> UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
> -------------------------------------------------------------------
>
> Key: OPENJPA-401
> URL: https://issues.apache.org/jira/browse/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.0.2, 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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.
[jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in
MappingToolTask when using DB2 JDBC driver
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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: https://issues.apache.org/jira/browse/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 IBM JDK :
> [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 com.ibm.jvm.Trace.initializeTrace(Trace.java:96)
> [mapping] at com.ibm.jvm.Trace.<clinit>(Trace.java:61)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.c.o.q(o.java:550)
> [mapping] at com.ibm.db2.jcc.c.o.<clinit>(o.java:319)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:130)
> [mapping] at com.ibm.db2.jcc.DB2Driver.class$(DB2Driver.java:48)
> [mapping] at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:51)
> [mapping] at java.lang.J9VMInternals.initializeImpl(Native Method)
> [mapping] at java.lang.J9VMInternals.initialize(J9VMInternals.java:192)
> [mapping] at java.lang.Class.forNameImpl(Native Method)
> [mapping] at java.lang.Class.forName(Class.java:163)
> [mapping] at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:82)
> <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.