Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
This things sound like we are using the wrong abstraction here.
<typedef/> inside an <antlib/> should use the antlib
classloader as the
parent for any subsequent classloader.
In this case the parent is the antlib classloader (it is the default
classloader).
So what happens if the toplevel antlib gets loaded from a different
classloader (because I defined classpaths and such). Would the
<typedef/>
inside pick-up that as the classloader? Or would it pickup some default
one?
Currently it would use the default ant classloader.
I do not see why that should cause an infinite recursion.
The problem is that the <typedef
resource="net/.../antlib.xml"> <classpath
path="cpptasks.jar"/> </typedef> in the antlib will pick up
the antlib.xml resoure that contains <typedef
resource="net/.../antlib.xml">
task which will pick up .....,
This does not happen with the current ant code, as the <typedef
resource="net/.../antlib.xml">
<classpath path="cpptasks.jar"/></typedef>
task will not see the antlib.xml resource in the parent classloader.
Another way to work-around this is for the typedef to use a thread
specific stack to check
for recursive loading of xml resources.
This probally should be done in any case:
recursive.xml
<antlib>
<typedef file="recursive.xml"/>
</antlib>
build.xml:
<project>
<typedef file="recursive.xml"/>
</project>
What is the difference between this and what we do for <import/>s.
In both cases we need to make sure we do not go into an infinite loop.
It should not matter whether the XML is an import fragment or an
antlib.xml
Yes, that that the point!.
A warning should be issued and the antlib should not be loaded again.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
