Hi Mike,
I have not seen any changes in the spec on this issue, so I am having
to raise it again. I see this as a major issue in plugging in different
providers with containers. In fact this was the first problem we faced
when we integrated TopLink with Sun's container. At that time TopLink
Essential was modified to work with a File URL. If the EG has no time to
make the suggested change (see the email thread below) in the SPI, then
let's at least reword the spec so that the returned URL can be either a
File URL or a jar file URL. That way we will at least have a spec
compliant integration of container and provider in the reference
implementation which is lacking today.
Thanks,
Sahoo
Mike Keith wrote:
>Hi Sahoo,
>
>Thanks for the suggestion. Unfortunately we really do need to
>spend our remaining spec time doing the stuff that absolutely needs
>to be done. This demands that we be very discriminating with the things
>we choose to do. Being that the deployment API does not even support
>deployment of exploded EAR files, or non-module/EAR deployments,
>this probably wouldn't make the cut. Thanks, though.
>
>-Mike
>
>
>
>>-----Original Message-----
>>From: Sanjeeb Kumar Sahoo [mailto:Sanjeeb.Sahoo_at_Sun.COM]
>>Sent: Wednesday, August 10, 2005 6:50 PM
>>To: ejb3-toplink-ext_at_sun.COM; Mike Keith
>>Subject: PersistenceInfo.getJarFiles() returning URL
>>
>>
>>Hi Mike,
>> Given the experience while integrating TopLink with glassfish, I am
>>of the opinion that JSR 220 EG should take a look at the
>>return type of
>>PersistenceInfo.getJarFiles(). If persistence provider is always
>>expecting the URL to point to a Jar file, then why use URL instead of
>>JarFile? Having said that I am not actually suggesting the return type
>>to be changed to JarFile. The issue with such a return type is that it
>>expects certain physical representation of the archive. e.g. some
>>appservers like glassfish may like to support directory based
>>deployment
>>and in that case, the server has to create a JarFile just for this
>>purpose. So I am thinking having an SPI that represents an archive may
>>help in better pluggability and may require less knowledge about the
>>actual representation of the archive. The SPI in my mind is something
>>like this:
>>
>>package javax.persistence.spi;
>>public interface Archive {
>> /**
>> * Returns an enumeration of the module file entries. Each String
>>represents
>> * a file name relative to the root of the module.
>> */
>> java.util.Enumeration<String> getEntries() throws
>>java.io.IOException;
>>
>>
>> /**
>> * Returns the InputStream for the given entry name The entry name
>>must be
>> * relative to the root of the module.
>> *
>> * @param entryPath the file name relative to the root of
>>the module.
>> * @return the InputStream for the given entry name or null if not
>>found.
>> */
>> java.io.InputStream getEntry(String entryPath) throws IOException;
>>}
>>
>>
>>
>>and then change PersistenceInfo.getJarFiles()'s return type to
>>List<Archive>.
>>
>>I would like to get your comments on this.
>>
>>Thanks & regards,
>>Sahoo
>>
>>
>>
>>