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 16:26:26 GMT
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
>>>>>
>>>>>
>>>>>           
>>>
>>>
>>>       
>
>
>
>   

Mime
View raw message