You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/08/28 18:24:23 UTC
multiple xml mapping files found on classpath
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
Re: multiple xml mapping files found on classpath
Posted by Kevin Sutter <kw...@gmail.com>.
Marina,
On 8/28/07, Marina Vatkina <Ma...@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
> >
>
>
Re: multiple xml mapping files found on classpath
Posted by Marina Vatkina <Ma...@Sun.COM>.
Kevin,
<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?
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
>
Re: multiple xml mapping files found on classpath
Posted by Sahoo <Sa...@Sun.COM>.
Patrick Linskey wrote:
>> Since PURoot URI can be calculated
>>
>
> How, portably?
>
>
Can PURoot URI not be calculated like this:
URL pxmlURL = ClassLoader.getResource("META-INF/persistence.xml");
URL puRoot = new URL(pxmlURL, "../");
Thanks,
Sahoo
Re: multiple xml mapping files found on classpath
Posted by Patrick Linskey <pl...@gmail.com>.
> Since PURoot URI can be calculated
How, portably?
> BTW, I did not understand what you meant by "manual specification of
> orm.xml files."
I meant that the user can specify different XML file URLs, which they
can then ensure are unique.
-Patrick
On 8/29/07, Sahoo <Sa...@sun.com> wrote:
> I think it is possible. Since PURoot URI can be calculated, one can use
> java.net.URI API to get an absolute URI from the relative URI
> "META-INF/orm.xml," and read the resource. About orm.xml files in
> related jar files, does OpenJPA support this in non-container
> environment? The spec (see persistence_1_0.xsd) says jar-file element is
> not applicable for non-container environment. If a provider wants to
> support it, I think it should first get URIs for each referenced jar
> file, and it can then use java.util.JarFile API to read "META-INF/orm.xml."
>
> BTW, I did not understand what you meant by "manual specification of
> orm.xml files."
>
> Thanks,
> Sahoo
>
> plinskey@gmail.com wrote:
> > 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 <Sa...@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 <sa...@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 <kw...@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 <pl...@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 <kw...@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
Re: multiple xml mapping files found on classpath
Posted by Sahoo <Sa...@Sun.COM>.
I think it is possible. Since PURoot URI can be calculated, one can use
java.net.URI API to get an absolute URI from the relative URI
"META-INF/orm.xml," and read the resource. About orm.xml files in
related jar files, does OpenJPA support this in non-container
environment? The spec (see persistence_1_0.xsd) says jar-file element is
not applicable for non-container environment. If a provider wants to
support it, I think it should first get URIs for each referenced jar
file, and it can then use java.util.JarFile API to read "META-INF/orm.xml."
BTW, I did not understand what you meant by "manual specification of
orm.xml files."
Thanks,
Sahoo
plinskey@gmail.com wrote:
> 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 <Sa...@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 <sa...@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 <kw...@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 <pl...@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 <kw...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: multiple xml mapping files found on classpath
Posted by pl...@gmail.com.
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 <Sa...@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 <sa...@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 <kw...@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 <pl...@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 <kw...@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
Re: multiple xml mapping files found on classpath
Posted by Sahoo <Sa...@Sun.COM>.
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 <sa...@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 <kw...@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 <pl...@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 <kw...@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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
>
Re: multiple xml mapping files found on classpath
Posted by Patrick Linskey <pl...@gmail.com>.
> 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?
-Patrick
On 8/29/07, Sahoo <sa...@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 <kw...@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 <pl...@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 <kw...@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
Re: multiple xml mapping files found on classpath
Posted by Sahoo <sa...@sun.com>.
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 <kw...@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 <pl...@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 <kw...@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
>>>
>>>
>
>
>
>
Re: multiple xml mapping files found on classpath
Posted by Patrick Linskey <pl...@gmail.com>.
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 <kw...@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 <pl...@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 <kw...@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
Re: multiple xml mapping files found on classpath
Posted by Kevin Sutter <kw...@gmail.com>.
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 <pl...@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 <kw...@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
>
Re: multiple xml mapping files found on classpath
Posted by Patrick Linskey <pl...@gmail.com>.
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 <kw...@gmail.com> wrote:
> On 8/28/07, Patrick Linskey <pl...@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 <kw...@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
Re: multiple xml mapping files found on classpath
Posted by Kevin Sutter <kw...@gmail.com>.
On 8/28/07, Patrick Linskey <pl...@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 <kw...@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
>
Re: multiple xml mapping files found on classpath
Posted by Patrick Linskey <pl...@gmail.com>.
<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.
I can see a strong case for throwing an exception if multiple
resources are found, also -- that would be my second preference.
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 <kw...@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