openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sahoo <sa...@sun.com>
Subject Re: multiple xml mapping files found on classpath
Date Wed, 29 Aug 2007 08:23:09 GMT
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
>>>
>>>       
>
>
>
>   

Mime
View raw message