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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
