[jira] Created: (AXIS2-4630) ADB generates code that doesn't compile when WSDL has abstract types.
ADB generates code that doesn't compile when WSDL has abstract types. - Key: AXIS2-4630 URL: https://issues.apache.org/jira/browse/AXIS2-4630 Project: Axis2 Issue Type: Bug Components: adb Affects Versions: 1.5.1 Reporter: Aaron Gourley In ADBBeanTemplate.xsl, occurrences of the following exist without taking into consideration the fact that the class may have been declared as abstract: new (); Classes are declared abstract if @isAbstract='true' here (also in ADBBeanTemplate.xsl): abstract Obviously, abstract classes can not be instantiated directly. Specifically I am seeing the problem in the generated Factory.fromString() method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4356) WSDL2Java doesn't support xsd:elem...@fixed
WSDL2Java doesn't support xsd:elem...@fixed
---
Key: AXIS2-4356
URL: https://issues.apache.org/jira/browse/AXIS2-4356
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: adb, codegen, wsdl
Affects Versions: 1.4.1
Environment: Java 6
Reporter: Aaron Gourley
Priority: Minor
For reference, the default and fixed constraints are defined here:
http://www.w3.org/TR/xmlschema-1/#e-value_constraint
Consider the following XML schema definitions:
ADB code generated for the ResultCode element is correct in setting the default
value of the code field to 0:
protected long localCode =
org.apache.axis2.databinding.utils.ConverterUtil.convertToLong("0");
ADB code generated for the SuccessCode element is incorrect according to XSD
definition for the fixed element. It actually appears to completely ignore the
fixed attribute. Considering the XSD definition for the fixed attribute, I
think the generated code should declare the code field as final and set the
final value as follows:
protected final long localCode =
org.apache.axis2.databinding.utils.ConverterUtil.convertToLong("0");
It follows that the generated code should not contain a setter method for the
code field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
[ https://issues.apache.org/jira/browse/AXIS2-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594099#action_12594099 ] Aaron Gourley commented on AXIS2-3635: -- Upon furthur investigation, I'm convinced that there is no "easy" fix for these issues in 1.4. Some of the issues are fixed by my proposition, but not the new ones. I found that in Axis2 1.3 the response objects are not unwrapped when unwrapping is enabled, so the code compiled fine and was only mildly inconvenient since manual unwrapping of responses was required. Axis2 1.4 saw a bunch of checks added to a bunch of the main XSLTs. Searching the codegen module for "=0) and ($isUnwrapParameters)" should find all of the occurrences. The ones I found are: MessageReceiver.xsl: ($returnparamcount=0) and ($isUnwrapParameters) InterfaceTemplate.xsl: ($outputparamcount=0) and ($isUnwrapParameters) InterfaceImplementationTemplate.xsl: ($outputparamcount=0) and ($isUnwrapParameters) SkeletonInterfaceTemplate.xsl: ($outputparamcount=0) and ($isUnwrapParameters) SkeletonTemplate.xsl: ($outputparamcount=0) and ($isUnwrapParameters) CallbackHandlerTemplate.xsl: ($outParamCount=0) and ($isUnwrapParameters) The problem introduced here is that the param count is ALWAYS 0 when the xmlbeans databinding is used, because it is ONLY initialized for the adb databinding (see org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension:110-116 "//TODO: support xmlbeans"). As a result, all methods are generated as 'void' methods. Removing the explicit "adb" check in the SchemaUnwrapperExtension allowed me to generate the unwrapped code, but unfortunately the XmlbeansDatabindingTemplate.xsl needs a plethora of getXXX() and wrapXXX() methods added. The ADBDatabindingTemplate.xsl can be referred to when trying to determine which ones are missing. Hope this helps you get closer to resolving the issue. Let me know if you need me to clarify anything. > Compilation errors encountered when using XMLBeans databinding with > unwrapping enabled > -- > > Key: AXIS2-3635 > URL: https://issues.apache.org/jira/browse/AXIS2-3635 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen, databinding >Affects Versions: 1.4, 1.3 >Reporter: Aaron Gourley >Assignee: Amila Chinthaka Suriarachchi > Attachments: parlayx.zip, XmlbeansDatabindingTemplate-modified.xsl > > > Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and > WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the > bug still exists in 1.4 RC1. > Axis2 1.4 RC1 seems to have new issues too: > 1. Skeleton/SkeletonInterface methods are incorrectly generated with void > return types when XMLBeans databinding is used with unwrapping enabled. The > return types are correct with unwrapping disabled. They are also correct > when using ADB in both scenarios. > 2. A call to an invalid wrapXXX() method is generated (possibly related to > the void return type issue). -- 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]
[jira] Updated: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
[ https://issues.apache.org/jira/browse/AXIS2-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Gourley updated AXIS2-3635: - Attachment: XmlbeansDatabindingTemplate-modified.xsl Attaching proposed fix for Axis2 1.3. This does not address the new issues that I identified for Axis2 1.4. > Compilation errors encountered when using XMLBeans databinding with > unwrapping enabled > -- > > Key: AXIS2-3635 > URL: https://issues.apache.org/jira/browse/AXIS2-3635 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen, databinding >Affects Versions: 1.4, 1.3 >Reporter: Aaron Gourley >Assignee: Amila Chinthaka Suriarachchi > Attachments: parlayx.zip, XmlbeansDatabindingTemplate-modified.xsl > > > Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and > WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the > bug still exists in 1.4 RC1. > Axis2 1.4 RC1 seems to have new issues too: > 1. Skeleton/SkeletonInterface methods are incorrectly generated with void > return types when XMLBeans databinding is used with unwrapping enabled. The > return types are correct with unwrapping disabled. They are also correct > when using ADB in both scenarios. > 2. A call to an invalid wrapXXX() method is generated (possibly related to > the void return type issue). -- 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]
[jira] Commented: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593347#action_12593347
]
Aaron Gourley commented on AXIS2-3651:
--
It is my feeling that if Datelin is right about this, then it is a problem with
the deserialization which in turn needs to be fixed. It seems clear to me that
from a SOAP perspective the xsi:type attribute should be meaningful with
regards to the WSDL (i.e. identify the schema type as defined in the WSDL). In
general, the class name doesn't tell a generic SOAP client anything about the
elements type, since the class name doesn't appear in the WSDL.
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
>
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
>Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
>Reporter: Aaron Gourley
>Assignee: nadir amra
>Priority: Minor
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
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]
[jira] Commented: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
[ https://issues.apache.org/jira/browse/AXIS2-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582416#action_12582416 ] Aaron Gourley commented on AXIS2-3635: -- Is there any chance that this will be fixed for Axis2 1.4 final? I see RC2 was recently released. > Compilation errors encountered when using XMLBeans databinding with > unwrapping enabled > -- > > Key: AXIS2-3635 > URL: https://issues.apache.org/jira/browse/AXIS2-3635 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen, databinding >Affects Versions: 1.4, 1.3 >Reporter: Aaron Gourley >Assignee: Amila Chinthaka Suriarachchi > Attachments: parlayx.zip > > > Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and > WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the > bug still exists in 1.4 RC1. > Axis2 1.4 RC1 seems to have new issues too: > 1. Skeleton/SkeletonInterface methods are incorrectly generated with void > return types when XMLBeans databinding is used with unwrapping enabled. The > return types are correct with unwrapping disabled. They are also correct > when using ADB in both scenarios. > 2. A call to an invalid wrapXXX() method is generated (possibly related to > the void return type issue). -- 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]
[jira] Created: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
BeanUtil class should try and fill the xsi:type attribute with value from type
table before defaulting to class name
Key: AXIS2-3651
URL: https://issues.apache.org/jira/browse/AXIS2-3651
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: databinding
Affects Versions: 1.3, 1.4
Environment: Windows XP SP2, Java 6
Reporter: Aaron Gourley
Priority: Minor
Using the type table to fill the xsi:type attribute would help make it possible
to successfully validate SOAP response messages against the WSDL. Although the
class name approach may be sufficient for POJO services, it provides
meaningless information when other approaches are used.
I suggest replacing the following lines of BeanUtil.java
// Added objectAttributes as a fix for issues AXIS2-2055 and
AXIS2-1899 to
// support polymorphism in POJO approach.
// For some reason, using QName(Constants.XSI_NAMESPACE, "type",
"xsi") does not generate
// an xsi:type attribtue properly for inner objects. So just using
a simple QName("type").
ArrayList objectAttributes = new ArrayList();
objectAttributes.add(new QName("type"));
objectAttributes.add(beanObject.getClass().getName());
With this (or similar ... not sure if qualified check should be there):
ArrayList objectAttributes = new ArrayList();
objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
"xsi"));
if( typeTable != null && qualified )
{
QName qNamefortheType =
typeTable.getQNamefortheType(beanObject.getClass().getName());
if (qNamefortheType == null) {
// Added objectAttributes as a fix for issues AXIS2-2055
and AXIS2-1899 to
// support polymorphism in POJO approach.
objectAttributes.add(beanObject.getClass().getName());
}
else
{
objectAttributes.add(qNamefortheType);
}
}
else
{
objectAttributes.add(beanObject.getClass().getName());
}
Note that I had no issues with generating the xsi:type attribute for inner
elements in my testing (as was mentioned by the existing comment).
--
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]
[jira] Commented: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
[ https://issues.apache.org/jira/browse/AXIS2-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580391#action_12580391 ] Aaron Gourley commented on AXIS2-3635: -- WSDL2Java arguments: -p com.redknee.service.parlayx.location.wsdl -o /tmp/build\InterfaceParlayx\trunk\/interface/parlayx\trunk -S src\java -R classes\com\redknee\service\parlayx\location\wsdl\axis2 -sn TerminalLocation -pn TerminalLocation -g -ss -ssi -sd -d xmlbeans -wv 1.1 -ns2p http://www.csapi.org/schema/parlayx/common/v2_0=com.redknee.service.parlayx.location.wsdl.axis2.common,http://www.csapi.org/schema/parlayx/terminal_location/v2_0=com.redknee.service.parlayx.location.wsdl.axis2.terminal.location,http://www.csapi.org/schema/parlayx/terminal_location/v2_0/local=com.redknee.service.parlayx.location.wsdl.axis2.terminal.location.local -u -uw -uri /redknee//interface/parlayx/trunk\src/wsdl/parlayx_terminal_location_service_2_0.wsdl > Compilation errors encountered when using XMLBeans databinding with > unwrapping enabled > -- > > Key: AXIS2-3635 > URL: https://issues.apache.org/jira/browse/AXIS2-3635 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen, databinding >Affects Versions: 1.4, 1.3 >Reporter: Aaron Gourley > Attachments: parlayx.zip > > > Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and > WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the > bug still exists in 1.4 RC1. > Axis2 1.4 RC1 seems to have new issues too: > 1. Skeleton/SkeletonInterface methods are incorrectly generated with void > return types when XMLBeans databinding is used with unwrapping enabled. The > return types are correct with unwrapping disabled. They are also correct > when using ADB in both scenarios. > 2. A call to an invalid wrapXXX() method is generated (possibly related to > the void return type issue). -- 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]
[jira] Updated: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
[ https://issues.apache.org/jira/browse/AXIS2-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Gourley updated AXIS2-3635: - Attachment: parlayx.zip Attaching WSDL > Compilation errors encountered when using XMLBeans databinding with > unwrapping enabled > -- > > Key: AXIS2-3635 > URL: https://issues.apache.org/jira/browse/AXIS2-3635 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen, databinding >Affects Versions: 1.4, 1.3 >Reporter: Aaron Gourley > Attachments: parlayx.zip > > > Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and > WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the > bug still exists in 1.4 RC1. > Axis2 1.4 RC1 seems to have new issues too: > 1. Skeleton/SkeletonInterface methods are incorrectly generated with void > return types when XMLBeans databinding is used with unwrapping enabled. The > return types are correct with unwrapping disabled. They are also correct > when using ADB in both scenarios. > 2. A call to an invalid wrapXXX() method is generated (possibly related to > the void return type issue). -- 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]
[jira] Created: (AXIS2-3635) Compilation errors encountered when using XMLBeans databinding with unwrapping enabled
Compilation errors encountered when using XMLBeans databinding with unwrapping enabled -- Key: AXIS2-3635 URL: https://issues.apache.org/jira/browse/AXIS2-3635 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: codegen, databinding Affects Versions: 1.3, 1.4 Reporter: Aaron Gourley Attachments: parlayx.zip Attaching modified version of Axis2 1.3's XmlbeansDatabindingTemplate.xsl and WSDL used to exploit this bug. This fix worked for me in Axis2 1.3, and the bug still exists in 1.4 RC1. Axis2 1.4 RC1 seems to have new issues too: 1. Skeleton/SkeletonInterface methods are incorrectly generated with void return types when XMLBeans databinding is used with unwrapping enabled. The return types are correct with unwrapping disabled. They are also correct when using ADB in both scenarios. 2. A call to an invalid wrapXXX() method is generated (possibly related to the void return type issue). -- 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]
[jira] Updated: (AXIS2-3634) NullPointerException during codegen when using JaxB RI databinding
[
https://issues.apache.org/jira/browse/AXIS2-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Gourley updated AXIS2-3634:
-
Attachment: parlayx.zip
WSDL exploiting JAXB RI bug.
> NullPointerException during codegen when using JaxB RI databinding
> --
>
> Key: AXIS2-3634
> URL: https://issues.apache.org/jira/browse/AXIS2-3634
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: codegen
>Affects Versions: 1.4, 1.3
> Environment: Windows XP, Java 6
>Reporter: Aaron Gourley
> Attachments: parlayx.zip
>
>
> I was able to get around the following exception by replacing
> org.apache.axis2.jaxbri.CodeGenerationUtility line 125 of Axis2 1.4 RC1 as
> follows (in anonymous EntityResolver.resolveEntity())
> Replace this: if (key.getTargetNamespace().equals(publicId)) {
> With this: if (key.getTargetNamespace() != null &&
> key.getTargetNamespace().equals(publicId)) {
> Additionally, I'm not sure if it would be acceptable to skip the for loop all
> together if publicId is null.
> The exception that I encountered was:
> 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:271)
> at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
> at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
> Caused by: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:112)
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> ... 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:597)
> at
> org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:101)
> ... 3 more
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:307)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility$1.resolveEntity(CodeGenerationUtility.java:125)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:296)
> at
> com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:274)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:148)
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:193)
> ... 8 more
> I will attach a WSDL that exploits this issue and the WSDL2Java parameters
> used.
--
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]
[jira] Commented: (AXIS2-3634) NullPointerException during codegen when using JaxB RI databinding
[
https://issues.apache.org/jira/browse/AXIS2-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580373#action_12580373
]
Aaron Gourley commented on AXIS2-3634:
--
WSDL2Java arguments:
-p com.redknee.service.parlayx.location.wsdl
-o /tmp/build\InterfaceParlayx\trunk\/interface/parlayx\trunk
-S src\java
-R classes\com\redknee\service\parlayx\location\wsdl\axis2
-sn TerminalLocation
-pn TerminalLocation
-g
-ss
-ssi
-sd
-d jaxbri
-wv 1.1
-ns2p
http://www.csapi.org/schema/parlayx/common/v2_0=com.redknee.service.parlayx.location.wsdl.axis2.common,http://www.csapi.org/schema/parlayx/terminal_location/v2_0=com.redknee.service.parlayx.location.wsdl.axis2.terminal.location,http://www.csapi.org/schema/parlayx/terminal_location/v2_0/local=com.redknee.service.parlayx.location.wsdl.axis2.terminal.location.local
-u -uri
/redknee//interface/parlayx/trunk\src/wsdl/parlayx_terminal_location_service_2_0.wsdl
> NullPointerException during codegen when using JaxB RI databinding
> --
>
> Key: AXIS2-3634
> URL: https://issues.apache.org/jira/browse/AXIS2-3634
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: codegen
>Affects Versions: 1.4, 1.3
> Environment: Windows XP, Java 6
>Reporter: Aaron Gourley
>
> I was able to get around the following exception by replacing
> org.apache.axis2.jaxbri.CodeGenerationUtility line 125 of Axis2 1.4 RC1 as
> follows (in anonymous EntityResolver.resolveEntity())
> Replace this: if (key.getTargetNamespace().equals(publicId)) {
> With this: if (key.getTargetNamespace() != null &&
> key.getTargetNamespace().equals(publicId)) {
> Additionally, I'm not sure if it would be acceptable to skip the for loop all
> together if publicId is null.
> The exception that I encountered was:
> 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:271)
> at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
> at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
> Caused by: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:112)
> at
> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> ... 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:597)
> at
> org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:101)
> ... 3 more
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:307)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility$1.resolveEntity(CodeGenerationUtility.java:125)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:296)
> at
> com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394)
> at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:274)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:148)
> at
> org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:193)
> ... 8 more
> I will attach a WSDL that exploits this issue and the WSDL2Java parameters
> used.
-
[jira] Created: (AXIS2-3634) NullPointerException during codegen when using JaxB RI databinding
NullPointerException during codegen when using JaxB RI databinding
--
Key: AXIS2-3634
URL: https://issues.apache.org/jira/browse/AXIS2-3634
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: codegen
Affects Versions: 1.3, 1.4
Environment: Windows XP, Java 6
Reporter: Aaron Gourley
I was able to get around the following exception by replacing
org.apache.axis2.jaxbri.CodeGenerationUtility line 125 of Axis2 1.4 RC1 as
follows (in anonymous EntityResolver.resolveEntity())
Replace this: if (key.getTargetNamespace().equals(publicId)) {
With this: if (key.getTargetNamespace() != null &&
key.getTargetNamespace().equals(publicId)) {
Additionally, I'm not sure if it would be acceptable to skip the for loop all
together if publicId is null.
The exception that I encountered was:
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:271)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
Caused by: java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:112)
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
... 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:597)
at
org.apache.axis2.wsdl.codegen.extension.JAXBRIExtension.engage(JAXBRIExtension.java:101)
... 3 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:307)
... 8 more
Caused by: java.lang.NullPointerException
at
org.apache.axis2.jaxbri.CodeGenerationUtility$1.resolveEntity(CodeGenerationUtility.java:125)
at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:296)
at
com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394)
at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:274)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:148)
at
org.apache.axis2.jaxbri.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:193)
... 8 more
I will attach a WSDL that exploits this issue and the WSDL2Java parameters used.
--
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]
[jira] Updated: (AXIS2-3476) Client-side processing of asynchronous requests with void return type is flawed.
[ https://issues.apache.org/jira/browse/AXIS2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Gourley updated AXIS2-3476: - Attachment: CustomMessage.wsdl Sample WSDL exploiting the deficiency. Notice that the startSetCustomMessage() method does not make use of the CustomMessageServiceCallbackHandler instance, making it impossible for the business logic to be informed of faults or completion. > Client-side processing of asynchronous requests with void return type is > flawed. > > > Key: AXIS2-3476 > URL: https://issues.apache.org/jira/browse/AXIS2-3476 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen >Affects Versions: 1.4, 1.3, 1.2 > Environment: Axis2 1.3, Java 6, Windows XP >Reporter: Aaron Gourley > Attachments: CustomMessage.wsdl > > > Root of problem is in > modules/codegen/src/org/apache/axis2/wsdl/template/java/InterfaceImplementation.xsl, > near the following block of code: > > // Nothing to pass as the callback!!! > > Due to the fact that the startXXX() methods don't register a callback in the > operationClient for void methods, generated client stubs are produced in such > a way that there is no way for the client application to have itself notified > upon request completion (whether on error, fault, or otherwise). The client > is left in limbo. > Along with a fix for this issue I believe that a change has to be made to the > CallbackHandlerTemplate.xsl file so that generated callback handlers support > some sort of onComplete() derivation (such as receiveCompleteXXX). The > reason being is that for void methods there is no way for a client > application using the generated stub code to be notified when a void method > completes successfully. This way, the generated Axis2Callback within the > stub code would be able to call the new onComplete() style method in the > CallbackHandler, allowing the client app to know when execution is complete. -- 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]
[jira] Created: (AXIS2-3476) Client-side processing of asynchronous requests with void return type is flawed.
Client-side processing of asynchronous requests with void return type is flawed. Key: AXIS2-3476 URL: https://issues.apache.org/jira/browse/AXIS2-3476 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: codegen Affects Versions: 1.2, 1.3, 1.4 Environment: Axis2 1.3, Java 6, Windows XP Reporter: Aaron Gourley Root of problem is in modules/codegen/src/org/apache/axis2/wsdl/template/java/InterfaceImplementation.xsl, near the following block of code: // Nothing to pass as the callback!!! Due to the fact that the startXXX() methods don't register a callback in the operationClient for void methods, generated client stubs are produced in such a way that there is no way for the client application to have itself notified upon request completion (whether on error, fault, or otherwise). The client is left in limbo. Along with a fix for this issue I believe that a change has to be made to the CallbackHandlerTemplate.xsl file so that generated callback handlers support some sort of onComplete() derivation (such as receiveCompleteXXX). The reason being is that for void methods there is no way for a client application using the generated stub code to be notified when a void method completes successfully. This way, the generated Axis2Callback within the stub code would be able to call the new onComplete() style method in the CallbackHandler, allowing the client app to know when execution is complete. -- 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]
[jira] Updated: (AXIS2-3218) Client sender connections not cleaned up when AxisFault received.
[
https://issues.apache.org/jira/browse/AXIS2-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Gourley updated AXIS2-3218:
-
Comment: was deleted
> Client sender connections not cleaned up when AxisFault received.
> -
>
> Key: AXIS2-3218
> URL: https://issues.apache.org/jira/browse/AXIS2-3218
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: codegen
>Affects Versions: 1.3, 1.2
> Environment: Windows XP, Java 5
>Reporter: Aaron Gourley
> Attachments: InterfaceImplementationTemplate.xsl
>
>
> I suspect that lines 439-513 of
> java/modules/codegen/src/org/apache/axis2/wsdl/template/java/InterfaceImplementationTemplate.xsl
> has a bug. This bug results in generated stubs not cleaning up their
> connections properly.
> The following line (491) is only called on a successful request:
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> If an AxisFault is thrown, then the message context is not cleaned up and the
> connection is not closed properly.
> I propose the following fix:
> - Remove line 491
> - Insert the following before line 439 (i.e. before
> "_operationClient.execute(true);")
> try {
> - Insert the following before line 514:
> }finally{
>
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> }
> This will force that cleanup be called on the message context after every
> execution of the operation. I realize that Axis2 1.3 has added
> Options.setCallTransportCleanup() method and a
> ServiceClient.cleanupTransport() method for this (which is good), but this
> fix might hit one of the root causes of stale connections being left open.
> I'll attach my version of the modified xsl file (used Axis2 1.3 source
> release as starting point). Verified that the problem still exists in trunk.
--
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]
[jira] Updated: (AXIS2-3218) Client sender connections not cleaned up when AxisFault received.
[
https://issues.apache.org/jira/browse/AXIS2-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Gourley updated AXIS2-3218:
-
Attachment: InterfaceImplementationTemplate.xsl
My local fix.
> Client sender connections not cleaned up when AxisFault received.
> -
>
> Key: AXIS2-3218
> URL: https://issues.apache.org/jira/browse/AXIS2-3218
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: codegen
>Affects Versions: 1.3, 1.2
> Environment: Windows XP, Java 5
>Reporter: Aaron Gourley
> Attachments: InterfaceImplementationTemplate.xsl
>
>
> I suspect that lines 439-513 of
> java/modules/codegen/src/org/apache/axis2/wsdl/template/java/InterfaceImplementationTemplate.xsl
> has a bug. This bug results in generated stubs not cleaning up their
> connections properly.
> The following line (491) is only called on a successful request:
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> If an AxisFault is thrown, then the message context is not cleaned up and the
> connection is not closed properly.
> I propose the following fix:
> - Remove line 491
> - Insert the following before line 439 (i.e. before
> "_operationClient.execute(true);")
> try {
> - Insert the following before line 514:
> }finally{
>
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> }
> This will force that cleanup be called on the message context after every
> execution of the operation. I realize that Axis2 1.3 has added
> Options.setCallTransportCleanup() method and a
> ServiceClient.cleanupTransport() method for this (which is good), but this
> fix might hit one of the root causes of stale connections being left open.
> I'll attach my version of the modified xsl file (used Axis2 1.3 source
> release as starting point). Verified that the problem still exists in trunk.
--
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]
[jira] Created: (AXIS2-3218) Client sender connections not cleaned up when AxisFault received.
Client sender connections not cleaned up when AxisFault received.
-
Key: AXIS2-3218
URL: https://issues.apache.org/jira/browse/AXIS2-3218
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: codegen
Affects Versions: 1.2, 1.3
Environment: Windows XP, Java 5
Reporter: Aaron Gourley
I suspect that lines 439-513 of
java/modules/codegen/src/org/apache/axis2/wsdl/template/java/InterfaceImplementationTemplate.xsl
has a bug. This bug results in generated stubs not cleaning up their
connections properly.
The following line (491) is only called on a successful request:
_messageContext.getTransportOut().getSender().cleanup(_messageContext);
If an AxisFault is thrown, then the message context is not cleaned up and the
connection is not closed properly.
I propose the following fix:
- Remove line 491
- Insert the following before line 439 (i.e. before
"_operationClient.execute(true);")
try {
- Insert the following before line 514:
}finally{
_messageContext.getTransportOut().getSender().cleanup(_messageContext);
}
This will force that cleanup be called on the message context after every
execution of the operation. I realize that Axis2 1.3 has added
Options.setCallTransportCleanup() method and a ServiceClient.cleanupTransport()
method for this (which is good), but this fix might hit one of the root causes
of stale connections being left open.
I'll attach my version of the modified xsl file (used Axis2 1.3 source release
as starting point). Verified that the problem still exists in trunk.
--
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]
[jira] Updated: (AXIS2-2395) AxisMessage.getSchema() returns null when schema element is found in an imported schema
[
https://issues.apache.org/jira/browse/AXIS2-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Gourley updated AXIS2-2395:
-
Affects Version/s: 1.2
> AxisMessage.getSchema() returns null when schema element is found in an
> imported schema
> ---
>
> Key: AXIS2-2395
> URL: https://issues.apache.org/jira/browse/AXIS2-2395
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
>Affects Versions: 1.2, 1.1.1
> Environment: All
>Reporter: Jeff Faath
>Assignee: Deepal Jayasinghe
>Priority: Minor
>
> When calling getSchema() on an AxisMessage, 'null' is returned when the
> schema element is found in an imported schema. This is because the code does
> not check imported schema. I've devised a solution below which recursively
> traverses any imported schema. The original getSchema() method can be
> replaced by the two methods below:
> public XmlSchemaElement getSchemaElement() {
> AxisService service = (AxisService) getParent().getParent();
> ArrayList schemas = service.getSchema();
> for (int i = 0; i < schemas.size(); i++) {
> XmlSchema schema = (XmlSchema) schemas.get(i);
> return getSchemaElement(schema);
> }
> return null;
> }
> private XmlSchemaElement getSchemaElement(XmlSchema schema) {
> XmlSchemaElement returnElement = null;
> if (schema != null) {
> if (schema.getItems() != null) {
> Iterator schemaItems = schema.getItems().getIterator();
> while (schemaItems.hasNext()) {
> Object item = schemaItems.next();
> if (item instanceof XmlSchemaElement) {
> XmlSchemaElement xmlSchemaElement = (XmlSchemaElement) item;
> if (xmlSchemaElement.getQName().equals(this.elementQname)) {
> returnElement = xmlSchemaElement;
> }
> }
>else if (item instanceof org.apache.ws.commons.schema.XmlSchemaImport)
> {
> returnElement =
> getSchemaElement(((org.apache.ws.commons.schema.XmlSchemaImport)item).getSchema());
>}
>else if (item instanceof
> org.apache.ws.commons.schema.XmlSchemaInclude) {
> returnElement =
> getSchemaElement(((org.apache.ws.commons.schema.XmlSchemaInclude)item).getSchema());
>}
>// We've found a matching element, no need to continue...
>if (returnElement != null)
> break;
>}
> }
>}
>return returnElement;
> }
--
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]
[jira] Commented: (AXIS2-2395) AxisMessage.getSchema() returns null when schema element is found in an imported schema
[
https://issues.apache.org/jira/browse/AXIS2-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502898
]
Aaron Gourley commented on AXIS2-2395:
--
I have encountered another issue with this method. Axis2 1.2 included a fix
that was similar to Jeff's proposal, but it has a fundamental flaw. It only
returns the element if it is contained in the last schema, otherwise it will
return null. This caused me to be unable to generate unwrapped code using
WSDL2Java.
I locally applied this code change and it fixed my problem:
public XmlSchemaElement getSchemaElement() {
XmlSchemaElement xmlSchemaElement = null;
AxisService service = (AxisService) getParent().getParent();
ArrayList schemas = service.getSchema();
for (Iterator schemaIter = schemas.iterator(); schemaIter.hasNext();){
xmlSchemaElement = getSchemaElement((XmlSchema) schemaIter.next());
if( xmlSchemaElement != null )
{
return xmlSchemaElement;
}
}
return xmlSchemaElement;
}
> AxisMessage.getSchema() returns null when schema element is found in an
> imported schema
> ---
>
> Key: AXIS2-2395
> URL: https://issues.apache.org/jira/browse/AXIS2-2395
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
>Affects Versions: 1.2, 1.1.1
> Environment: All
>Reporter: Jeff Faath
>Assignee: Deepal Jayasinghe
>Priority: Minor
>
> When calling getSchema() on an AxisMessage, 'null' is returned when the
> schema element is found in an imported schema. This is because the code does
> not check imported schema. I've devised a solution below which recursively
> traverses any imported schema. The original getSchema() method can be
> replaced by the two methods below:
> public XmlSchemaElement getSchemaElement() {
> AxisService service = (AxisService) getParent().getParent();
> ArrayList schemas = service.getSchema();
> for (int i = 0; i < schemas.size(); i++) {
> XmlSchema schema = (XmlSchema) schemas.get(i);
> return getSchemaElement(schema);
> }
> return null;
> }
> private XmlSchemaElement getSchemaElement(XmlSchema schema) {
> XmlSchemaElement returnElement = null;
> if (schema != null) {
> if (schema.getItems() != null) {
> Iterator schemaItems = schema.getItems().getIterator();
> while (schemaItems.hasNext()) {
> Object item = schemaItems.next();
> if (item instanceof XmlSchemaElement) {
> XmlSchemaElement xmlSchemaElement = (XmlSchemaElement) item;
> if (xmlSchemaElement.getQName().equals(this.elementQname)) {
> returnElement = xmlSchemaElement;
> }
> }
>else if (item instanceof org.apache.ws.commons.schema.XmlSchemaImport)
> {
> returnElement =
> getSchemaElement(((org.apache.ws.commons.schema.XmlSchemaImport)item).getSchema());
>}
>else if (item instanceof
> org.apache.ws.commons.schema.XmlSchemaInclude) {
> returnElement =
> getSchemaElement(((org.apache.ws.commons.schema.XmlSchemaInclude)item).getSchema());
>}
>// We've found a matching element, no need to continue...
>if (returnElement != null)
> break;
>}
> }
>}
>return returnElement;
> }
--
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]
[jira] Created: (AXIS2-1850) Support for output parameters (i.e. reference parameters/holders)
Support for output parameters (i.e. reference parameters/holders) - Key: AXIS2-1850 URL: http://issues.apache.org/jira/browse/AXIS2-1850 Project: Apache Axis 2.0 (Axis2) Issue Type: Wish Components: deployment Environment: Windows XP SP2, Java 5 Update 9 Reporter: Aaron Gourley I am wondering if there are any plans to implement output parameters. For example: Say we have a java method: private void makeRequest( RequestParameters input, ResponseParameters output ); I am looking for a way to have the contents of the output parameter to be returned to the output parameter that the client passed. This method is only an example. I realize that a solution to this would be to just change the method to look like this, but let's just say that this is not an option for me: private ResponseParameters makeRequest( RequestParameters input ); I believe this was supported in Axis 1.x as long as the type was used as an inout or an out parameter. (http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL) If this functionality is already implemented in Axis2, I apologize. In this case, would it be possible for somebody to provide me with an example? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1790) schemaLocation element of import statements should contain URI reference to schema document.
[
http://issues.apache.org/jira/browse/AXIS2-1790?page=comments#action_12454373 ]
Aaron Gourley commented on AXIS2-1790:
--
Make that AxisService2OM's generateOM() method (not AxisService2WSDL2's)
> schemaLocation element of import statements should contain URI reference to
> schema document.
>
>
> Key: AXIS2-1790
> URL: http://issues.apache.org/jira/browse/AXIS2-1790
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: wsdl
>Affects Versions: 1.1
> Environment: Windows XP, Java 5 Update 9
>Reporter: Aaron Gourley
>
> From W3C schemaLocation spec:
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#composition-schemaImport
> Additional reference:
> http://www.stylusstudio.com/w3c/schema0/schemaLocation.htm#attribute-schemaLocation
>id = ID
> namespace = anyURI
> schemaLocation = anyURI
> {any attributes with non-schema namespace . . .}>
> Content: (annotation?)
>
> "In a schema, the include element has a required schemaLocation attribute,
> and it contains a URI reference which must identify a schema document."
> Axis2 is currently using a relative SchemaLocation, which on its own can not
> be used to identify the schema document. This actually causes a
> compatibility problem between Glue clients and such WSDLs published by Axis2.
> WSDL published by Axis2:
> targetNamespace="http://www.csapi.org/wsdl/parlayx/terminal_location/v2_0/service";>
> TerminalLocation
>
> elementFormDefault="qualified"
> targetNamespace="http://www.csapi.org/schema/parlayx/terminal_location/v2_0/local";>
> namespace="http://www.csapi.org/schema/parlayx/terminal_location/v2_0";
> schemaLocation="TerminalLocation?xsd=xsd0"/>
> namespace="http://www.csapi.org/schema/parlayx/common/v2_0";
> schemaLocation="TerminalLocation?xsd=xsd2"/>
> .
>
> binding="tns:TerminalLocationSOAP11Binding">
> location="http://localhost:9080/TerminalLocationService/services/TerminalLocation"/>
>
> binding="tns:TerminalLocationSOAP12Binding">
> location="http://localhost:9080/TerminalLocationService/services/TerminalLocation"/>
>
> binding="tns:TerminalLocationHttpBinding">
> location="http://localhost:9080/TerminalLocationService/rest/TerminalLocation"/>
>
>
>
> When Glue parses this WSDL, it simply creates a URI from the string
> "TerminalLocation?xsd=xsd0". Since the prefix
> ("http://localhost:9080/TerminalLocationService/services/";) is not shown in
> the WSDL, a FileNotFoundException occurs and the bind fails. I have not been
> able to find a workaround using Glue.
> I realize that the easy solution is to say that this is a Glue problem, but
> would it be at all possible to include the address location in the generated
> WSDL?
> Suggested fix:
> 1. In AxisService's adjustSchemaLocation(XmlSchema, XmlSchemaExternal,
> Hashtable, Hashtable) method:
> - Change getName() in default mode to getEndpoint()
> 2. In AxisService2WSDL2's generateOM() method:
> - add call to
> axisService.setCustomSchemaNamePrefix(axisService.getEndpoint() + "?xsd=")
> before call to populateSchemaMappings() is made.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1790) schemaLocation element of import statements should contain URI reference to schema document.
schemaLocation element of import statements should contain URI reference to
schema document.
Key: AXIS2-1790
URL: http://issues.apache.org/jira/browse/AXIS2-1790
Project: Apache Axis 2.0 (Axis2)
Issue Type: Improvement
Components: wsdl
Affects Versions: 1.1
Environment: Windows XP, Java 5 Update 9
Reporter: Aaron Gourley
>From W3C schemaLocation spec:
>http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#composition-schemaImport
Additional reference:
http://www.stylusstudio.com/w3c/schema0/schemaLocation.htm#attribute-schemaLocation
Content: (annotation?)
"In a schema, the include element has a required schemaLocation attribute,
and it contains a URI reference which must identify a schema document."
Axis2 is currently using a relative SchemaLocation, which on its own can not be
used to identify the schema document. This actually causes a compatibility
problem between Glue clients and such WSDLs published by Axis2.
WSDL published by Axis2:
http://www.csapi.org/wsdl/parlayx/terminal_location/v2_0/service";>
TerminalLocation
http://www.csapi.org/schema/parlayx/terminal_location/v2_0/local";>
http://www.csapi.org/schema/parlayx/terminal_location/v2_0";
schemaLocation="TerminalLocation?xsd=xsd0"/>
http://www.csapi.org/schema/parlayx/common/v2_0";
schemaLocation="TerminalLocation?xsd=xsd2"/>
.
http://localhost:9080/TerminalLocationService/services/TerminalLocation"/>
http://localhost:9080/TerminalLocationService/services/TerminalLocation"/>
http://localhost:9080/TerminalLocationService/rest/TerminalLocation"/>
When Glue parses this WSDL, it simply creates a URI from the string
"TerminalLocation?xsd=xsd0". Since the prefix
("http://localhost:9080/TerminalLocationService/services/";) is not shown in the
WSDL, a FileNotFoundException occurs and the bind fails. I have not been able
to find a workaround using Glue.
I realize that the easy solution is to say that this is a Glue problem, but
would it be at all possible to include the address location in the generated
WSDL?
Suggested fix:
1. In AxisService's adjustSchemaLocation(XmlSchema, XmlSchemaExternal,
Hashtable, Hashtable) method:
- Change getName() in default mode to getEndpoint()
2. In AxisService2WSDL2's generateOM() method:
- add call to
axisService.setCustomSchemaNamePrefix(axisService.getEndpoint() + "?xsd=")
before call to populateSchemaMappings() is made.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1754) Exceptions thrown by service methods are not propogated to clients properly.
Exceptions thrown by service methods are not propogated to clients properly. Key: AXIS2-1754 URL: http://issues.apache.org/jira/browse/AXIS2-1754 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: rpc Affects Versions: 1.1 Environment: OS: Windows XP SP2, Eclipse 3.2 IDE, Java 5.0 Update 7 Reporter: Aaron Gourley This bug was introduced in revision 452427 (http://svn.apache.org/viewvc?view=rev&revision=452427) In the invokeBusinessLogic() method, calls to "AxisFault.makeFault(e)" were changed to calls to "new AxisFault(msg, e)" in the catch blocks in the try/catch statements. This is particularly a problem in the handling of InvocationTargetExceptions, because the call was actually replaced with a call to "new AxisFault(msg) and exceptions thrown by service methods (which are wrapped by InvocationTargetExceptions at this point) are discarded. The old behaviour was to wrap the cause exception in an AxisFault and rethrow. Now the cause exception is only used for its message and a new AxisFault exception is created with the same message (and no reference to the exception thrown by the service method). This results in a meaningless exception being thrown every time. Example: My service object throws an exception object (which is defined in my WSDL) containing some member fields: messageId and resultCode. I do not call setMessage() on this exception, so getMessage() returns null. After the RPCMessageReceivers process my exception, an AxisFault is thrown with message "Exception occurred while trying to invoke service method " + method.getName(). My original exception is thrown away and I lose my messageId and resultCode information. I get the following SOAP message from the server: HTTP/1.1 500 Internal Server Error Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=07DA197EBF0B871BF5F99B82A177EE01; Path=/TerminalLocationService Content-Type: text/xml;charset=UTF-8 Transfer-Encoding: chunked Date: Mon, 20 Nov 2006 20:05:48 GMT Connection: close 169 http://schemas.xmlsoap.org/soap/envelope/";>soapenv:ClientException occurred while trying to invoke service method getLocationForGroup 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1754) Exceptions thrown by service methods are not propogated to clients properly.
[
http://issues.apache.org/jira/browse/AXIS2-1754?page=comments#action_12451679 ]
Aaron Gourley commented on AXIS2-1754:
--
After furthur analyzing the AxisFault source, I see that the class is not
designed to extract meaningful information from the source exception in the way
I have implemented my service.
>From what I can tell, I must use the generated
>TerminalLocationServiceMessageReceiverInOut object if I want Axis2 to process
>my exceptions the way I expect it to. The following catch blocks will do what
>I expect:
catch (ServiceException e)
{
org.apache.axis2.AxisFault f = createAxisFault(e);
f.setDetail(toOM(e.getFaultMessage(), false));
throw f;
}
catch (PolicyException e)
{
org.apache.axis2.AxisFault f = createAxisFault(e);
f.setDetail(toOM(e.getFaultMessage(), false));
throw f;
}
catch (Exception e)
{
throw org.apache.axis2.AxisFault.makeFault(e);
}
> Exceptions thrown by service methods are not propogated to clients properly.
>
>
> Key: AXIS2-1754
> URL: http://issues.apache.org/jira/browse/AXIS2-1754
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: rpc
>Affects Versions: 1.1
> Environment: OS: Windows XP SP2, Eclipse 3.2 IDE, Java 5.0 Update 7
>Reporter: Aaron Gourley
>
> This bug was introduced in revision 452427
> (http://svn.apache.org/viewvc?view=rev&revision=452427)
> In the invokeBusinessLogic() method, calls to "AxisFault.makeFault(e)" were
> changed to calls to "new AxisFault(msg, e)" in the catch blocks in the
> try/catch statements. This is particularly a problem in the handling of
> InvocationTargetExceptions, because the call was actually replaced with a
> call to "new AxisFault(msg) and exceptions thrown by service methods (which
> are wrapped by InvocationTargetExceptions at this point) are discarded. The
> old behaviour was to wrap the cause exception in an AxisFault and rethrow.
> Now the cause exception is only used for its message and a new AxisFault
> exception is created with the same message (and no reference to the exception
> thrown by the service method).
> This results in a meaningless exception being thrown every time.
> Example:
> My service object throws an exception object (which is defined in my WSDL)
> containing some member fields: messageId and resultCode. I do not call
> setMessage() on this exception, so getMessage() returns null. After the
> RPCMessageReceivers process my exception, an AxisFault is thrown with message
> "Exception occurred while trying to invoke service method " +
> method.getName(). My original exception is thrown away and I lose my
> messageId and resultCode information. I get the following SOAP message from
> the server:
> HTTP/1.1 500 Internal Server Error
> Server: Apache-Coyote/1.1
> Set-Cookie: JSESSIONID=07DA197EBF0B871BF5F99B82A177EE01;
> Path=/TerminalLocationService
> Content-Type: text/xml;charset=UTF-8
> Transfer-Encoding: chunked
> Date: Mon, 20 Nov 2006 20:05:48 GMT
> Connection: close
> 169
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> />soapenv:ClientException
> occurred while trying to invoke service method
> getLocationForGroup />
> 0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
