axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: ant-java2wsdl classpath not being used by ComplexType: ref BUGs 14815 & 21950
Date Fri, 16 Jan 2004 17:10:37 GMT
Both bugs are marked as fixed. which means you should use the latest cvs :)

--- Jim Stafford <jcstaff@apl.jhu.edu> 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 
> 'itis.ewm.soapdemo.axis2.wsdl.Event'"
> 
> 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 
> org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1075)
> 
> In looking at org.apache.axis.tools.ant.wsdl.ComplexType, 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).
> 
> comments?
> jim
> 
> 


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message