ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Rydahl Andersen" <max.ander...@jboss.com>
Subject Re: ant tasks creation of classloaders
Date Mon, 20 Jun 2005 05:42:20 GMT

> If you want your "local" classloader a childloader of the task's loader  
> you
> should - as of less classpath overhead - simply code
> new URLClassloader(this.getClass().getClassloader(),localClasspath)
> (and set it as ThreadContextClassloader) unless you want to support  
> things
> like "isolate"...

Is "isolate" what you call setParentFirst(false) ?

> Hope that helps a little bit

It did. So, the short answer to my initial question is: Yes, its ok to use
the tasks own classloader even though not many other tasks dod it ;)

/max

> Cheers
>
> Rainer
>
>> -----Original Message-----
>> From: Max Rydahl Andersen [mailto:max.andersen@jboss.com]
>> Sent: Saturday, June 18, 2005 11: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: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message