openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From plins...@gmail.com
Subject Re: multiple xml mapping files found on classpath
Date Wed, 29 Aug 2007 17:31:40 GMT
Yes, but here is no portale way to disambiguate in the non-container
enment (that I am aware of, at least). If the user has so configured
the classpath, and wants isolation, the manual specification of
orm.xml files is always available.

Things are different, of course, in the in-container case.

-Patrick

On 8/29/07, Sahoo <Sahoo@sun.com> wrote:
> Patrick Linskey wrote:
> >> 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?
> >
> Depending on user's classpath settings, getResources("META-INF/orm.xml")
> can potentially return more number of resources than what the provider
> should be looking at.
>
> Thanks,
> Sahoo
> > -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

Mime
View raw message