> 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? > >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 Jose Alberto > > Peter > > > --------------------------------------------------------------------- > 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]
