openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: multiple xml mapping files found on classpath
Date Tue, 28 Aug 2007 17:30:47 GMT
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.

-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

Mime
View raw message