axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Meyer (JIRA)" <>
Subject [jira] Commented: (AXIS2-2995) Codegen bug with different namespaces (including proposed fix)
Date Wed, 05 Sep 2007 08:00:41 GMT


Christian Meyer commented on AXIS2-2995:

I found another problem in the generated code of

The method toOM that is called by Michaels fix shows some emty Strings that cause "localname
cannot be null or emty" errors. To avoid this error i changed the method as follows:

                private toOM(net.bipro.namespace.allgemein.CTProzessFehler
param, org.apache.axiom.soap.SOAPFactory factory, boolean optimizeContent) {
                    try {
                        javax.xml.bind.JAXBContext context = net_bipro_namespace_allgemein_CTProzessFehler;
                        javax.xml.bind.Marshaller marshaller = context.createMarshaller();
                        marshaller.setProperty(javax.xml.bind.Marshaller.JAXB_FRAGMENT, Boolean.TRUE);

                        JaxbRIDataSource source = new JaxbRIDataSource( net.bipro.namespace.allgemein.CTProzessFehler.class,
               namespace = factory.createOMNamespace("",
                        return factory.createOMElement(source, "cTProzessFehler", namespace);
                    } catch (javax.xml.bind.JAXBException bex){
                        throw new RuntimeException(bex);



> Codegen bug with different namespaces (including proposed fix)
> --------------------------------------------------------------
>                 Key: AXIS2-2995
>                 URL:
>             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
>            Reporter: Michael Pollmeier
>            Assignee: Amila Chinthaka Suriarachchi
>         Attachments:
> 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- -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:
> reflect.InvocationTargetException
>         at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(
>         at org.apache.axis2.wsdl.WSDL2Code.main(
>         at org.apache.axis2.wsdl.WSDL2Java.main(
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
>         at org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(
>         at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(
>         ... 2 more
> Caused by: java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(
>         ... 3 more
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>         at org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(
>         ... 8 more
> Caused by: java.lang.NullPointerException
>         at org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(
>         ... 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:
For additional commands, e-mail:

View raw message