ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: Resource.getURL()
Date Fri, 22 Sep 2006 14:50:21 GMT
--- Scott Stirling <scottstirling@gmail.com> wrote:

> DD asks:
> > > Does that play well with application containers
> that often embed Ant?
> 
> Stephen McConnell replies, in part:
> > 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.
> 
> What do you guys mean by "mutable system
> classloader?" This is
> intriguing but also smells suspicious to me, having
> worked with
> classloaders quite a bit over the years.
> 
> > > > 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).
> 
> Custom protocol handlers can, I know because I've
> done it, be handled
> in another way by building up support for them at
> the application
> layer. For example (from a an XML file for location
> metadata:
> 
> <map src="cp:maps/first-floor.png"
>          xSize="300" ySize="500" name="First
> Floor"/>
> 
> That src="cp:maps/first-floor.png" is handled in
> code that interprets
> any src attribute value beginning with "cp:" as a
> pointer to a
> resource that should be loaded from the classpath
> (the cp). This was
> added to support loading maps in a JUnit test
> context. When the "cp:"
> prefix is not present, the resource is interpreted
> as a file system
> resource.
> 
> This is a simple example. My point is just that
> custom protocol
> handlers could probably be handled as an application
> layer
> enhancement, as alternative to leveraging the JVM
> system settings,
> which is invasive and inconvenient to deploy,
> especially in embedded
> contexts.
> 
> > > > 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.
> 
> What is Depot?, if you don't mind me asking, late to
> the discussion.
> 
> > 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 think you're right. I remember a classic JavaWorld
> example using the
> protocol handler API to create one for working with
> the Windows
> registry. That said, in the embedded contexts where
> Ant often runs
> (IDEs, installers, app servers, other tools), it is
> arguably much more
> powerful for Ant to be able to control such things
> in its application
> layer rather than depending on system-level JVM
> configuration.
> 
> Where would these protocols appear from a user
> perspective? In build
> scripts? If that's the case, then I'd definitely say
> consider letting
> Ant handle them and convert them to standard URLs
> through a registry
> mechanism perhaps like the custom task registry.

Scott, are you talking about something like option (b)
that I described at the end of:

http://marc.theaimsgroup.com/?l=ant-dev&m=115885448826992&w=2

?

-Matt

> 
> > > 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
> 
> Scott Stirling
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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


Mime
View raw message