> This surprises me. You're positive you can change the system's
> classloader classpath dynamically just by assigning to this property?
The system property 'java.system.class.loader' is used to declare the name
of custom system classloader class. [...]
But as I pointed out, this is a JRE 1.4 feature.
Thanks for the precision. I missed the .loader part of the property
name, my mistake. OK, you are replacing the default system class
loader with your own. But I'd assume 'java.system.class.loader' is
thus a sys pty you need to specify at startup then, no?
b) declaration of the package paths under the
'java.protocol.handler.pkgs' system property - which is
more flexible in that the property value is mutable and
can be updated/extended at runtime
Ah, again I didn't know about that. Thinking back, I probably needed
to specify it on the command line because the custom protocol I was
declaring was used in XML entity includes, so used during the parsing
of the build file, and thus before I'd have the chance to change sys
properties with Ant.
This is principal reason why I suggested the
approach related to the 'java.protocol.handler.pkgs' property as this does
not interfere with nor depend on any URLStreamHandlerFactory declaration.
I like that, but if I read you correctly, you still need the special
sys class loader to locate these handlers if they are not already on
the sys class path, which implies replacing the sys class loader,
something problematic for embedded use of Ant.
All that said, to come back to Resource, as I previsouly wrote, you
can already use any URL as a resource in the build file. Resource is
akin to URL in the sense that it allows you to get access to streams.
The question is why would you need to get back a URL from a Resource?
I'm not sure yet. Maybe we should have a Resource.getURL but rather a
URLResource.getURL. I still don't see the point of forcing all
Resources to be URL-based.
"Normal" protocol URLs (file:, http:, etc...) are often "absolute", in
that they are context-free. The URL name is all you need to get back
at the same streams. Resources on the other hand, like a resource on
the classpath, is not "absolute", and will give you different results
depending on which classpath is used. The resource "name" is not
enough in itself to locate the streams. Sure you can wrap a single Ant
property value (just a String) into a URL using some custom handler,
but again the URL name (or path if you want) is meaningless. This is
this fondamental distinction between URLs and Resources which make me
reluctant to add a getURL method to the base Resource type (interface,
abstract class, I don't remember).
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
