Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of plinskey@gmail.com designates
 66.249.82.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FcXHkHMRfh8RdeRD/WjL6mNE3fyjbdfqL3gFhRPNmC9DDNZWZp/4xXqkc3yzDq53jUw5u0O6SjI6OQrmp22AOsf9BC8AfmJG2TkFi8pPzYBI7ChdQ61c9ec5zwTxbXQEHoYXC9IxeFQGk8HqcbZ10t4k8KZx1XUCrX5NHyAuT8g=
Message-ID: <7262f25e0708290912x29c67801wae82e1597719d140@mail.gmail.com>
Date: Wed, 29 Aug 2007 09:12:55 -0700
From: "Patrick Linskey" <plinskey@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: multiple xml mapping files found on classpath
In-Reply-To: <46D52CED.5050400@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

> 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?

-Patrick

On 8/29/07, Sahoo <sahoo@sun.com> 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 <kwsutter@gmail.com> 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 <mapping-file>
> >>> * 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 <http://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 <plinskey@gmail.com> wrote:
> >>>>
> >>>>> <mapping-file> 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 <kwsutter@gmail.com> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> In a persistence.xml , I have a specific xml mapping file
> >>>>>>
> >>> identified:
> >>>
> >>>>>> <mapping-file>OrderOfInvocationORM.xml</mapping-file>
> >>>>>>
> >>>>>> 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
> >>>
> >>>
> >
> >
> >
> >
>


-- 
Patrick Linskey
202 669 5907