ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer Noack" <>
Subject RE: What do you think about a <classloader> task ?
Date Mon, 29 Mar 2004 18:35:05 GMT
Hi Steve

Your security issues sounds very reasonable for me. 

I've never thought of this, as I've used the URL option rarely 
in practice and only for LAN access where security was irrelevant.
Another reason is, that I've no experience with this stuff.

Do you think, it could be a blocker?

What is the best solution in the case, there is nobody who is more
familiar with this stuff and implements the security issues now?
a) Contribute as is and document this issue in the task documentation
   until it's hopefully implemented later or
b) Change the task, so that it does not accept non-file URLs (should be 
   no big deal) or accepts only the original Path type instead of the
   extended one.


> -----Original Message-----
> From: Steve Loughran [] 
> Sent: Monday, March 29, 2004 3:35 PM
> To: Ant Developers List
> Subject: Re: What do you think about a <classloader> task ?
> Rainer Noack wrote:
> > Hi Ant developers,
> > 
> > After taskdef supports the loaderref attribute, I've
> > written a task that is able to 
> > 
> > a) append classpath entries to existing classloaders,
> > b) explicitely create classloaders,
> > c) put the actual path of a classloader into a property and
> > d) log a simple report about the currently classloaders.
> > 
> > Currently it supports URLClassLoader and AntClassLoader. It is
> > designed to simply support custom extensions for any arbitrary 
> > ClassLoader.
> > I've posted it some time ago - a little rash (sorry) - to this list.
> > 
> > However, as classpathes can completely managed from inside the 
> > build.xml,
> > this task has helped in several projects
> > 1. to avoid the need to either change Ant's default installation 
> >    by adding or removing jars to or from Ant's lib dir 
> >    or manage the classpath in the launching script and
> > 2. to avoid classpath-problems with custom tasks 
> >    (especially if they should - for whatever reason - be used 
> >     as jars in the same buildfile as they were created).
> > 
> This all seems useful, and is the logical extension of the 
> -lib option 
> to insert new stuff into the base classloader.
> I am currently busy doing classpath stuff and ant integration 
> with our 
> deployment framework (see 
One thing smartfrog does is lets you specify a codebase when describing 
a new app to host/deploy; that codebase takes URLs. now in security on 
mode, only signed and sealed URLs are allowed, but ignoring that detail, 
being able to spec URLs to where jars come from is very, very slick.

Security does matter; you dont want to have build files that go

   <add url="" />

without something saying 'is this a trusted release of junit'.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message