I do not know if it solves this problem, but I think that it does. (but at a cost - this is not standard use of classloaders, the code uses reflection to access protected methods of URLClassloader). Peter
On 8/22/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
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]
