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.
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
