You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Christian Meyer (JIRA)" <ji...@apache.org> on 2007/09/05 10:00:41 UTC

[jira] Commented: (AXIS2-2995) Codegen bug with different namespaces (including proposed fix)

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

Christian Meyer commented on AXIS2-2995:
----------------------------------------

I found another problem in the generated code of EVBService2010MessageReceiverInOut.java.

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 org.apache.axiom.om.OMElement 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,
                                                                        param,
                                                                        marshaller,
                                                                        "http://www.bipro.net/namespace/allgemein",
                        												"cTProzessFehler");
                        org.apache.axiom.om.OMNamespace namespace = factory.createOMNamespace("",
                                                                           null);
                        return factory.createOMElement(source, "cTProzessFehler", namespace);
                    } catch (javax.xml.bind.JAXBException bex){
                        throw new RuntimeException(bex);
                    }
                }

===========================

Regards
Christian

> 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