axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AXIS2-2995) Codegen bug with different namespaces (including proposed fix)
Date Fri, 28 Dec 2007 11:55:43 GMT

     [ https://issues.apache.org/jira/browse/AXIS2-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Amila Chinthaka Suriarachchi resolved AXIS2-2995.
-------------------------------------------------

    Resolution: Fixed

fixed the issue with  revision 607217

> Codegen bug with different namespaces (including proposed fix)
> --------------------------------------------------------------
>
>                 Key: AXIS2-2995
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2995
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: codegen
>    Affects Versions: 1.2
>         Environment: I already changed the JAXB RI jars to 2.1.3, but this isn't the
problem
>            Reporter: Michael Pollmeier
>            Assignee: Amila Chinthaka Suriarachchi
>         Attachments: wsdl.zip
>
>
> Axis codegen has a problem when there are objects with the same name in different namespaces.
I will upload a sample wsdl. If you use wsdl2java to create a service like this: wsdl2java
-uri EVBService-2.0.1.0.wsdl -ss -sd -d jaxbri -o service
> you will get an exception on console: 
> Exception in thread "main" org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException:
java.lang.
> reflect.InvocationTargetException
>         at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:256)
>         at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
>         at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
>         at org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:109)
>         at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:209)
>         ... 2 more
> Caused by: java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:98)
>         ... 3 more
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>         at org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:126)
>         ... 8 more
> Caused by: java.lang.NullPointerException
>         at org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:105)
>         ... 8 more
> ... which seems to be an "optimizable" design, because you do not see the real exception.
When I debugged the code I got the real exception: 
> >>>>>>>
> org.xml.sax.SAXParseException: A class/interface with the same name "net.bipro.www.namespace.evb.CTStatusResponse"
is already in use. Use a class customization to resolve this conflict.
> <<<<<<<<<<<<<
> I saw that JAXBs XJC compiler does not have any problems with our schema, so there had
to be a difference of parameters between xjc batch and axis2 codegen. So I found out that
if you comment out the statement "sc.setDefaultPackageName(pkg);" in CodeGenerationUtility:processSchemas(),
everything is generated just fine!
> This might have some side effects, so someone who really knows what happens down the
code should have a look at this. Maybe a solution would be to have another command line parameter
for wsdl2java to not set the default package.
> There is another, smaller problem which occurs when you use my bugfix:  when the code
is generated, the message receiver class cannot be compiled because of an obviously wrong
code: the method toOM() needs three parameters, but only two are submitted: toOM(e.getFaultMessage(),false));
> If you change it to toOM(e.getFaultMessage(), getSOAPFactory(msgContext), false), everything
can be compiled and works.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message