Hi,
In this case, most probably, the port-component-name or endpoint-address-uri
is not set correctly in sun-ejb-jar.xml
This will cause the message-security-binding not to take effect.
You may like to double check that the xml elements are correct.
Thanks.
Shing Wai Chan
V B Kumar Jayanti wrote:
> Hi,
>
> Please see my comments at the End....
>> Subject:
>> Using auth-recipient throws SOAP exception
>> From:
>> glassfish_at_javadesktop.org
>> Date:
>> Wed, 07 Mar 2007 16:45:41 -0800 (PST)
>> To:
>> users_at_glassfish.dev.java.net
>>
>> To:
>> users_at_glassfish.dev.java.net
>>
>>
>> I am able to deploy my EJB with only a sun-ejb-jar.xml descriptor. The glassfish container generates the webservices.xml and ejb-jar.xml, and updates the sun-ejb-jar.xml file passed in.
>>
>> This works somewhat:
>>
>> Here are the scenarios:
>>
>> 1) Default security provider (No sun-ejb-jar.xml provided upon deployment):
>>
>> Request policy: auth-source="content" auth-recipient="after-content"
>> Client signs and then encrypts message, all works fine.
>>
>> 2) Specify provider and request protection in sun-ejb-jar.xml to be signature based:
>>
>> Request policy: auth-source="content" defined in <message-security>
>> Client signs message
>>
>> All works fine.
>>
>> 3) Specify provider and request protection in sun-ejb-jar.xml to be signature and encrypted. (Should be same as Scenario one).
>>
>> Request policy: auth-source="content" auth-recipient="after-content" defined in <message-security>
>> Client signs and then encrypts message.
>>
>> The server throws the following exception:
>> [#|2007-03-07T17:30:37.895-0700|SEVERE|sun-appserver-pe9.0|javax.enterprise.resource.webservices.jaxws.server.soapmd|_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=eb686a92-f5a7-4a24-a83f-fbffeed3dd4d;|Error in decoding SOAP Message
>> Error in decoding SOAP Message
>> at com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.toInternalMessage(SOAPXMLDecoder.java:89)
>> at com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher.toMessageInfo(SOAPMessageDispatcher.java:187)
>> at com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher$SoapInvoker.invoke(SOAPMessageDispatcher.java:571)
>> at com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher.receive(SOAPMessageDispatcher.java:145)
>> at com.sun.xml.ws.server.Tie.handle(Tie.java:88)
>> at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:160)
>> at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:89)
>> at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:178)
>> at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:109)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:100)
>> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
>> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:71)
>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
>> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
>> at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
>> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
>> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
>> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
>> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
>> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231)
>> at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
>> at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
>> at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
>> at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
>> at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
>> at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
>> at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
>> Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot find the dispatch method
>> at com.sun.xml.ws.encoding.soap.SOAPDecoder.raiseFault(SOAPDecoder.java:674)
>> at com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.decodeDispatchMethod(SOAPXMLDecoder.java:152)
>> at com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeBodyContent(SOAPDecoder.java:337)
>> at com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeBody(SOAPDecoder.java:327)
>> at com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeEnvelope(SOAPDecoder.java:250)
>> at com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.toInternalMessage(SOAPXMLDecoder.java:81)
>> ... 29 more
>>
>>
>> Please note that the client is the same for Scenario 1 and 3, yet the outcome is greatly different.
> The root cause in this case is :
> Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot find the dispatch method
>
> Which means somehow Security was never run on the Incoming Message on the Server, which left the Message in ecncrypted form, and then the runtime tried to find out from the encrypted payload which method it should dispatch the request to and failed....
>
> This is a common error that we encounter when Client is Secured and Service is Non-Secure (Security is not enabled for the Service). Just guessing whether this is the case, because if there was some security bug then we would have seen other kind of exceptions indicating unable to decrypt of unable to verify signature etc.
>
> Can you give us more clues on the Service settings in this case.
>
> Ron, Shing-Wai : In the stack-trace shown above, i do not see either the SystemHandlerDelegate nor the CommonServerSecurityPipe in picture and this is the reason why i am saying the security runtime did not kick in for the incoming message. The encrypted message was directly given to JAXWS for dispatch and it failed as expected.
>
>> In Scenario 2, the client is the same, yet it doesn't encrypt the message.
>>
>>
> Yes this the expected behavior, when you set auth-source=content then
> the message is only Signed (and not encrypted)
>
> regards,
> kumar
>> Also, I did try manually change the generated descriptor, rather than passing in sun-ejb-jar.xml. This did not work either. same error.
>>
>> Thanks for any help.
>> [Message sent by forum member 'fefland' (fefland)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=206770
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>