Ant and thread context class loader

[Joerg Heinicke <jo...@gmx.de>]

Hi,

I have a problem with a library and an Ant task I wrote for it. Internally it
tries to get the thread context class loader to load a class:

  ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
  classLoader.loadClass(className);

Unfortunately, this does not work in Ant as it has its URLClassLoader set as
thread context ClassLoader. Now I searched around a bit about a correct way to
handle this and found two interesting things:

1. http://marc.theaimsgroup.com/?t=106433045400001&r=1&w=4

David Wood writes about a similar problem and solved it by using:

  // Get the task class loader we used to load this tag.
  AntClassLoader taskloader = (AntClassLoader)this.getClass().getClassLoader();

  // Shove it into the Thread, replacing the thread's ClassLoader:
  taskloader.setThreadContextLoader();

Then you do what you have to do. When your done, I highly advise doing a:

  // Reset the Thread's original ClassLoader.
  taskloader.resetThreadContextLoader();

Is this a proof way of working around the problem?

2. http://marc.theaimsgroup.com/?l=ant-dev&m=115723869001877&w=4

With this commit for a scripting environment something similar is done. I only
wonder why this is not done for every classpath-related task. Wouldn't that be
more proof? And is there any reason that in ScriptRunner the
AntClassLoader.setThreadContextLoader() feature is not used, but setting the
thread context class loader is done by hand?

Regards,
Jörg


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

Re: Ant and thread context class loader

[Peter Reilly <pe...@gmail.com>]

On 10/24/06, Joerg Heinicke <jo...@gmx.de> wrote:
> Hi,
>
> I have a problem with a library and an Ant task I wrote for it. Internally it
> tries to get the thread context class loader to load a class:
>
>   ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
>   classLoader.loadClass(className);
>
> Unfortunately, this does not work in Ant as it has its URLClassLoader set as
> thread context ClassLoader. Now I searched around a bit about a correct way to
> handle this and found two interesting things:
>
> 1. http://marc.theaimsgroup.com/?t=106433045400001&r=1&w=4
>
> David Wood writes about a similar problem and solved it by using:
>
>   // Get the task class loader we used to load this tag.
>   AntClassLoader taskloader = (AntClassLoader)this.getClass().getClassLoader();
>
>   // Shove it into the Thread, replacing the thread's ClassLoader:
>   taskloader.setThreadContextLoader();
>
> Then you do what you have to do. When your done, I highly advise doing a:
>
>   // Reset the Thread's original ClassLoader.
>   taskloader.resetThreadContextLoader();
>
> Is this a proof way of working around the problem?
>
> 2. http://marc.theaimsgroup.com/?l=ant-dev&m=115723869001877&w=4
>
> With this commit for a scripting environment something similar is done. I only
> wonder why this is not done for every classpath-related task.
Nearly all ant tasks are classpath related. (;-:), - for example taskdef,
it may not make sense for this to be done in general.

> Wouldn't that be
> more proof? And is there any reason that in ScriptRunner the
> AntClassLoader.setThreadContextLoader() feature is not used, but setting the
> thread context class loader is done by hand?
Ignorance on my part, also looking at the code (AntClassLoader), it
does something weird
depending on "build.sysclasspath", (which relates back to running in gump).

Peter

>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> 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