axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Stafford <>
Subject Re: ant-java2wsdl classpath not being used by ComplexType: ref BUGs 14815 & 21950
Date Mon, 19 Jan 2004 21:08:00 GMT
I am using a version that I believe contains the fixes for these bugs. 
What I am trying to report is that there are still related issues when 
using complex types and get some feedback as to whether I'm doing it 
wrong or some insight as to how we can fix it.

Right now, the easiest fix is to remove the taskdef from the common task 
area and have it loaded from the type-specific areas so that they can 
impact the classpath for the taskdef. That works fine as is the 
originally stated work-around.

Davanum Srinivas wrote:

>Both bugs are marked as fixed. which means you should use the latest cvs :)
>--- Jim Stafford <> wrote:
>>I am having a problem getting 100% success with the classpath solutions 
>>for BUGs 14815 & 21950
>>I am using the <classpath> sub-element within the <ant-java2wsdl> task

>>to supply by classes. This works fine for WRAPPED, RPC, and MESSAGE 
>>styles. However, for DOCUMENT, it requires a type mapping:
>>"Please register a typemapping/beanmapping for 
>>When I went to create a typemapping for the Event class, following the 
>>example in the samples/ejb/ant-build.xml file
>><complextype classname="itis.ewm.soapdemo.axis2.wsdl.Event"
>>             namespace="${ws.namespace}"/>
>>It doesn't seem to locate the custom bean class:
>>java.lang.ClassNotFoundException: itis.ewm.soapdemo.axis2.wsdl.Event
>>        at 
>>In looking at, it is using 
>>the root classloader:
>>    public void register(TypeMapping tm) throws ClassNotFoundException {
>>        Class cl = Class.forName(className);
>>However, Java2WsdlAntTask added the new classpath to the AntClassLoader
>>        if (classpath != null) {
>>            AntClassLoader cl = new AntClassLoader(
>>                    getClass().getClassLoader(),
>>                    project,
>>                    classpath,
>>                    false);
>>            log("Using CLASSPATH " + cl.getClasspath(),
>>                    Project.MSG_VERBOSE);
>>            ClassUtils.setDefaultClassLoader(cl);
>>The two classes appear to be using different classloaders. I tried a 
>>quick fix to switch Class.forName() to ClassUtils.forName(), but 
>>suffered singleton initialization issues. The comment at the end of the 
>>bug "If if you really want it, it is going to keep you busy for some 
>>time..." made me think I needed to stop going down this path and go back 
>>to the approach that has everyone defining the taskdef with their class 
>>in the classpath (works).
>Davanum Srinivas -

View raw message