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