Bug 28228

Summary: <classloader> task
Product: Ant Reporter: Rainer Noack <rainer>
Component: Core tasksAssignee: Ant Notifications List <notifications>
Status: NEW ---    
Severity: enhancement CC: dsb, gabriele.garuglieri, Martin.vGagern, meinc, robert.flaherty
Priority: P3    
Version: 1.7.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: new files for proposed patch
changes (diff) for proposed patch
new files for proposed patch (with correct mimetype,sorry) replaces attach_id #11152
new files for proposed patch (last try with now - hopefully - correct mime-type)
again: new files for proposed patch. replaces attachment from 04/07/04 21:22
modified diff (if also required), replaces attachment from 04/06/04 11:19

Description Rainer Noack 2004-04-06 11:14:11 UTC
This is the "formal" enhancement request for a <classloader>
task. In it's actual form, it has been introduced in the developer's 
mailing list. 
(see: http://marc.theaimsgroup.com/?l=ant-dev&m=108055794609605&w=2)

I would like to reactivate and extend the current "sleeping" <classloader>
task with a patch 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.

Advantages 
----------
As classpathes can completely managed from inside the build.xml, 
this task can help
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).

b) and c) can be used to easily sync other task's classpathes and 
d) might be helpful to debug some classpath problems and understand classloader
behaviour ;-)

Disadvantages
-------------
The most frequent raised objection is, that adding classpathes to existing
parent classloaders in a delegation hierarchy may lead to situations where 
one class is loaded by two different classloaders in a delegation hierarchy
at the same time. This will most likely cause linkage errors and mysterious 
failures.
(See: http://marc.theaimsgroup.com/?l=ant-dev&m=106389211508059&w=2
  and http://marc.theaimsgroup.com/?l=ant-dev&m=104080215031773&w=2)
Another point is the risk of security loopholes if URLs are used as classpath 
entries.

Both objections are reasonable but IMHO, the advantages outweigh them.
* The aforesaid potential risks are described in the task documentation.
* As this task is new, it can not endanger existing builds. 
* Advanced users have the possibility to break the above-mentioned
  requirements.
  
Regards,
Rainer

P.S. Adding this task to the external task list is dissatisfying IMHO,
     as it shoots the major advantage (1.) down.
Comment 1 Rainer Noack 2004-04-06 11:17:48 UTC
Created attachment 11152 [details]
new files for proposed patch
Comment 2 Rainer Noack 2004-04-06 11:19:34 UTC
Created attachment 11153 [details]
changes (diff) for proposed patch
Comment 3 Rainer Noack 2004-04-06 11:40:39 UTC
oops, i've seen, that the first attachment can not be opened.
it's the patch.tar.gz resulting from the patch.xml.
how should i contribute it? what is the correct classification/mine-type?
sorry,
Rainer
Comment 4 Rainer Noack 2004-04-07 21:11:57 UTC
Created attachment 11178 [details]
new files for proposed patch (with correct mimetype,sorry) replaces attach_id #11152
Comment 5 Rainer Noack 2004-04-07 21:22:56 UTC
Created attachment 11179 [details]
new files for proposed patch (last try with now - hopefully - correct mime-type)
Comment 6 peter reilly 2004-05-11 08:27:00 UTC
It looks like some files are missing for the tar.gz file:
the classloaders in the o.a.t.a.taskdefs.classloader
package:
AntClassLoaderAdapter
SimpleClassLoaderAdapter
URLClassLoaderAdapter
Comment 7 Rainer Noack 2004-05-14 00:29:37 UTC
oops. peter, you're right.
sorry, I didn't noticed that.
may i send you the 3 files as a zip?
regards,
rainer
Comment 8 peter reilly 2004-05-14 09:59:23 UTC
Just attach them to the bugzilla report.
Cheers,
Peter.
Comment 9 Rainer Noack 2004-05-15 10:15:51 UTC
Created attachment 11562 [details]
again: new files for proposed patch. replaces attachment from 04/07/04 21:22
Comment 10 Rainer Noack 2004-05-15 10:42:38 UTC
Created attachment 11563 [details]
modified diff (if also required), replaces attachment from 04/06/04 11:19
Comment 11 Gabriele Garuglieri 2005-02-02 10:49:47 UTC
I added a vote for this enhancement that i find really useful and, at least for
my needs, works like a charm.
Actually i extracted the patch and built it as a separate package that i plan to
use for our internal build system, but i hope to see it soon on afficial Ant
release so that i won't have to carry around an additional jar.
I'm aware of the security risks that it exposes, but, once well documented, i
think the advantages largely override them.
I maintained all the code comments and ownership, so i hope Rainer has nothing
contrary to what i did.
Regards,  Gabriele.
Comment 12 Peter Reilly 2005-06-02 16:08:23 UTC
I am looking at this again.
It would be nice to make a number of changes:

1) the task import sun.import sun.misc.Launcher and import sun.misc.URLClassPath.
   It would be better not to import sun.* classes in non-optional tasks. A
   solution to this would be make the report function a seperate optional task.

2) the task could check if a jar or directort is already in a in the classpath
   I found when testing that it is easy to get into a situation where the
   classpath will have the same jar file many times - due to calls to
   <classloader> with using netbeans

3) the doc could state that use of this task in ides that do not
   have a separate jvm for a run of ant will cause issues - the
   classpath will be retained by the ide and used in the next
   ant build run
Comment 13 Rainer Noack 2005-09-05 22:14:13 UTC
A new version of this functionality is available as an external task for trial 
purposes on

http://jtools.org/ant-classloadertask/

This version solves some delegation hierarchy problems (see 
http://issues.apache.org/bugzilla/show_bug.cgi?id=35436) and follows peter's 
suggestions. The report functionality is removed into a separate task.
Because I've also used the functionality in other contexts, I've separated the 
customisation framework from the Ant specific classes to increase it's 
reusability.

As I'm not perfectly happy with this implementation (a little bit too 
sophisticated IMHO) I will think about some simplification before providing an 
updated patch.

Any comments welcome!

Cheers

Rainer
Comment 14 Robert 2005-10-28 14:54:24 UTC
*** Bug 37223 has been marked as a duplicate of this bug. ***
Comment 15 Steve Loughran 2006-05-18 10:03:15 UTC
What are we going to do with this. Something for Ant1.7? 

Being able to patch the classloader can screw up IDEs, but its nice for adding
antlibs on the fly
Comment 16 Stefan Bodewig 2008-11-14 06:23:14 UTC
*** Bug 8722 has been marked as a duplicate of this bug. ***
Comment 17 Mario Frasca 2009-10-07 04:31:45 UTC
I came across this request while trying to solve a problem I was having with the ftp task: the class implementing the task itself is loaded, but a library on which the task relies is not found.  I am executing a ant.jar (java -jar ant.jar) so I can't specify the classpath (I know I can invoke the Main class from that jar adding all jars I need to the classpath, but I like the compact invocation form).

I tried the classloader thing described here (actually the version in SVN) but it does not do much about my issue, at least not until I add some code that would hack the global classpath, adding the jars there, not the ant classloader.

would it be an idea to add an option (maybe a reserved name?) to have this task alter the global classpath?

a working way to alter the classpath (it's what I've been successfully using) is described here: http://forums.sun.com/thread.jspa?threadID=300557&start=49
Comment 18 Martin von Gagern 2014-11-29 01:20:24 UTC
I've tried to integrate this patch with current master, the result is here: https://github.com/gagern/ant/compare/28228-classloader

I've noticed this while working on bug #47003. I must say, however, that this is a rather big change in this patch here. So far I haven't gotten it to compile yet. And I don't fully understand it either.

(In reply to Mario Frasca from comment #17)
> a working way to alter the classpath (it's what I've been successfully
> using) is described here:
> http://forums.sun.com/thread.jspa?threadID=300557&start=49

Unfortunately that page is not available any more.