From dev-return-5987-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Aug 29 16:23:51 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 40253 invoked from network); 29 Aug 2007 16:23:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Aug 2007 16:23:50 -0000 Received: (qmail 25580 invoked by uid 500); 29 Aug 2007 16:23:45 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 25552 invoked by uid 500); 29 Aug 2007 16:23:45 -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 25543 invoked by uid 99); 29 Aug 2007 16:23:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2007 09:23:45 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NORMAL_HTTP_TO_IP,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.19.7] (HELO sineb-mail-2.sun.com) (192.18.19.7) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2007 16:23:39 +0000 Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7TGNBWg028371 for ; Wed, 29 Aug 2007 16:23:16 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNJ00601KOLY500@mail-apac.sun.com> (original mail from Sahoo@Sun.COM) for dev@openjpa.apache.org; Thu, 30 Aug 2007 00:23:11 +0800 (SGT) Received: from [192.168.1.10] ([59.92.196.223]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNJ00H4KMUMHW51@mail-apac.sun.com> for dev@openjpa.apache.org; Thu, 30 Aug 2007 00:23:11 +0800 (SGT) Date: Wed, 29 Aug 2007 21:56:26 +0530 From: Sahoo Subject: Re: multiple xml mapping files found on classpath In-reply-to: <7262f25e0708290912x29c67801wae82e1597719d140@mail.gmail.com> Sender: Sanjeeb.Sahoo@Sun.COM To: dev@openjpa.apache.org Message-id: <46D59E32.6050102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <89c0c52c0708280924n6cd682d7i8cca8cfac49adde4@mail.gmail.com> <7262f25e0708280933s61d1f79aqefdf3306a60b4384@mail.gmail.com> <89c0c52c0708280954v10072b80o10667aa023a5408b@mail.gmail.com> <7262f25e0708281030tc3a5e06o842a2139471d172c@mail.gmail.com> <89c0c52c0708281458y20430e8dw2d165d0420e7da00@mail.gmail.com> <7262f25e0708281501o19f79ee5o27c318b181fa85dc@mail.gmail.com> <46D52CED.5050400@Sun.COM> <7262f25e0708290912x29c67801wae82e1597719d140@mail.gmail.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) X-Virus-Checked: Checked by ClamAV on apache.org Patrick Linskey wrote: >> By the way, how does OpenJPA search the default mapping >> file(META-INF/orm.xml)? I hope it does not search using >> ClassLoader.getResources() API. >> > > I would assume that we use a call like that at some point in the > non-container environment... why? > Depending on user's classpath settings, getResources("META-INF/orm.xml") can potentially return more number of resources than what the provider should be looking at. Thanks, Sahoo > -Patrick > > On 8/29/07, Sahoo wrote: > >> This is yet another source of non-portability of JPA applications. I >> know about a fairly widely used, spec compliant JPA provider which >> behaves very differently in this scenario. Its *default* behavior is to >> throw an exception. It can be configured to just log a warning and >> continue using the first available resource by that name - which I agree >> is a very dangerous option for reasons already mentioned in this email >> thread. >> >> I think it is worth raising this issue to the expert group so that the >> spec can be *corrected*. >> >> By the way, how does OpenJPA search the default mapping >> file(META-INF/orm.xml)? I hope it does not search using >> ClassLoader.getResources() API. >> >> Thanks, >> Sahoo >> >> Patrick Linskey wrote: >> >>> I definitely like our current handling. I do think that the spec makes it a >>> bit vague by mentioning that the names should be 'unique'. However, the spec >>> certainly does not indicate that what we're doing is flagrantly incorrect. >>> >>> -Patrick >>> >>> On 8/28/07, Kevin Sutter wrote: >>> >>> >>>> Patrick, >>>> I'm coming to a slightly different conclusion from the javadoc and spec... >>>> >>>> On 8/28/07, Patrick Linskey < plinskey@gmail.com> wrote: >>>> >>>> >>>>> The spec JavaDoc for PUImpl implies that we should throw an exception: >>>>> >>>>> /** >>>>> * @return The list of mapping file names that the persistence >>>>> * provider must load to determine the mappings for the entity >>>>> * classes. The mapping files must be in the standard XML >>>>> * mapping format, be uniquely named and be resource-loadable >>>>> * from the application classpath. >>>>> * Each mapping file name corresponds to a >>>>> * element in the persistence.xml file. >>>>> */ >>>>> >>>>> Of course, this is just the JavaDoc, and doesn't comment about the XML >>>>> elements directly, but it probably stands to reason that the two are >>>>> equivalent. >>>>> >>>>> >>>> The javadoc above indicates that the mapping files are >>>> "resource-loadable". >>>> And, section " 6.2.1.6 mapping-file, jar-file, class, >>>> exclude-unlisted-classes" of the JPA spec has the following sentence: "An >>>> orm.xml file or other mapping file is loaded as a resource by the >>>> persistence provider." >>>> >>>> Both of these references indicate that the mapping files should be treated >>>> as "resources". Thus, I think our current processing of looking for all >>>> instances via the classloader and merging the contents is the correct >>>> processing. No exception processing should be considered. This >>>> processing >>>> would be consistent with our persistence.xml and orm.xml processing. >>>> >>>> Agree? >>>> >>>> Kevin >>>> >>>> -Patrick >>>> >>>> >>>>> On 8/28/07, Kevin Sutter < kwsutter@gmail.com> wrote: >>>>> >>>>> >>>>>> On 8/28/07, Patrick Linskey wrote: >>>>>> >>>>>> >>>>>>> identifies a resource, not a file (despite the name). >>>>>>> In general, we try to handle resources on the assumption that there >>>>>>> might be more than one. >>>>>>> >>>>>>> Personally, I think that the current behavior is the most >>>>>>> >>>>>>> >>>> appropriate. >>>> >>>> >>>>>>> Imagine that you are working on a project that has multiple teams >>>>>>> contributing XML mapping files. What happens if each team builds a >>>>>>> separate jar that contributes to the same PU but creates mapping >>>>>>> >>>>>>> >>>> files >>>> >>>> >>>>>>> with the same names? The current behavior is more tolerant of such >>>>>>> configurations. >>>>>>> >>>>>>> >>>>>> After I wrote up the note on this topic, I was starting to think along >>>>>> >>>>>> >>>>> these >>>>> >>>>> >>>>>> same lines. This type of processing would also be consistent with the >>>>>> processing of the generic orm.xml resource. >>>>>> >>>>>> I can see a strong case for throwing an exception if multiple >>>>>> >>>>>> >>>>>>> resources are found, also -- that would be my second preference. >>>>>>> >>>>>>> >>>>>> Agree. We either have to process all discovered resources with the >>>>>> >>>>>> >>>>> given >>>>> >>>>> >>>>>> name or we have to thrown an exception. At this point, I am leaning >>>>>> >>>>>> >>>>> towards >>>>> >>>>> >>>>>> allowing the current behavior of multiple xml mapping >>>>>> >>>>>> >>>> resources. Unless >>>> >>>> >>>>>> someone finds a spec reference that indicates we're doing the wrong >>>>>> >>>>>> >>>>> thing... >>>>> >>>>> >>>>>> Kevin >>>>>> >>>>>> I think that just choosing one would be undesirable, since it would >>>>>> >>>>>> >>>>>>> lead to relatively unpredictable / unexpected behavior (even if we >>>>>>> deterministically chose the first one available or something). >>>>>>> >>>>>>> -Patrick >>>>>>> >>>>>>> On 8/28/07, Kevin Sutter wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> In a persistence.xml , I have a specific xml mapping file >>>>>>>> >>>>>>>> >>>>> identified: >>>>> >>>>> >>>>>>>> OrderOfInvocationORM.xml >>>>>>>> >>>>>>>> I am finding that our processing in AbstractCFMetaDataFactory is >>>>>>>> >>>>>>>> >>>>> looking >>>>> >>>>> >>>>>>> for >>>>>>> >>>>>>> >>>>>>>> and processing all instances of >>>>>>>> >>>>>>>> >>>> "META-INF/OrderOfInvocationORM.xml" >>>> >>>> >>>>> in >>>>> >>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> classpath, not just the first one. It just so happens that a test >>>>>>>> environment that I am processing in had multiple versions of this >>>>>>>> >>>>>>>> >>>>> file >>>>> >>>>> >>>>>>>> available in the classpath (both my ejb and web modules). This >>>>>>>> >>>>>>>> >>>>> multiple >>>>> >>>>> >>>>>>> xml >>>>>>> >>>>>>> >>>>>>>> mapping file processing surprised me. >>>>>>>> >>>>>>>> I understand where we need to search for multiple versions of the >>>>>>>> >>>>>>>> >>>>>>> generic >>>>>>> >>>>>>> >>>>>>>> "META-INF/orm.xml" file in the classpath, but I would have >>>>>>>> >>>>>>>> >>>> expected >>>> >>>> >>>>> that >>>>> >>>>> >>>>>>> we >>>>>>> >>>>>>> >>>>>>>> only process a single instance of a specific named xml mapping >>>>>>>> >>>>>>>> >>>> file. >>>> >>>> >>>>>>>> Of course, you could argue that if you do have multiple copies >>>>>>>> >>>>>>>> >>>>> available >>>>> >>>>> >>>>>>> on >>>>>>> >>>>>>> >>>>>>>> the classpath and we're only supposed to process one of them, >>>>>>>> >>>>>>>> >>>> which >>>> >>>> >>>>> one >>>>> >>>>> >>>>>>> do >>>>>>> >>>>>>> >>>>>>>> we process? First, last, all of them as we do today? >>>>>>>> >>>>>>>> I've read through the spec and the Pro EJB3 book and although they >>>>>>>> >>>>>>>> >>>>> imply >>>>> >>>>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>>> single file will be processed, it's not explicit. So, I'm looking >>>>>>>> >>>>>>>> >>>>> for >>>>> >>>>> >>>>>>> any >>>>>>> >>>>>>> >>>>>>>> other interpretations or findings in the spec that would indicate >>>>>>>> >>>>>>>> >>>>>>> whether we >>>>>>> >>>>>>> >>>>>>>> are processing correctly or not. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Patrick Linskey >>>>>>> 202 669 5907 >>>>>>> >>>>>>> >>>>>>> >>>>> -- >>>>> Patrick Linskey >>>>> 202 669 5907 >>>>> >>>>> >>>>> >>> >>> >>> > > > >