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. Regards, Rainer > -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > 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 > http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/ant/doc/ant_task s.sxi). 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 <codebase> <add url="http://gump.apache.org/latest/junit/dist/junit.jar"; /> <codebase> without something saying 'is this a trusted release of junit'. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
