Taskdef weirdness - classloader issue?

[Mike Morris <mi...@coco-technologies.co.za>]

I have an external task defined with a taskdef along the lines of:

<taskdef name="foo"
     classname="org.foobar.ant.FooTask"
     classpathref="build.classpath"
/>

The jarfile containing this task is in ${ant.home}/lib.
So far, so good.

However FooTask depends on another set of classes in a different library 
"foobar.jar", and the build terminates with

	java.lang.ClassNotFoundException: org.foobar.morestuff.MoreFoo
	   at... [many lines of stacktrace]

Now "foobar.jar" containing the offending class(es) /is/ defined as part 
of the "build.classpath" (and verified, since the javac task in other 
targets is quite happy finding stuff in that library using the same 
build.classpath.)

If I copy (or link, tried both) "foobar.jar" into ${ant.home}/lib, I get 
a /different/ error:

	java.lang.reflect.InvocationTargetException
	    ...
	    Caused by: java.lang.VerifyError: (class: 
org/foobar/metadata/MetaDataElement, method: mergeElement signature: 
(Lorg/foobar/metadata/MetaDataElement;)V)
	    Incompatible object argument for function call

In the docs I see that since ant 1.5 one can define a loaderRef for a 
task, and this looks to me a lot like different classes being defined as 
different because they are being loaded by different classloaders.

Could some kind soul please point me at where to find out more about how 
to use the loaderRef to ensure that all classes are being loaded by the 
same classloader, or some other way to resolve/workaround this issue.

I am also told that the task works under ant 1.3, but have put in so 
much work on refactoring build scripts that I am loath to go backwards 
at this stage...

I am using Ant version 1.5, SunJDK build 1.4.1-b21 on Linux 
(2.4.something if that matters).

--
mike morris
cOcO software - "because you can't reboot the internet"

email: mike.morris (at) coco-technologies . co . za
ph:    (Local) 044 388 4635
        (Int'l) +27 44 388 4635

------- A day without chillies is a day wasted -------




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Taskdef weirdness - classloader issue?

[Mike Morris <mi...@coco-technologies.co.za>]

Thanks for the suggestion, but unfortunately it doesn't help.  I end up
with the same result (InvocationTargetException) when both jarfiles are
in some other (non ANT_HOME/lib) directory with an appropriate classpath
setting.

Conor MacNeill wrote:
> Mike Morris wrote:
> 
>> I have an external task defined with a taskdef along the lines of:
>>
>> <taskdef name="foo"
>>     classname="org.foobar.ant.FooTask"
>>     classpathref="build.classpath"
>> />
>>
>> The jarfile containing this task is in ${ant.home}/lib.
>> So far, so good.
>>
> 
> Actually No. Since the Task is in $ANT_HOME/lib the Tas class will be 
> loaded by the system loader (since all jars in ANT_HOME/lib are added to 
> the classpath prior to starting Ant). Since this class is loaded by the 
> taskdef's loader's parent, it cannot see classes available in the child 
> loader.
> 
> Try moving FooTask's jar out of ANT_HOME/lib and then creating a new 
> classpath containing the new loacation and the build.classpath. Use this 
> new path in the taskdef
> 
>> Could some kind soul please point me at where to find out more about 
>> how to use the loaderRef to ensure that all classes are being loaded 
>> by the same classloader, or some other way to resolve/workaround this 
>> issue.
>>
> 
> loaderrefs are there to ensure that multiple taskdefs/typedefs use the 
> same class loader which is not an issue for you since you are only doing 
> one taskdef.
> 
> 
> Conor
> 
> 
> 
> -- 
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 
> 

-- 
mike morris
cOcO software - "because you can't reboot the internet"

email: mike.morris (at) coco-technologies . co . za
ph:    (Local) 044 388 4635
         (Int'l) +27 44 388 4635

------- A day without chillies is a day wasted -------




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Taskdef weirdness - classloader issue?

[Conor MacNeill <co...@cortexebusiness.com.au>]

Mike Morris wrote:
> I have an external task defined with a taskdef along the lines of:
> 
> <taskdef name="foo"
>     classname="org.foobar.ant.FooTask"
>     classpathref="build.classpath"
> />
> 
> The jarfile containing this task is in ${ant.home}/lib.
> So far, so good.
> 

Actually No. Since the Task is in $ANT_HOME/lib the Tas class will be loaded 
by the system loader (since all jars in ANT_HOME/lib are added to the 
classpath prior to starting Ant). Since this class is loaded by the 
taskdef's loader's parent, it cannot see classes available in the child loader.

Try moving FooTask's jar out of ANT_HOME/lib and then creating a new 
classpath containing the new loacation and the build.classpath. Use this new 
path in the taskdef

> Could some kind soul please point me at where to find out more about how 
> to use the loaderRef to ensure that all classes are being loaded by the 
> same classloader, or some other way to resolve/workaround this issue.
> 

loaderrefs are there to ensure that multiple taskdefs/typedefs use the same 
class loader which is not an issue for you since you are only doing one taskdef.


Conor



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>