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 22:01:48 GMT
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

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