From dev-return-6917-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Thu Nov 29 18:23:25 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 81779 invoked from network); 29 Nov 2007 18:23:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Nov 2007 18:23:25 -0000 Received: (qmail 69146 invoked by uid 500); 29 Nov 2007 18:23:13 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 68993 invoked by uid 500); 29 Nov 2007 18:23:12 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 68984 invoked by uid 99); 29 Nov 2007 18:23:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 10:23:12 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kwsutter@gmail.com designates 209.85.146.179 as permitted sender) Received: from [209.85.146.179] (HELO wa-out-1112.google.com) (209.85.146.179) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 18:23:15 +0000 Received: by wa-out-1112.google.com with SMTP id m28so2625754wag for ; Thu, 29 Nov 2007 10:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=SezXwzBxLlVGsRDyaf8n4IWoggFhS6Bb7aLqDx6dhOQ=; b=gr92EJ4hZDoR4rBGf1DxCHjzz+4y5ZS72UbFmxWZbH4h5/pVCP0ZbMX+I4XGk+bCFYh+k++hGyAeabzY60Iz2h4AaiPo8TNI6a9zasSiPThxCGOuPrPGZeHkhmBUJ59akP0dBzmnG9fk+JbAkh63Hcaavwip4jPiR6ezgqzQDHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=oVGQeuFW/IjR8lcLXajsk8NQBNn16xmSk5YLsx+rnznE1ROgnXHYORdu2W9jxlLry5BwMQiMwp4m2WuUt6jSpzWZtBJKXJHQQ4s3NkucRIhHOmmF5tXDVGADaydcopfzWyA+PNOvYzKqXMNPk02pmm1zNulzRDX7bqWEmG5mzZE= Received: by 10.115.54.1 with SMTP id g1mr11405wak.1196360572704; Thu, 29 Nov 2007 10:22:52 -0800 (PST) Received: by 10.114.75.15 with HTTP; Thu, 29 Nov 2007 10:22:52 -0800 (PST) Message-ID: <89c0c52c0711291022h17d88aaay9ccdb4e147849c56@mail.gmail.com> Date: Thu, 29 Nov 2007 12:22:52 -0600 From: "Kevin Sutter" To: dev@openjpa.apache.org Subject: Re: [jira] Updated: (OPENJPA-401) UnsatisfiedLinkError in MappingToolTask when using DB2 JDBC driver In-Reply-To: <600975A9-F818-44D0-8D75-7AB146BB0FA7@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_976_24920218.1196360572686" References: <8785235.1192203354571.JavaMail.jira@brutus> <11531323.1196356603016.JavaMail.jira@brutus> <89c0c52c0711290945k7b990c57q1a447857838281a5@mail.gmail.com> <600975A9-F818-44D0-8D75-7AB146BB0FA7@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_976_24920218.1196360572686 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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) 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.(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.(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.(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) > >>> > >>> 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. > >> > >> > > ------=_Part_976_24920218.1196360572686--