Hi Sahoo,
Agreed. We will loosen the language in the javadoc to include at least those
two types, and I think in the end we should not even be that restrictive.
After this draft we will look at loosening the language and perhaps even
adjusting the API if necessary.
Thanks,
-Mike
> -----Original Message-----
> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM]On Behalf Of
> Sanjeeb Kumar Sahoo
> Sent: Thursday, December 01, 2005 7:13 AM
> To: Mike Keith
> Cc: persistence_at_glassfish.dev.java.net; Qingqing Ouyang; Bill Shannon
> Subject: Re: PersistenceInfo.getJarFiles() returning URL
>
>
> 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
> >>
> >>
> >>
> >>
>
>