Hi,
Sorry, I was not on the original email list, but Sahoo noticed and forwarded it to me yesterday.
Yes, this should be updated to be that the url can refer to a JAR or to a directory containing the
exploded jar file contents.
-Mike
> -----Original Message-----
> From: Sanjeeb Kumar Sahoo [mailto:Sanjeeb.Sahoo_at_Sun.COM]
> Sent: Tuesday, March 07, 2006 11:15 PM
> To: Linda Demichiel
> Cc: persistence_at_glassfish.dev.java.net; Bill Shannon; Qingqing Ouyang
> Subject: Re: PersistenceInfo.getJarFiles() returning URL
>
>
> Hi Mike, Linda,
>
> Was it not agreed in the email below that this is going to be
> changed to
> at least allow File url in this release?
> I don't see this change in the final draft (dated 13 Feb 2006). The
> javadocs remains same as what it was in public review version
> of the spec:
>
> /**
> * @return The list of JAR file URLs that the persistence
> * provider must examine for managed classes of the persistence
> * unit. Each jar file URL corresponds to a named <jar-file>
> * element in the persistence.xml file.
> */
> public List<URL> getJarFileUrls();
>
> Please acknowledge.
>
> Thanks,
> Sahoo
>
> Mike Keith wrote:
>
> >>>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.
> >>>
> >>>
> >>Mike, as we've been discussing in our separate thread, the key is
> >>providing enough information in the spec that you can write
> a portable
> >>provider. Knowing that it can be any kind of URL at all
> isn't enough
> >>given what the provider has to be able to do. Requiring it
> >>to be either
> >>a file: URL or another URL from which you can get an
> InputStream that
> >>contains a jar file is sufficient, but let's just say it's not very
> >>object oriented. :-) Returning a new kind of object that abstracts
> >>the required operations, as Sahoo suggested, would be better, but I
> >>realize it's too late to fix that in this release.
> >>
> >>
> >
> >Absolutely. I was suggesting that for this draft we should limit
> >the URL to be one of those two types, but that before we are final we
> >should loosen it further. As I mentioned, I am certainly not averse
> >to tweaking the API to accomodate an abstraction of that, just not
> >right now!
> >
> >
> >
>
>
>
>