Sahoo,
Here are the candidate clarifications, which allow file urls, as
discussed in the earlier thread.
Please review:
/**
* @return The list of file: URLs or jar file URLs for the
* jar files or exploded jar file directories that the
* persistence provider must examine for managed classes of
* the persistence unit. Each URL corresponds to a named
* <jar-file> element in the persistence.xml file.
*/
public List<URL> getJarFileUrls();
/**
* @return The file: URL or jar file URL for the jar file or
* directory that is the root of the persistence unit. (If the
* persistence unit is rooted in the WEB-INF/classes directory,
* this will be the URL of that directory.)
*/
public URL getPersistenceUnitRootUrl();
thanks,
Linda
Sanjeeb Kumar Sahoo wrote:
> 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!
>>
>>
>>