Sahoo,
I'll do more experiments with Class-path in manifest to see why were
the files found originally, when that entry was missing. I need to test
a PU packaged into a jar in SE as well to see which path we take in
finding the files.
But step#2 is not that simple. If you have your PU defined in Java SE
and mappingFile.xml is located in the PU root, plus (incidentally) there
is another mappingFile.xml located somewhere on the classpath, we
most probably should ignore that other one.
Also, if we ever support jar-file in SE, that complicated logic might
need to be added back to step#2.
And the last one - Tom mentioned (I'll leave it for Tom to give details
and examples) that Tomcat returns some strange URLs that need to be
addressed separately, and this is done in URL comparisons after getResources()
call.
Let's see what else I can find on what seemed like an easy bug fix ;).
thanks,
-marina
Sanjeeb Kumar Sahoo wrote:
> Marina,
>
> There is also a bug in the code and the subject line of this mail thread
> spells it out nicely. The code does not distinguish between the default
> mapping file(META-INF/persistence.xml) and the files specified using
> <mapping-file> element in persistence.xml. It is making a merged list
> and then applying uniform strategy to look them up. That's wrong. It
> should do this:
> // step #1: try to read default mapping file (META-INF/orm.xml) from
> PURoot and from each referenced jar-file.
> // during this time, it can use all the complex logic that is required
> to handle various difference kinds of URLs that can be encountered.
> // step #2: read explicitly specified mapping-files
> for (String mfName : puInfo.getmappingFiles()) {
> // don't do any special processing if user specified META-INF/orm.xml
> here as well. That's a bug in user code.
> InputStream mfStream =
> persistenceUnitInfo.getTempClassLoader().getResourceAsStream(mfName);
> // read the content...
> }
>
> In step #2, we can definitely throw a ValidationException if we come
> across multiple mapping files with same name as Winsoek suggested earlier.
>
> I have a feeling, this change has to be made in more than one place.
>
> Thanks,
> Sahoo
>
> Marina Vatkina wrote:
>
>> Hi Tom,
>>
>> It was my fault - manifest file in PU didn't have Class-Path entry to add
>> that jar to the classpath (thanks Sahoo!).
>>
>> thanks,
>> -marina
>>
>> Tom Ware wrote:
>>
>>> Hi Marina,
>>>
>>> Are the entities you are having trouble loading on the classpath?
>>> It is my understanding that the jars should be on the classpath
>>> (either put there by the application server, or, in the SE case,
>>> explicitly put there)
>>>
>>> -Tom
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Hi Wonseok,
>>>>
>>>> Very good point about more than one resource.
>>>>
>>>> PersistenceUnitProcessor.createInputStreamForFileInPersistenceUnit
>>>> the 1st thing it does - looks for the mapping files located in a jar.
>>>>
>>>> Attached test proves that it does look in a jar as it complains about
>>>> not found classes. Which brings up another questions: am I doing
>>>> something wrong there, or is it another bug: 2 out of 3 entities
>>>> listed in the mapping file(s) and located in that ref-ed jar can't be
>>>> loaded (so they are ignored - the 3rd bug?).
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Wonseok Kim wrote On 09/10/06 23:05,:
>>>>
>>>>
>>>>> Hi, Marina
>>>>>
>>>>> I agree that orm.xml or mapping files in the PU root should be used if
>>>>> there are multiple same name files in the classpath.
>>>>> But if there is no one in PU root and we pick one of the same name
>>>>> mapping files in the classpath, it can be unpredictable.
>>>>> How about throwing an exception in that case? Of course if there is
>>>>> one
>>>>> mapping file in the classpath, it should work.
>>>>> If you agree with this, the 4th step should call getResources() and
>>>>> check the number of returned resources.
>>>>>
>>>>> I'm now curious that current impl can process several META-INF/orm.xml
>>>>> files which exist in referenced jar files from persistence.xml. You
>>>>> mentioned it is accomplished by current impl, but I couldn't find
>>>>> it in
>>>>> the code... please instruct me.
>>>>>
>>>>> Thanks
>>>>> - Wonseok
>>>>>
>>>>> On 9/9/06, *Marina Vatkina* <Marina.Vatkina_at_sun.com
>>>>> <mailto:Marina.Vatkina_at_sun.com>> wrote:
>>>>>
>>>>> Team,
>>>>>
>>>>> Do you have any idea of a simpler/better/nicer solution for
>>>>> locating
>>>>> mapping
>>>>> files in a PU?
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>>> -------- Original Message --------
>>>>> From: mvatkina_at_dev.java.net <mailto:mvatkina_at_dev.java.net>
>>>>> Subject: [Issue 1074] Regression: TopLink does not serach
>>>>> classpath
>>>>> for mapping
>>>>> files specified in persistence.xml
>>>>>
>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1074
>>>>>
>>>>>
>>>>>
>>>>> User mvatkina changed the following:
>>>>>
>>>>> What |Old value |New value
>>>>>
>>>>> ================================================================================
>>>>>
>>>>>
>>>>> Status|NEW |STARTED
>>>>>
>>>>> --------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------- Additional comments from mvatkina_at_dev.java.net
>>>>> <mailto:mvatkina_at_dev.java.net> Fri Sep 8 20:41:35 +0000
>>>>> 2006 -------
>>>>> Here is what I learned about the current implementation:
>>>>>
>>>>> 1. Because there can be more than 1 persistence.xml on the
>>>>> classpath,
>>>>> META-INF/orm.xml or any other mapping file referenced from a
>>>>> persistence.xml,
>>>>> must be 1st looked up in the PU root or in any jar file referenced
>>>>> from that
>>>>> persistence.xml. Otherwise we can get some other PU's mapping files
>>>>> that are
>>>>> accidentally on the classpath (is it a spec oversight that there is
>>>>> no PU name
>>>>> in the mapping file?).
>>>>> This is accomplished by steps 1 and 2 in
>>>>>
>>>>> PersistenceUnitProcessor.createInputStreamForFileInPersistenceUnit().
>>>>>
>>>>> 2. In Tomcat the PU root is returned by a complicated URL that is
>>>>> handled by
>>>>> step 3 in the above method.
>>>>>
>>>>> The solution would be to add getResourceAsStream call as the 4th
>>>>> step, but it's
>>>>> not clear if we should attempt to do so for the default mapping
>>>>> file
>>>>> (META-INF/orm.xml).
>>>>>
>>>>>
>>>>>