One thing that I didn't mention in the JIRA is that I noticed in WSDL11ToAxisServiceBuilder that there is code in a few places that handles SOAP 1.2 extensibility elements by testing for UnknownExtensibilityElement and manually testing for SOAP 1.2 elements (most notably in copyExtensibleElements()). As of the current version of WSDL4J (1.6.1), possibly earlier, this should be a bug since all of the SOAP 1.2 extensibility elements are in there, and are registered by the default ExtensionRegistry implementation (also by the custom version which I have included in the patch).
I didn't address this in the patch since it was specific to JMS support. -----Original Message----- From: Brennan Spies (JIRA) [mailto:[EMAIL PROTECTED] Sent: Saturday, October 28, 2006 7:02 PM To: [email protected] Subject: [jira] Updated: (AXIS2-1381) Need to enhance code generation from WSDL to support JMS extensions [ http://issues.apache.org/jira/browse/AXIS2-1381?page=all ] Brennan Spies updated AXIS2-1381: --------------------------------- Attachment: patch.zip This is a patch to fix this issue. Notes: 1. Have not dealt with native JMS binding, but the more common use case of SOAP JMS binding with a JMS address as the <port> subelement. 2. See changelog notes on how to set the WSDL4J ExtensionRegistry, so that WSDL4J can auto-discover the correct implmentation. Changelog (also included in attachment): CHANGELOG for JMS extensions patch: Module: codegen 1. Added JMS WSDL extensions for WSDL4J from the Apache WSIF project. Minor modifications to get them to work with WSDL4J 1.6.1 and Axis 2 (change to method call and removal of custom trace logging). To enable them, you must use the META-INF/services/ properties file in the attached zip (or use System property). 2. Added two methods, getJmsAttributes(String,Document,Element) and getJmsAddress(Port) to AxisServiceBasedMultiLanguageEmitter. Modified getServiceElement(string,String,Document) to use these. The result is that the custom XML that gets passed to the XSLT is modified with extra attributes if jms:address extensibility elements are present. 3. Modified ServiceXMLTemplate.xsl to detect the extra attributes in #2, and generate the <transports> block and appropriate JMS <property> elements. Module: kernel 1. Added two custom classes for registering and using extensibility elements with WSDL4J, org.apache.axis.wsdl.WSDLExtensionRegistry and AxisWSDLFactory (which uses the former). 2. AxisService2OM. Current version before patch only generates bindings for HTTP (SOAP 1.1 and 1.2). I've modified this class to generate SOAP 1.1 and 1.2 bindings for each endpoint/transport that is passed into the constructor (the String[] urls). Added code to generate the appropriate transport URI to the binding, as well as map the appropriate binding to a port. 3. Fixed a bug where AxisService2OM would generate <soap:body> subelements of an operation's fault element rather than the appropriate <soap:fault>. 4. Added utility method in JMSUtils to convert a jms:address into a soap:address of the form jms:/topicOrQueue?[property=value]&[property=value]...(entity ref for ampersand for valid XML). This is used to set the endpoint on the AxisService so that the generated client stub has the correct default endpoint. 5. Added some constants for namespaces, etc. 6. Added ability to recognize JMSAddress as legitimate element in both findSOAPPort() and copyExtensibilityElements() in WSDL11ToAxisServiceBuilder. > Need to enhance code generation from WSDL to support JMS extensions > ------------------------------------------------------------------- > > Key: AXIS2-1381 > URL: http://issues.apache.org/jira/browse/AXIS2-1381 > Project: Apache Axis 2.0 (Axis2) > Issue Type: New Feature > Components: codegen > Affects Versions: 1.1 > Environment: All > Reporter: Brennan Spies > Assigned To: Davanum Srinivas > Attachments: files.zip, patch.zip > > > Currently, there is no support for JMS WSDL extensions in Axis 2.0. Code generation for a WSDL service with JMS bindings succeeds, but the client stub is missing a default JMS endpoint reference, and transport elements and appropriate properties from <jms:address> should be placed into the generated services.xml file. > To do this, the appropriate extension elements for JMS in the WSDL must be recognized. This requires adding them to WSDL4J's extensibility mechanism. The appropriate implementations already exist in the Apache WSIF project: http://ws.apache.org/wsif/providers/wsdl_extensions/jms_extension.html. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
