Antlib Class Loaders

Jose Alberto Fernandez

Let me first say that this feature appeared by the need to be able to say,

<antlib name="A" classpathref="XYZ"/>
<antlib name="B" classpathref="XYZ"/>

And being able to make sure that B and A use the same classLoader and therefore they can use each other components.

My solution at the time was this idea of a named classloader that you could define using a classpath, and then tell your antlibs use this or that classloader, if you use the same classloader visibility is guaranteed.

Stefan Bodewig 23.04.2003 17:11

I understand that usecase (using the same class loader for 2 different antlibs) and think it's important. See Steve Loughran's comment on the .NET tasks wanting to have access to the datatypes defined in the cpptasks project for example.

Take a look at what Costin had done to <taskdef> and <typedef> with the loaderref attribute. This has now (i.e. CVS HEAD) been generalized in ClasspathUtils, the infrastructure for named classloaders is there - at least the foundation for it.

Stefan

Costin Manolache 29.04.2003 18:52

The main issue is how to enforce ordering to deal with dependencies between the antlibs.

Or simply do not deal with dependencies, ie antlibs must not (yet) depend on on the other, except for the core ones.

Using an unified class loader ( at least as default ) - like jboss is doing, or like JMX loading policy - has a lot of benefits. It also has some cases that are not well covered - so we'll probably need to deal with both "unified loader" and "loader hierarchy" cases.