metro/wsit java client to glassfish using ws-security

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

metro/wsit java client to glassfish using ws-security

I am familiar with JAX-WS but new to Metro/WSIT.

Using glassfish v3.1.2.2

I have successfully built the Sample - SecureCalculatorApp, and SecureCalculatorClientApp,
successfully deployed and run.

My focus is on WS-Security - not quality of service.

I have built client by referencing the deployed service's WSDL - and configured the Web Service Attributes
to match the working GF Deployed Client's Web Service Attributes -- ie - default username, password, and trustStore,
trustStore password and trustStore alias.

I have been debugging - using sources for glassfish v3.1.2.2, and Metro Web Services Stack Project sources,
and the JAX-WS used in gfv3.1.2.2 and also the lastest Metro snapshot sources for the client side version 2.3.1,
and the JAX-WS sources used in metro 2.3.1 -- jaxws-2.2.10.

Again - the deployed client war, and deployed service war do successfully communicate using ws-security.

When the java stand alone client - built from either of the Metro versions mentioned I get similar errors.

The gfv3.1.2.2 error msg is:
SEVERE: WSS0265: Primary Policy Violation occured
SEVERE: com.sun.xml.wss.XWSSecurityException: com.sun.xml.wss.impl.PolicyViolationException:
 Expected Signature Element as per receiver requirements, found  ReferenceList

I also built from scratch a simple web service, web client, and java client of the service - simple sayHello.
And configured metro setting in netbeans like the defaults in the SecureCalulatorApp sample.
Again - the deployed client successfully talks with the deployed Service, but the java client gets the same
type of error.

I have looked at the SOAP messages sent both by deployed client, and stand-alone client.
Those request/response messages have been saved to files and can be shared.
I have attached 2 JPG files of the XML tree of both the bad request/response from java client,
and good request/response from the deployed client.

Please advise how to proceed.

BTW - I have been unable to get any Metro/WSIT examples mentioned above to work at all with gfv4,
both when configured to use the  keystore/cacerts files with gfv4 default domain, and the gfv3.1.2.2 domain.


BadRequestResponseXml.JPG (142K) Download Attachment
GoodRequestResponseXml.JPG (184K) Download Attachment