> -----Original Message-----
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 24 September 2006 1:27 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Actual mutation of the system classloader can be handled
> > with relative safety in JRE 1.4 and later via a system
> > property 'java.system.class.loader'
>
> This is news to me Steven. This implies that the system
> classloader would need to query this property to see if it
> changed any time it attempts to locate a new Class, no?
Nope.
> This surprises me. You're positive you can change the system's
> classloader classpath dynamically just by assigning to this property?
Lets take a step back for a moment.
The system property 'java.system.class.loader' is used to declare the name
of custom system classloader class. Given control over the system
classloader it is feasible to declare supplementary operations dealing with
content mutation. For example you could declare methods allowing the
addition and retraction of a classloader to be included in a stack of
classloaders to consulted before consulting the original classpath - and
operations allowing the addition/retraction of classloaders to be consulted
after evaluating the initial and overriding stacks. But as I pointed out -
this is a JRE 1.4 feature.
> You're description of URL custom handlers is pretty good, but
> you gloss over the registration of the custom handlers. Don't
> you still need to install your own handler factory?
Each custom protocol needs a URLStreamHandler which acts as a factory for
URLConnection instances. There are three approaches to handler
registration:
a) declaration of a URLStreamHandlerFactory - which is
problematic because only one instance may be declared for
a given JVM (and there are no chaining semantics) and
this is where complications can occur with applications
that are assigning their own factory
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
Option (b) is the strategy I described in an earlier post - in effect your
dealing with a property that contains a sequence of package names separated
by the '|' character where each package name is used to locate a protocol
handler using the convention '[package-name].[protocol-name].Handler'. A
task within Ant could update the value of this property which in turn would
enable JVM runtime location of custom handlers (assuming the handlers are
resolvable be the system classloader).
> Doesn't
> that require a JVM arg at startup, i.e. you cannot install it
> once the JVM is up?
You can modify the 'java.protocol.handler.pkgs' at runtime.
> I'm still concerned about the use of an
> embedded Ant regarding the custom handler factory.
> Maybe things have changed since I looked at them, but I felt
> that custom URL handlers' registration or discovery was not
> convenient or flexible enough the way the JDK implemented it.
I think the URLStreamHandlerFactory model fits this description. In effect
it does not provide an API to support runtime customization or multiple
factory declaration/chaining. 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.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
