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 19:54:34 GMT
Marina,

On 8/28/07, Marina Vatkina <Marina.Vatkina@sun.com> wrote:
>
>
> <mapping-file>OrderOfInvocationORM.xml</mapping-file> shouldn't be placed
> under
> the META-INF, as it's usually not on the classpath, while the file should
> be.
> Does OpenJPA require it to be under META-INF?


Sorry, I was cutting and pasting from various test scenarios.  We do not
require the xml mapping files to be in the META-INF directory.

thanks,
> -marina
>
> Kevin Sutter 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
> >
>
>

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