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 "Michael Pollmeier (JIRA)" <ji...@apache.org> on 2007/07/21 13:31:07 UTC
[jira] Created: (AXIS2-2995) Codegen bug with different namespaces
(including proposed fix)
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2995) Codegen bug with different namespaces
(including proposed fix)
Posted by "Michael Pollmeier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Pollmeier updated AXIS2-2995:
-------------------------------------
Attachment: wsdl.zip
example wsdl for this issue
> 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
> 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
[jira] Commented: (AXIS2-2995) Codegen bug with different
namespaces (including proposed fix)
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514859 ]
Deepal Jayasinghe commented on AXIS2-2995:
------------------------------------------
Amila ,
Do you consider this as a blocker ?
Thanks
Deepal
> 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
[jira] Resolved: (AXIS2-2995) Codegen bug with different namespaces
(including proposed fix)
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-2995) Codegen bug with different
namespaces (including proposed fix)
Posted by "Christian Meyer (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (AXIS2-2995) Codegen bug with different namespaces
(including proposed fix)
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-2995:
----------------------------------------
Assignee: Amila Chinthaka Suriarachchi
> 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