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 18:23:13 GMT
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 <Sahoo@sun.com> wrote:
>   
>> Patrick Linskey wrote:
>>     
>>>> By the way, how does OpenJPA search the default mapping
>>>> file(META-INF/orm.xml)? I hope it does not search using
>>>> ClassLoader.getResources() API.
>>>>
>>>>         
>>> I would assume that we use a call like that at some point in the
>>> non-container environment... why?
>>>
>>>       
>> Depending on user's classpath settings, getResources("META-INF/orm.xml")
>> can potentially return more number of resources than what the provider
>> should be looking at.
>>
>> Thanks,
>> Sahoo
>>     
>>> -Patrick
>>>
>>> On 8/29/07, Sahoo <sahoo@sun.com> wrote:
>>>
>>>       
>>>> This is yet another source of non-portability of JPA applications. I
>>>> know about a fairly widely used, spec compliant JPA provider which
>>>> behaves very differently in this scenario. Its *default* behavior is to
>>>> throw an exception. It can be configured to just log a warning and
>>>> continue using the first available resource by that name - which I agree
>>>> is a very dangerous option for reasons already mentioned in this email
>>>> thread.
>>>>
>>>> I think it is worth raising this issue to the expert group so that the
>>>> spec can be *corrected*.
>>>>
>>>> By the way, how does OpenJPA search the default mapping
>>>> file(META-INF/orm.xml)? I hope it does not search using
>>>> ClassLoader.getResources() API.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Patrick Linskey wrote:
>>>>
>>>>         
>>>>> I definitely like our current handling. I do think that the spec makes
>>>>>           
>> it a
>>     
>>>>> bit vague by mentioning that the names should be 'unique'. However, the
>>>>>           
>> spec
>>     
>>>>> certainly does not indicate that what we're doing is flagrantly
>>>>>           
>> incorrect.
>>     
>>>>> -Patrick
>>>>>
>>>>> On 8/28/07, Kevin Sutter <kwsutter@gmail.com> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Patrick,
>>>>>> I'm coming to a slightly different conclusion from the javadoc and
>>>>>>             
>> spec...
>>     
>>>>>> On 8/28/07, Patrick Linskey < plinskey@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> The spec JavaDoc for PUImpl implies that we should throw an exception:
>>>>>>>
>>>>>>> /**
>>>>>>> * @return The list of mapping file names that the persistence
>>>>>>> * provider must load to determine the mappings for the entity
>>>>>>> * classes. The mapping files must be in the standard XML
>>>>>>> * mapping format, be uniquely named and be resource-loadable
>>>>>>> * from the application classpath.
>>>>>>> * Each mapping file name corresponds to a <mapping-file>
>>>>>>> * element in the persistence.xml file.
>>>>>>> */
>>>>>>>
>>>>>>> Of course, this is just the JavaDoc, and doesn't comment about
the XML
>>>>>>> elements directly, but it probably stands to reason that the
two are
>>>>>>> equivalent.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> The javadoc above indicates that the mapping files are
>>>>>> "resource-loadable".
>>>>>> And, section " 6.2.1.6 <http://6.2.1.6> mapping-file, jar-file,
class,
>>>>>> exclude-unlisted-classes" of the JPA spec has the following sentence:
>>>>>>             
>> "An
>>     
>>>>>> orm.xml file or other mapping file is loaded as a resource by the
>>>>>> persistence provider."
>>>>>>
>>>>>> Both of these references indicate that the mapping files should be
>>>>>>             
>> treated
>>     
>>>>>> as "resources".  Thus, I think our current processing of looking
for
>>>>>>             
>> all
>>     
>>>>>> instances via the classloader and merging the contents is the correct
>>>>>> processing.  No exception processing should be considered.  This
>>>>>> processing
>>>>>> would be consistent with our persistence.xml and orm.xml processing.
>>>>>>
>>>>>> Agree?
>>>>>>
>>>>>> Kevin
>>>>>>
>>>>>> -Patrick
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On 8/28/07, Kevin Sutter < kwsutter@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> On 8/28/07, Patrick Linskey <plinskey@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> <mapping-file> identifies a resource, not a file
(despite the name).
>>>>>>>>> In general, we try to handle resources on the assumption
that there
>>>>>>>>> might be more than one.
>>>>>>>>>
>>>>>>>>> Personally, I think that the current behavior is the
most
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>> appropriate.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>>> Imagine that you are working on a project that has multiple
teams
>>>>>>>>> contributing XML mapping files. What happens if each
team builds a
>>>>>>>>> separate jar that contributes to the same PU but creates
mapping
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>> files
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>>> with the same names? The current behavior is more tolerant
of such
>>>>>>>>> configurations.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> After I wrote up the note on this topic, I was starting to
think
>>>>>>>>                 
>> along
>>     
>>>>>>>>                 
>>>>>>> these
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> same lines.  This type of processing would also be consistent
with
>>>>>>>>                 
>> the
>>     
>>>>>>>> processing of the generic orm.xml resource.
>>>>>>>>
>>>>>>>> I can see a strong case for throwing an exception if multiple
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> resources are found, also -- that would be my second
preference.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Agree.  We either have to process all discovered resources
with the
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> given
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> name or we have to thrown an exception.  At this point, I
am leaning
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> towards
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> allowing the current behavior of multiple xml mapping
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>> resources.  Unless
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> someone finds a spec reference that indicates we're doing
the wrong
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> thing...
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Kevin
>>>>>>>>
>>>>>>>> I think that just choosing one would be undesirable, since
it would
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> lead to relatively unpredictable / unexpected behavior
(even if we
>>>>>>>>> deterministically chose the first one available or something).
>>>>>>>>>
>>>>>>>>> -Patrick
>>>>>>>>>
>>>>>>>>> On 8/28/07, Kevin Sutter <kwsutter@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Hi,
>>>>>>>>>> In a persistence.xml , I have a specific xml mapping
file
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> identified:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> <mapping-file>OrderOfInvocationORM.xml</mapping-file>
>>>>>>>>>>
>>>>>>>>>> I am finding that our processing in AbstractCFMetaDataFactory
is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> looking
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> and processing all instances of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>> "META-INF/OrderOfInvocationORM.xml"
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> in
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> classpath, not just the first one.  It just so happens
that a test
>>>>>>>>>> environment that I am processing in had multiple
versions of this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> file
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> available in the classpath (both my ejb and web modules).
 This
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> multiple
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> xml
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> mapping file processing surprised me.
>>>>>>>>>>
>>>>>>>>>> I understand where we need to search for multiple
versions of the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> generic
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> "META-INF/orm.xml" file in the classpath, but I would
have
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>> expected
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> that
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> we
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> only process a single instance of a specific named
xml mapping
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>> file.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>>>> Of course, you could argue that if you do have multiple
copies
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> available
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> the classpath and we're only supposed to process
one of them,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>> which
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> one
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> do
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> we process?  First, last, all of them as we do today?
>>>>>>>>>>
>>>>>>>>>> I've read through the spec and the Pro EJB3 book
and although they
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> imply
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> single file will be processed, it's not explicit.
 So, I'm looking
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> for
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> any
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> other interpretations or findings in the spec that
would indicate
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> whether we
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> are processing correctly or not.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Kevin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> --
>>>>>>>>> Patrick Linskey
>>>>>>>>> 202 669 5907
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> --
>>>>>>> Patrick Linskey
>>>>>>> 202 669 5907
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>
>>>>>           
>>>
>>>
>>>       
>
>
>   

Mime
View raw message