Hi Sahoo,
I think the fix should be ok.
Is there anywhere we can document the cases that will cause issues?
(SE deployments that are not in jar files must have all classes listed,
I guess )
-Tom
Sanjeeb Kumar Sahoo wrote:
>Hi Tom,
>
>Very good point raised. I forgot to mention about this in the proposed
>fix. We have a *new* method in ArchiveFactoryImpl called
>*isJarInputStream(URL)* which checks if a Jar format InputStream can be
>obtained from a URL. If this method returns true, ArchiveFactoryImpl
>returns a JarInputStreamArchive, else it returns a URLArchive.
>JarInputStream can return the entries of a jar correctly.
>
>For <jar-file>bar.jar</jar-file>, Eclipse gives us a URL which looks
>like bundleresource://3/bar.jar. For this, isJarInputStream() returns
>true, so we are OK.
>
>One more thing to note is that, we are not likely to use URLArchive in
>Java EE environment as the spec requires containers to return URLs with
>either file: or jar: scheme or from which a Jar format InputStream can
>be obtained.
>
>Hope this clarifies. I shall update the proposed fix details in issue
>tracker.
>
>Thanks,
>Sahoo
>Tom Ware wrote:
>
>
>>Hi Sahoo,
>>
>> I just have one concern. Perhaps you can alleviate it.
>>
>> The fact that we have to return and empty iterator from the
>>getEntries method of URLArchive means we cannot detect classes that
>>are in a jar. Can the URL of a jar file listed in persistence.xml as
>>a <jar-file> use this kind of a URL? If so, doesn't the spec require
>>us to be able to detect the classes?
>>
>>-Tom
>>
>>
>>Sanjeeb Kumar Sahoo wrote:
>>
>>
>>
>>>Hi Tom,
>>>
>>>Please review the fix for issue #1502. It needs introduction of a new
>>>class called URLArchive in addition to the changes to two existing
>>>classes. Issue tracker has more details about the fix.
>>>
>>>Thanks,
>>>Sahoo
>>>
>>>
>>>
>>>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com