[Design of JBoss Web Services] - doclit request message element name not equal to operation n
by thomas.diesler＠jboss.com
I have
| <types>
| <schema ...>
| <complexType name="paraListType">
| <sequence>
| <element name="username" type="string" nillable="true"/>
| <element name="password" type="string" nillable="true"/>
| <element name="operationName" type="string" nillable="true"/>
| <element name="inputXML" type="string" nillable="true"/>
| </sequence>
| </complexType>
| <complexType name="responseType">
| <sequence>
| <element name="result" type="string" nillable="true"/>
| </sequence>
| </complexType>
| <element name="paraList2" type="tns:paraListType"/>
| <element name="responseXML" type="tns:responseType"/>
| </schema>
| </types>
| <message name="attachRequest">
| <part name="parameters" element="ns2:paraList2"/>
| <part name="attachmentContents" type="xsd:string"/>
| </message>
| <message name="attachResponse">
| <part name="result" element="ns2:responseXML"/>
| </message>
| <portType name="TransmulatorInterface">
| <operation name="invokeAttach">
| <input message="tns:attachRequest"/>
| <output message="tns:attachResponse"/>
| </operation>
| </portType>
|
When running tools I get
| Exception in thread "main" org.jboss.ws.WSException: Unable to unwrap parameters, wrapper element name must match operation name. operationName=invokeAttach elementName=paraList2
| at org.jboss.ws.tools.WSDLToJava.appendParameters(WSDLToJava.java:421)
| at org.jboss.ws.tools.WSDLToJava.appendDocParameters(WSDLToJava.java:387)
|
Do we have a reference to the relevant part in a spec?
Generally, we please document (read MUST) why we make assertions like this. A future version of the spec might invalidate the assertion.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000809#4000809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000809
19 years, 2 months
JWS regression resolved in javaee5_0_tempb-b04-tck.zip
by Jason T. Greene
The TCK update, and other changes in the core codebase introduced
regression in the JWS module. I just fixed the last issue, so now the
module passes in full. The update resolved one of the TCK challenges
(JBCTS-428), the other is still occurring so I have forwarded the
information to SUN.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Jason T. Greene
Senior Software Engineer
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 2 months
[Design of JBoss Web Services] - Design of wsimport
by jason.greene＠jboss.com
I thought I would outline the plan for the JAX-WS wsdl->java tool (wsimport).
API Dependencies
Unlike the java to wsdl processing, wsimport is more isolated and has minimal API requirements from core:
| * WSDLDefinitions - Our WSDL API is the main source, as this tool largely has 1 input, the WSDL file.
| * JAXB XJC API - This will be needed to generate Java types for all schema types contained in the WSDL.
| * JAXB Code Model API - Since the XJC API returns instances of JCodeModel, we might as well use it for generating the remaining Java artifacts.
| * JDK Compiler or Javassist - We will either need to invoke the JDK compiler or build a JCodeModel to bytecode translator using javassit
|
Key Tasks
The following are the major tasks for implementing this tool:
| * Enhance WSDLDefinitions - The WSDLDefinitions API needs to be enhanced to handle the custom jaxws binding extension elements. Also WSDL11Reader needs to be enhanced to take a DOM view of all schema elements and make them available as a DOMTypes object (already exists for generation now).
| * Implement Binding File Processing - A JAX-WS binding file parser needs to be implemented. This binding file allows you to specify customizations that apply to the WSDL file, but without having to modify the WSDL file.
| * WSDL XPath Modifcation Phase - Since the binding file uses xpath expressions, we must first read the WSDL file into a DOM tree, then perform the XPath modifications to obtain the inlined version. After this the WSDL11Reader will produce a WSDLDefinitions model that contains the additional JAX-WS metadata.
| * Implement Core Processing Engine - This component will be responsible for interpreting the resulting metadata, and generating artifacts through JAXB XJC and the JAXB Code Model API that conform to the WSDL to Java portion of the specification.
| * Implement Source and Bytecode generation - At the end of the processing phase, bytecode and optionally source will need to be written to disk. The code model API has the capability to generate the source; however, it has no direct bytecode generation capability. This would have to be implemented by us, or we could just invoke the compiler and delete the source files if they aren't desired by the user.
| * API - A simple API will need to be developed that takes the input options, and returns the list of artifacts generated, as well as any error or warning conditions that occurred.
| * Command line tool - This will be a simple command line tool that uses the above API to perform the required processing.
| * ANT Task - A simple ant task that offers the same options needs to be developed. As in the command line tool, it should use the above API.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000708#4000708
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000708
19 years, 2 months
[Design of JBoss Web Services] - Re: Using jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
by dwin
hey guys
thanks for the help, adding junit.jar to the ant/lib fixed it (although ant already has an ant-junir.jar in its classpath already) and upgrading to ant 1.7 fixed the xerces bug. Perhaps, you guys could put ant 1.7 as a requirement for building JBossWS on the Wiki to avoid future confusion with other developers.
However, the tests are failing for me.
On the server side, I am regularly getting these exceptions which all basically relate to the "setProperty must be overridden by all subclasses of SOAPMessage" message. Every test seems to fail because of these exceptions.
| 14:10:57,445 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
| java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessageInternal(Unknown Source)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
| at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
| at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:619)
| 14:10:57,477 ERROR [AbstractServiceEndpointServlet] Error processing web service request
| java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
| at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.toSOAPMessage(Unknown Source)
| at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.exceptionToFaultMessage(Unknown Source)
| at org.jboss.ws.core.jaxrpc.SOAP11BindingJAXRPC.createFaultMessageFromException(Unknown Source)
| at org.jboss.ws.core.CommonSOAPBinding.bindFaultMessage(Unknown Source)
| at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
| at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
|
The vast majority of my unit tests fail (but not all fail, a minute portion of them do pass).
I am guessing that my environment is not setup as the rest of the JBoss team.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000580#4000580
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000580
19 years, 2 months
[Design of JBoss Web Services] - JBWS-1259 - element ref and type qnames
by darran.lofthouse＠jboss.com
>From the following schema: -
| <schema targetNamespace='http://test.jboss.org/ws/jbws1259/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1259/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
|
| <complexType name='Person'>
| <sequence>
| <element name='firstName' nillable='true' type='string'/>
| <element name='surname' nillable='true' type='string'/>
| <element ref='tns:comment'/>
| </sequence>
| </complexType>
|
| <complexType name='TelephoneNumber'>
| <sequence>
| <element name='areaCode' nillable='true' type='string'/>
| <element name='number' nillable='true' type='string'/>
| <element ref='tns:comment'/>
| </sequence>
| </complexType>
|
| <element name='comment'>
| <complexType>
| <sequence>
| <element name='test' type='string' />
| <element ref='tns:comment' />
| </sequence>
| </complexType>
| </element>
|
| <element name='lookup' type='tns:Person' />
| <element name='lookupResponse' type='tns:TelephoneNumber'/>
| </schema>
wscompile generates the following mapping for comment: -
| <java-xml-type-mapping>
| <java-type>org.jboss.test.ws.jbws1259.Comment</java-type>
| <anonymous-type-qname xmlns:typeNS='http://test.jboss.org/ws/jbws1259/types'>typeNS:>Person>comment</anonymous-type-qname>
| <qname-scope>complexType</qname-scope>
| <variable-mapping>
| <java-variable-name>test</java-variable-name>
| <xml-element-name>test</xml-element-name>
| </variable-mapping>
| <variable-mapping>
| <java-variable-name>comment</java-variable-name>
| <xml-element-name>comment</xml-element-name>
| </variable-mapping>
| </java-xml-type-mapping>
We generate the following mapping (different qname because of the order we create the mappings): -
| <java-xml-type-mapping>
| <java-type>org.jboss.test.ws.jbws1259.Comment</java-type>
| <anonymous-type-qname>http://test.jboss.org/ws/jbws1259/types:>TelephoneNumber>comment</anonymous-type-qname>
| <qname-scope>complexType</qname-scope>
| <variable-mapping>
| <java-variable-name>test</java-variable-name>
| <xml-element-name>test</xml-element-name>
| </variable-mapping>
| <variable-mapping>
| <java-variable-name>comment</java-variable-name>
| <xml-element-name>comment</xml-element-name>
| </variable-mapping>
| </java-xml-type-mapping>
Looking at the Web Services for J2EE specification section 7.3.2.2 I think both of these are wrong, shouldn't this be mapped according to use case 4? e.g.
<anonymous-type-qname>http://test.jboss.org/ws/jbws1259/types:>comment</anonymous-type-qname>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000475#4000475
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000475
19 years, 2 months
Deploying EJB3 Webservice to JBoss 5
by Darran Lofthouse
I just wanted to check if this is a known problem, I have not looked
closely at it yet.
If I copy a jar to the deploy folder containing an EJB3 web service the
EJB is deployed but it is not deployed as a web service when JBoss is
started.
However if I run a test from the testsuite (that uses the same jar) the
deployment works correctly.
It looks as if the deployment works fine if the main deployer is called
after JBoss is started but if the jar is deployed during startup JBossWS
is not involved in the deployment.
Regards,
Darran Lofthouse.
19 years, 2 months
