Re: Upgrading to GF v2.1 - Problem with WS-Addressing

> Hello Metro and GlassfishESB folks,
>  
> We have a NHIN gateway implementation from last year that we developed
> using an older OpenESB and Metro build. We are in the process of
> testing the feasibility of upgrading the base software to the latest
> Glassfish ESB v2.1. We are trying to deploy one application (and its
> dependencies) onto a fresh Glassfish ESB v2.1 installation and are
> getting errors with respect to WS-Addressing. This test does not
> involve security at the message level, or transport level.
>  
> Here is the error we get (attached log-with-policy.txt) -
>  
> Unknown WS-Addressing header
> A fault occured, possibly a specified service fault.
> javax.xml.ws.soap.SOAPFaultException: The
> "urn:ihe:iti:2007:RegistryStoredQuery" cannot be processed at the receiver
>         at
> com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:188)
>         at
> com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:108)
>         at
> com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:187)
>         at
> com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java:1108)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java:1139)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:667)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:249)
>         at
> com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:63)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>  
>  
> To remove addressing from the picture and check if we could circumvent
> the problem, I also tried commenting out the "wsaw:UsingAddressing"
> from the policy in the WSDL. We got another eror as follows (attached
> log-no-policy.txt) -
>  
> A fault occured, possibly a specified service fault.
> javax.xml.ws.soap.SOAPFaultException: Cannot find dispatch method for
> {urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0}AdhocQueryRequest
>         at
> com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:188)
>         at
> com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
>         at
> com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:187)
>         at
> com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java:1108)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java:1139)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:667)
>         at
> com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:249)
>         at
> com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:63)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>  
> Here is what our old environment was (everything works fine) -
>  
> OpenESB nightly as of 06/16/2008 - Updated HTTPBC to support 2-way SSL
> Metro 1.4 nightly as of 08/14/2008 (with several updates provided by
> the metro team to support our security and other requirements)
>  
> Here is what we are trying to upgrade to -
>  
> Glassfish ESB v2.1
> Packaged Metro 1.5
>  
> I am also attaching the WSDL that we are using to publish the service
> (the policy in here was commented out for the no-policy test).
>  
> Can someone please throw some light on what the potential problems
> could be?
>  
> Thanks in advance,
> Sourabh Pawar
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...