[JBoss JIRA] Updated: (JBWS-859) SOAPMessageUnMarshaller doesn't support HTTP server response [204] - No Content
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-859?page=all ]
Thomas Diesler updated JBWS-859:
--------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> SOAPMessageUnMarshaller doesn't support HTTP server response [204] - No Content
> -------------------------------------------------------------------------------
>
> Key: JBWS-859
> URL: http://jira.jboss.com/jira/browse/JBWS-859
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Affects Versions: jbossws-1.0.0, jbossws-1.0.0.CR4
> Environment: JBoss-4.0.4.CR2
> JBossWS-1.0.0.CR4
> Java Version 1.5.0_06
> Java VM Version 1.5.0_06-b05
> OS Name Windows 2003
> jaxm1.1.2 using the jaxm-remote sample which is an example that uses a remote provider to send and receive messages using the ebXML profile.
>
> OS Version 5.2
> OS Arch x86
> Reporter: Aaron Walker
> Assigned To: Thomas Diesler
> Fix For: jbossws-1.0.6
>
> Attachments: JBWS-859.patch
>
>
> Parital log info from server.log - debug level. Let me know if you want a trace level log.
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Get locator for: http://127.0.0.1:8080/jaxm-provider/sender
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Remoting meta data: {HEADER={SOAPAction="", Content-Type=text/xml}}
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Outgoing SOAPMessage
> <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
> <env:Header>
> <jaxm:ClientInfo env:actor='http://java.sun.com/xml/jaxm/provider' env:mustUnderstand='1' xmlns:jaxm='http://java.sun.com/xml/jaxm'>
> <Method>InitConnection</Method>
> <Endpoint>http://www.wombats.com/remote/sender</Endpoint>
> <CallbackURL>http://localhost:8080/jaxm-remote/receiver</CallbackURL>
> </jaxm:ClientInfo>
> </env:Header>
> <env:Body/>
> </env:Envelope>
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.remoting.Client] invoke called, but our invoker is disconnected, discarding and fetching another fresh invoker for: InvokerLocator [http://127.0.0.1:8080/jaxm-provider/sender]
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] connect called for: org.jboss.remoting.transport.http.HTTPClientInvoker@6d23ea
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] Setting request header with SOAPAction : ""
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] Setting request header with Content-Type : text/xml
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.ws.soap.MessageFactoryImpl] createMessage: [contentType=text/xml]
> 2006-04-24 21:30:04,593 DEBUG [org.jboss.ws.soap.SOAPContentElement] setXMLFragment: <jaxm:ClientInfo env:actor='http://java.sun.com/xml/jaxm/provider' env:mustUnderstand='1' xmlns:jaxm='http://java.sun.com/xml/jaxm'><Method>InitConnection</Method><Endpoint>http://www.wombats.com/remote/sender</Endpoint><CallbackURL>http://localhost:8080/jaxm-remote/receiver</CallbackURL></jaxm:ClientInfo>
> 2006-04-24 21:30:04,609 INFO [com.sun.xml.messaging.jaxm.provider] Processing InitConnection
> 2006-04-24 21:30:04,609 DEBUG [org.jboss.ws.binding.soap.SOAPMessageUnMarshaller] getMimeHeaders from: {X-Powered-By=[Servlet 2.4; JBoss-4.0.4.CR2 (build: CVSTag=JBoss_4_0_4_CR2 date=200603311500)/Tomcat-5.5], ResponseCodeMessage=OK, Date=[Mon, 24 Apr 2006 11:30:04 GMT], Content-Type=[text/xml], Server=[Apache-Coyote/1.1], HEADER={SOAPAction="", Content-Type=text/xml}, Transfer-Encoding=[chunked], null=[HTTP/1.1 200 OK], ResponseCode=200}
> 2006-04-24 21:30:04,609 DEBUG [org.jboss.ws.soap.MessageFactoryImpl] createMessage: [contentType=text/xml]
> 2006-04-24 21:30:04,609 DEBUG [org.jboss.ws.soap.SOAPContentElement] setXMLFragment: <jaxm:Message env:actor='http://java.sun.com/xml/jaxm/provider' env:mustUnderstand='1' xmlns:jaxm='http://java.sun.com/xml/jaxm'><Method>MetaData</Method><Name>Sun Microsystems JAXM RI Remote provider</Name><MajorVersion>1</MajorVersion><MinorVersion>1</MinorVersion><SupportedProfiles><ProfileName>ebxml</ProfileName><ProfileName>soaprp</ProfileName></SupportedProfiles></jaxm:Message>
> 2006-04-24 21:30:04,609 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Incomming Response SOAPMessage
> <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
> <env:Header>
> <jaxm:Message env:actor='http://java.sun.com/xml/jaxm/provider' env:mustUnderstand='1' xmlns:jaxm='http://java.sun.com/xml/jaxm'>
> <Method>MetaData</Method>
> <Name>Sun Microsystems JAXM RI Remote provider</Name>
> <MajorVersion>1</MajorVersion>
> <MinorVersion>1</MinorVersion>
> <SupportedProfiles>
> <ProfileName>ebxml</ProfileName>
> <ProfileName>soaprp</ProfileName>
> </SupportedProfiles>
> </jaxm:Message>
> </env:Header>
> <env:Body/>
> </env:Envelope>
> 2006-04-24 21:30:04,640 ERROR [STDERR] Sending message to : http://www.wombats.com/remote/sender
> 2006-04-24 21:30:04,640 ERROR [STDERR] Sent message is logged in "sent.msg"
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.ws.soap.attachment.CIDGenerator] generateFromCount: cid:0-1145878204640-744320@ws.jboss.org
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Get locator for: http://127.0.0.1:8080/jaxm-provider/sender
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Remoting meta data: {HEADER={SOAPAction="", Content-Type=multipart/related; type="text/xml"; start="<rootpart(a)ws.jboss.org>";
> boundary="----=_Part_1_11886941.1145878204640"}}
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.ws.soap.SOAPConnectionImpl] Outgoing SOAPMessage
> <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
> <env:Header>
> <jaxm:Message env:actor='http://java.sun.com/xml/jaxm/provider' env:mustUnderstand='1' xmlns:jaxm='http://java.sun.com/xml/jaxm'>
> <Method>SendMessage</Method>
> <Profile>ebxml</Profile>
> </jaxm:Message>
> <eb:MessageHeader SOAP-ENV:mustUnderstand='1' eb:version='1.0' xmlns:eb='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'>
> <eb:From>
> <eb:PartyId eb:type='URI'>http://www.wombats.com/remote/sender</eb:PartyId>
> </eb:From>
> <eb:To>
> <eb:PartyId eb:type='URI'>http://www.wombats.com/remote/sender</eb:PartyId>
> </eb:To>
> <eb:CPAId>http://example.com/cpas/ourcpawithyou.xml</eb:CPAId>
> <eb:ConversationId>20001209-133003-28572</eb:ConversationId>
> <eb:Service eb:type=''>SupplierOrderProcessing</eb:Service>
> <eb:Action>NewOrder</eb:Action>
> <eb:MessageData>
> <eb:MessageId>d5b9e018-580d-4bb6-88f8-e92f132de17a</eb:MessageId>
> <eb:RefToMessageId>20001209-133003-28572(a)example.com</eb:RefToMessageId>
> <eb:Timestamp>1145878204609</eb:Timestamp>
> </eb:MessageData>
> </eb:MessageHeader>
> </env:Header>
> <env:Body>
> <eb:Manifest eb:id='manifest' eb:version='1.0' xmlns:eb='http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'>
> <eb:Reference eb:id='pay01' xlink:href='cid:pay01' xlink:role='http://regrep.org/gci/purchaseorder' xmlns:xlink='http://www.w3.org/1999/xlink'>
> <eb:Schema eb:location='http://regrep.org/gci/purchaseorder.xsd' eb:version='1.0'/>
> <eb:Description xml:lang='en-us'>PurchaseOrder for widgets</eb:Description>
> </eb:Reference>
> </eb:Manifest>
> </env:Body>
> </env:Envelope>
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] Setting request header with SOAPAction : ""
> 2006-04-24 21:30:04,640 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] Setting request header with Content-Type : multipart/related; type="text/xml"; start="<rootpart(a)ws.jboss.org>";
> boundary="----=_Part_1_11886941.1145878204640"
> 2006-04-24 21:30:04,671 DEBUG [org.jboss.ws.soap.MessageFactoryImpl] createMessage: [contentType=multipart/related; type="text/xml";
> boundary="----=_Part_1_11886941.1145878204640";
> start="<rootpart(a)ws.jboss.org>"]
> 2006-04-24 21:30:04,671 DEBUG [org.jboss.ws.soap.attachment.SwapableMemoryDataSource] Using memory buffer, size = 112
> 2006-04-24 21:30:04,671 DEBUG [org.jboss.ws.soap.attachment.SwapableMemoryDataSource] Using memory buffer, size = 168
> 2006-04-24 21:30:04,671 DEBUG [org.jboss.remoting.transport.http.HTTPClientInvoker] Error invoking http client invoker.
> org.jboss.ws.WSException: Invalid HTTP server response [204] - No Content
> at org.jboss.ws.binding.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:73)
> at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
> at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> at org.jboss.remoting.Client.invoke(Client.java:525)
> at org.jboss.remoting.Client.invoke(Client.java:488)
> at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:158)
> at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:76)
> at com.sun.xml.messaging.jaxm.client.remote.ProviderConnectionImpl.send(ProviderConnectionImpl.java:179)
> at remote.sender.SendingServlet.doGet(SendingServlet.java:150)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 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.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
> 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.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:595)
> 2006-04-24 21:30:04,671 ERROR [STDERR] javax.xml.soap.SOAPException: Could not transmit message
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:173)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:76)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at com.sun.xml.messaging.jaxm.client.remote.ProviderConnectionImpl.send(ProviderConnectionImpl.java:179)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at remote.sender.SendingServlet.doGet(SendingServlet.java:150)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
> 2006-04-24 21:30:04,671 ERROR [STDERR] Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:525)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:488)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:158)
> 2006-04-24 21:30:04,671 ERROR [STDERR] ... 24 more
> 2006-04-24 21:30:04,671 ERROR [STDERR] Caused by: org.jboss.ws.WSException: Invalid HTTP server response [204] - No Content
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.ws.binding.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:73)
> 2006-04-24 21:30:04,671 ERROR [STDERR] at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
> 2006-04-24 21:30:04,671 ERROR [STDERR] ... 29 more
> 2006-04-24 21:30:04,671 ERROR [com.sun.xml.messaging.jaxm.client.remote] Message send failed
> javax.xml.soap.SOAPException: Could not transmit message
> at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:173)
> at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:76)
> at com.sun.xml.messaging.jaxm.client.remote.ProviderConnectionImpl.send(ProviderConnectionImpl.java:179)
> at remote.sender.SendingServlet.doGet(SendingServlet.java:150)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 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.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
> 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.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:595)
> Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
> at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
> at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> at org.jboss.remoting.Client.invoke(Client.java:525)
> at org.jboss.remoting.Client.invoke(Client.java:488)
> at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:158)
> ... 24 more
> Caused by: org.jboss.ws.WSException: Invalid HTTP server response [204] - No Content
> at org.jboss.ws.binding.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:73)
> at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-862) Return SOAP Fault for invalid soap messages
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-862?page=all ]
Thomas Diesler updated JBWS-862:
--------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> Return SOAP Fault for invalid soap messages
> -------------------------------------------
>
> Key: JBWS-862
> URL: http://jira.jboss.com/jira/browse/JBWS-862
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Reporter: Anil Saldhana
> Assigned To: Thomas Diesler
> Priority: Minor
> Fix For: jbossws-1.0.6
>
>
> Please refer to Branch_4_0 testcase - org.jboss.test.wsrp.MarkupTestCase and the test is "testBlankSOAPMessage"
> The error in server.log is
> =======================================================================================
> 01:03:50,718 ERROR [SOAPFaultExceptionHelper] SOAP request exception
> javax.xml.soap.SOAPException: Cannot obtain SOAPBody from SOAPMessage
> at javax.xml.soap.SOAPMessage.getSOAPBody(SOAPMessage.java:182)
> at org.jboss.ws.soap.SOAPMessageDispatcher.getDispatchDestination(SOAPMessageDispatcher.java:77)
> at org.jboss.ws.soap.SOAPMessageImpl.getOperationMetaData(SOAPMessageImpl.java:285)
> at org.jboss.ws.server.ServiceEndpointInvoker.getDispatchDestination(ServiceEndpointInvoker.java:153)
> at org.jboss.ws.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:110)
> at org.jboss.ws.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:236)
> at org.jboss.ws.server.ServiceEndpointServlet.doPost(ServiceEndpointServlet.java:113)
> .....
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.soap.SOAPMessageContextImpl.getNamespaceRegistry(SOAPMessageContextImpl.java:168)
> at org.jboss.ws.soap.SOAPMessageContextImpl.getSerializationContext(SOAPMessageContextImpl.java:153)
> at org.jboss.ws.jaxrpc.SOAPFaultExceptionHelper.toSOAPMessage(SOAPFaultExceptionHelper.java:222)
> at org.jboss.ws.jaxrpc.SOAPFaultExceptionHelper.exceptionToFaultMessage(SOAPFaultExceptionHelper.java:177)
> =======================================================================================
> To run the testcase:
> ===============================================================================
> asaldhana~/jboss-4.0/testsuite>ant -Dtest=org.jboss.test.wsrp.MarkupTestCase one-test
> Buildfile: build.xml
> Overriding previous definition of reference to xdoclet.task.classpath
> one-test:
> [delete] Deleting: C:\cygwin\home\asaldhana\jboss-4.0\testsuite\output\log\test.log
> [junit] Running org.jboss.test.wsrp.MarkupTestCase
> [junit] Tests run: 6, Failures: 2, Errors: 0, Time elapsed: 10.594 sec
> [junit] Test org.jboss.test.wsrp.MarkupTestCase FAILED
> BUILD SUCCESSFUL
> Total time: 14 seconds
> ============================================================================
> Please ignore the other failing testcase - testBEAPortalInterop.
> Please change the priority and schedule of this JIRA issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-434) Support sequences of anys
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-434?page=all ]
Thomas Diesler updated JBWS-434:
--------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> Support sequences of anys
> -------------------------
>
> Key: JBWS-434
> URL: http://jira.jboss.com/jira/browse/JBWS-434
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Reporter: Thomas Diesler
> Assigned To: Alexey Loubyansky
> Priority: Critical
> Fix For: jbossws-1.0.6
>
>
> Francisco wrote:
> Are there plans for supporting sequences of anys? One of my grad students is working on WS transactions, which use things like
> <xsd:sequence>
> <xsd:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded"/>
> </xsd:sequence>
> His work should help us to get JBWS-36 done. I expect him to implement at least WS-Coordination and WS-AtomicTransaction, which should be (mostly) WS layers over the existing DTM code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-652) Add JAAS certificate authentication support to ws-security implementation
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-652?page=all ]
Thomas Diesler updated JBWS-652:
--------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> Add JAAS certificate authentication support to ws-security implementation
> -------------------------------------------------------------------------
>
> Key: JBWS-652
> URL: http://jira.jboss.com/jira/browse/JBWS-652
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: ws-security
> Reporter: Jason T. Greene
> Fix For: jbossws-1.0.6
>
>
> Currently X.509 tokens are validated against a truststore that is local to the ws-security deployment. We should offer support for delegating to JAAS/JBossSX so that JEE declarative security can reference known certificates. There is one problem with adding support for this, which is that a WS-Security message may contain many X.509 tokens (perhaps one for signature, and one for encryption), so we would have to somehow decide to pick one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-1136) Allow username to be specified in the requires list
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1136?page=all ]
Thomas Diesler updated JBWS-1136:
---------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> Allow username to be specified in the requires list
> ---------------------------------------------------
>
> Key: JBWS-1136
> URL: http://jira.jboss.com/jira/browse/JBWS-1136
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: ws-security
> Affects Versions: jbossws-1.0.1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-1.0.6
>
>
> Allow username to be specified in the requires list for endpoints so that messages without the username can be rejected.
> At the moment for EJB endpoints they can be configured using standard J2EE security so if there is no authenticated user the request is rejected, however this can't be done for the POJO endpoints.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-826) [Fatal Error] :-1:-1: Premature end of file.
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-826?page=all ]
Thomas Diesler updated JBWS-826:
--------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> [Fatal Error] :-1:-1: Premature end of file.
> --------------------------------------------
>
> Key: JBWS-826
> URL: http://jira.jboss.com/jira/browse/JBWS-826
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Reporter: Thomas Diesler
> Assigned To: Thomas Diesler
> Fix For: jbossws-1.0.6
>
>
> SOAPMessageUnMarshaller:
> SOAPMessage soapMsg = new MessageFactoryImpl().createMessageInternal(mimeHeaders, inputStream, true);
> tries to create the message and with ingnoreParseException=true. The inputStream is empty.
> Is there a way to know that the HTTP response is empty?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (JBWS-1132) Cannot consume soap/encoded response with xsi:type attribute
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1132?page=all ]
Thomas Diesler updated JBWS-1132:
---------------------------------
Fix Version/s: jbossws-1.0.6
(was: jbossws-1.0.5)
If this issue has been rescheduled to 1.0.6 it is because we currently focus 80% of our effort on JAXWS. If need a particular feature or bugfix to be included in 1.0.5 you are welcome to get involved and contribute.
> Cannot consume soap/encoded response with xsi:type attribute
> ------------------------------------------------------------
>
> Key: JBWS-1132
> URL: http://jira.jboss.com/jira/browse/JBWS-1132
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Reporter: Thomas Diesler
> Assigned To: Thomas Diesler
> Fix For: jbossws-1.0.6
>
>
> After this mornings discussion I have gone back to the first of the
> SOAP/Encoded client cases to review what they are asking for and to see
> if they are using arrays or references.
> It is actually the parsing of the response that is failing but the
> customer has also questioned the format of the request message.
> The request message is of the following type: -
> <xsd:complexType name="AssignmentSoapType">
> <xsd:sequence>
> <xsd:element type="xsd:dateTime" name="assignmentDate"
> minOccurs="1" nillable="true" maxOccurs="1">
> </xsd:element>
> <xsd:element type="xsd:long" name="assignmentNum" minOccurs="1"
> maxOccurs="1">
> </xsd:element>
> <xsd:element type="xsd:long" name="busOrg" minOccurs="1"
> maxOccurs="1">
> </xsd:element>
> <xsd:element type="xsd:boolean" name="reusePosition" minOccurs="1"
> maxOccurs="1">
> </xsd:element>
> <xsd:element type="xsd:boolean" name="terminate" minOccurs="1"
> maxOccurs="1">
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> So everything is minOccurs and maxOccurs of 1.
> The request message that is generated looks like: -
> <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
> <env:Header/>
> <env:Body>
> <ns1:cancelAssignment
> xmlns:ns1='http://www.iqnavigator.com/iqnservices'>
> <assignmentSoapType
> xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
> <ns_assignmentDate:assignmentDate
> xmlns:ns_assignmentDate='java:com.iqnavigator.frontoffice.webservice.sta
> fftrack'>2006-06-19T00:00:00.000-05:00</ns_assignmentDate:assignmentDate
> > >
> <ns_assignmentNum:assignmentNum
> xmlns:ns_assignmentNum='java:com.iqnavigator.frontoffice.webservice.staf
> ftrack'>267589</ns_assignmentNum:assignmentNum>
> <ns_busOrg:busOrg
> xmlns:ns_busOrg='java:com.iqnavigator.frontoffice.webservice.stafftrack'
> > >153801</ns_busOrg:busOrg>
> <ns_reusePosition:reusePosition
> xmlns:ns_reusePosition='java:com.iqnavigator.frontoffice.webservice.staf
> ftrack'>true</ns_reusePosition:reusePosition>
> <ns_terminate:terminate
> xmlns:ns_terminate='java:com.iqnavigator.frontoffice.webservice.stafftra
> ck'>true</ns_terminate:terminate>
> </assignmentSoapType>
> </ns1:cancelAssignment>
> </env:Body>
> </env:Envelope>
> The customer is saying the request message looks weird. I think this is
> because everything is everything to use xsi:type but we have used
> references to a schema.
> From the Soap 1.1 specification is this is because of this paragraph: -
> "Although it is possible to use the xsi:type attribute such that a graph
> of values is self-describing both in its structure and the types of its
> values, the serialization rules permit that the types of values MAY be
> determinate only by reference to a schema."
> I also noticed that the message we generate does not contain the
> encodingStyle, again from the Soap 1.1 spec is this because it is not
> mandatory: -
> "Messages using this particular serialization SHOULD indicate this using
> the SOAP encodingStyle attribute."
> The part that appears to actually be failing is the parsing of the
> response. The response message is constructed using xsi:type for each
> element however we appear to be expecting everything to be based on the
> schema.
> <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'
> xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/'
> xmlns:xsd='http://www.w3.org/2001/XMLSchema'
> xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
> <env:Header/>
> <env:Body
> env:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
> <m:cancelAssignmentResponse
> xmlns:m='http://www.iqnavigator.com/iqnservices'>
> <result
> xmlns:n1='java:com.iqnavigator.frontoffice.webservice.stafftrack'
> xsi:type='n1:WebServiceGenericResponse'>
> <responseCode xsi:type='xsd:string'>BONF</responseCode>
> <responseDesc xsi:type='xsd:string'>The business organization that
> you've referenced does not exist.</responseDesc>
> </result>
> </m:cancelAssignmentResponse>
> </env:Body>
> </env:Envelope>
> The error coming from JBossXB is: -
> 2006-08-04 18:24:12,265 INFO [STDOUT] exception
> sendCancelAssignmentToIqn ejava.rmi.RemoteException: Call invocation
> failed: org.jboss.ws.binding.BindingException:
> javax.xml.bind.JAXBException: Failed to parse source: Requested element
> responseCode is not allowed in this position in the sequence. The next
> element should be
> {java:com.iqnavigator.frontoffice.webservice.stafftrack}responseCode
> Regards,
> Darran Lofthouse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years