openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: multiple xml mapping files found on classpath
Date Tue, 28 Aug 2007 21:58:13 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message