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) <[EMAIL PROTECTED]> 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.
