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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
