Should work, but these issues typically require manipulation of the System Classloader (resp. User-Classloader). In Ant, this is the Launcher's Classloader whereas oata.Main, oata.Project and the rest are loaded via a System Classloader's childloader. As discussed in this list some years ago, it may produce curious results if a class is added to a parent-loader after it is used/load by a childloader. Handle with care!!! One can use <classloaderreport/> to debug classloader related issues.
Cheers Rainer > -----Original Message----- > From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 22, 2006 3:59 PM > To: dev@ant.apache.org > Subject: classloader and delegating classloader problem > > > Hello Peter and other, > > does this <classloader/> task address the delegating class > loader issue ? > > I am really not knowledgeable about classloaders myself, but > remember that I was not able to make a custom task based on > JNDI APIs work if the concrete JNDI driver to use (in this > case it was a JNDI driver for MQ Series) was not put on the > classpath before starting ant. I guess that the explanation > in this case is that my custom task invokes the standard JNDI > APIs (Context class) which is implemented in the Java > runtime, and that this one cannot find the classloader which > loaded my task anymore, so does not know about the JNDI driver. > > Would be cool if <classloader/> solves the problem. > > Regards, > > Antoine > > --------------------------------------------------------------------- > 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]
