ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@dpml.net>
Subject RE: Resource.getURL()
Date Fri, 22 Sep 2006 03:22:16 GMT
 

> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com] 
> Sent: Friday, 22 September 2006 11:44 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
> 
> > Just for reference I have quite a bit of experience working with 
> > custom protocol handlers.
> 
> OK, that's better than my casual experience with them. How do 
> you install them? What does it require in terms of JVM 
> startup arguments?

There are two primary mechanisms:

  * declaring a URLStreamHandlerFactory
  * declaring the 'java.protocol.handler.pkgs' system property

> Does that play well with application containers that often embed Ant?

The first option (the URLStreamHandlerFactory) can cause problems in that
only one factory may be declared and conflicts can arise with applications
that assume they have control over this resource.  The second option is more
flexible in that the system property value can be set within an application
and any existing declarations can be maintained because arguments are
separated by the '|' character (i.e. Ant can read in the value of the
property and supplement that value with any additional protocol package
names that are declared).

An example of the declaration of the 'java.protocol.handler.pkgs' system
property is:

  -Djava.protocol.handler.pkgs=net.dpml.transit

In this example the property value identifies a package path which will be
used to resolve a protocol handler.  In the case of the Transit resource
management system there are a number of protocols including 'artifact',
'link', and 'local'. When a URL is constructed the protocol is identified
(e.g. file:, http:, or in the case of Transit - artifact:).  The JVM uses
the combination of package path and protocol name to locate a protocol
handler using the convention:

  [package-path].[protocol-name].Handler

In the case of the DPML Transit artifact protocol [1] and handler [2] this
translates to the class:

  net.dpm.transit.artifact.Handler

Something to keep in mind is that the creation of a URL is handled inside
the system classloader.  As such when the JVM attempts to locate handler
classes, it is limited to classes that exist within the system classloader
or system extensions. Application normally deal with this constraint be
ensuring that the jar file containing protocol handlers is included in
system classloader or is installed as a JVM extension - however, an
alternative is to deploy a JVM with a mutable system classloader.

> > In the context of Ant this subject will inevitably link back to the 
> > subject of system classloader mutation.  Enabling the 
> > declaration of 
> > custom protocol handlers as a part of system classloader expansion 
> > would significantly simply things for applications such as Depot 
> > (which makes extensive use of custom handlers).  In fact the 
> > combination of system classloader mutation plus support for 
> custom URL 
> > handlers would contribute to a significant potential 
> simplification of 
> > Depot's extensions to the Ant project model and task some 
> task implementations.
> 
> You're loosing me a bit here ;-) As far as I understand them, 
> Ant's new Resource type is kind of a duplicate to URLs to get 
> access to some content (stream), but without the "location" 
> part. There's already a URLResource I believe, so whatever 
> URL the JVM already supports can be hooked up to a resource. 
> Why would Ant need to "mess" with custom URL handlers?

Custom handlers allow the introduction of alternative resource
identification and retrieval mechanisms.  For example - data could be
referenced using a query structure expressed as a url and the handler could
use the url to interrogate a remote database.  Another example is multiple
remote data sources (as is the case of the 'artifact' protocol). In these
example the custom URL enables the removal of logic concerning resource type
and associated retrieval mechanics from application code.  This results in
greater portability and easier long-term maintenance.

> I guess my position on these handlers depends on the ease to 
> install them to a running JVM, and the actual use cases 
> having them would solves. --DD

I'll need to get myself more up-to-date with the resource class and its
usage in Ant to answer this properly (which I'll do in the next few days).

Cheers, Steve.

[1] artifact protocol
http://www.dpml.net/transit/technical/artifact.html

[2] artifact protocol handler javadoc and source
http://www.dpml.net/api/dpml/1.0.2/net/dpml/transit/artifact/Handler.html


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message