Please unsubscribe the [EMAIL PROTECTED] from your list.

-----Original Message-----
From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 18, 2005 2:44 PM
To: dev@ant.apache.org
Subject: ant tasks creation of classloaders

Hi guys,

Having some "fun" issues with classloading these days.

I have a task (HibernateTool) that is used like this:

     <taskdef name="hibernatetool"  
classname="org.hibernate.tool.ant.HibernateToolTask">
       <classpath path="[necessary hibernate libs]">
     </taskdef>


        <target name="exportddl" depends="compiletest"
description="Export the  
DDL to caveatemptor.ddl and DB">
         <hibernatetool destdir="${build.dir}">
             <classpath path="etc;${build.dir}/classes"/>
             <annotationconfiguration  
configurationfile="${classes.dir}/hibernate.cfg.xml"/>
             <hbm2ddl export="false" console="false" drop="false"  
create="true" outputfilename="caveatemptor.ddl" delimiter=";"/>
         </hibernatetool>
        </target>


Notice that the classpath of the taskdef and hibernatetool have no  
overlaps.

Until today I had the following code in the HibernateToolTask for
creating  
the classloader:

AntClassLoader loader = getProject().createClassLoader(classPath);
loader.setParent(getProject().getCoreLoader());
loader.setThreadContextLoader();

But when I run this stuff with the task above I get ClassNotFoundErrors

for annotations defined in hibernate.

This occurs because with the above classloader setup I effectively goes

around the <taskdef> classpath - it
will instead first look in the parent of the AntClassLoader I created
and  
this will be the system classloader which
of course know nothing about the hibernate specific classloaders.

Know my current work around for this is to do:

AntClassLoader loader = getProject().createClassLoader(classPath);
loader.setParent(this.getClass().getClassLoader()); <-- this is the  
HibernateToolTask instance
loader.setThreadContextLoader();

This will setup the right classloading sequence.

But i'm just curious of why this does not seem to be the default way of

doing things in the existing ant tasks ?

e.g. in LoadProperties is:
            ClassLoader cL = (classpath != null)
                 ? getProject().createClassLoader(classpath)
                 : LoadProperties.class.getClassLoader();

which for me says "ignore LoadProperties own classloader if i have a  
<classpath>"

and most other places they *only* uses the core task loader which for me

seems kinda strange (as it can give funny
sideeffects if not all classes used by the <taskdef> isn't loaded yet)

So, am I missing some crucial insight or is it just "random" how the  
current ant tasks setup their classloaders :) ?

Anyone which can think up any bad things with the classloader setup I
did  
here ?

/max





---------------------------------------------------------------------
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]

Reply via email to