openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver
Date Thu, 29 Nov 2007 17:45:05 GMT
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) <jira@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message