Matt Benson wrote:
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
Hi,
XSLT processing, and maybe other tasks would need a
method getURL() to be added to Resource.
Any thoughts on that ?
If we do it, do we do :
String() getURL()
or
java.net.URL getURL()
Hmm. I'm not smart enough for this. I guess we
probably should as file resources have urls. What
does that say for <url>? Is that a conflict, or is it
just the most generic of the "real" resource types?
If we make it part of the resource then I would think
we should use the actual URL type; in fact URLResource
already has this property, so it already implements
this. This way custom resource implementations could
create the URL they return with a custom
URLStreamHandler and the resulting URLs would be able,
with sufficient JVM permissions set, to behave
appropriately for whatever resource is declared. How
does this sound to anyone who cares?
ahh, now we are getting complex
Remember that (somehow) even JAR entries can become URLs (see
JarURLConnection)
jar:http://www.foo.com/bar/baz.jar!/COM/foo/Quux.class
Which even gives us insight into jar/zip files.
What we cannot do is trivally add a new tar: url, or the like, primarily
because the URLConnection logic is always implemented in the base
classloader, possibly restricted to extension libraries, I forget. All I
do know is that in some bit of smartfrog I had to add
classpath:some.resource.here URLs and had to make sure that everything
that wanted to load it had to use their own factory stuff.
Things that dont use the custom factory (like, say, Xalan), couldnt
handle custom URLs if they were passed down as strings, embedded into
XSL sheets, etc.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
