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
>>
>>