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 18:22:52 GMT
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 <mprudhom@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) <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