addressing not enabled on provider-based endpoint

[glassfishrobot]

Filing on behalf of Mike Grogan:

It looks like the Addressing Feature is not turned on by the WSDL processing for a Provider-based endpoint.

Here is a simple way to reproduce the problem:

1. Check out and build the jax-ws-sources project. 2. Go to the dist/samples/provider subdirectory and modify the sample as follows. a. prepend $AS_HOME/lib/*.jar to all the javac and java classpaths in the build script so the sample builds and runs with the WSIT libraries. Set the build variable "log" to "true" to see the messages. b. Add a Policy containing UsingAddressing to the WSDL and attach it to the Binding for the service. c. Do ant server;ant client;ant run... The invocation fails because there are no addressing headers on the response message, although the WSDL returned by a GET request contains the correct Policy and the client sends a request with the required addressing headers. d. Add @javax.xml.ws.soap.Addressing to the Provider class and do ant clean;ant server;ant client;ant run.. The invocation works correctly. There are correct addressing headers on request and response messages.

Environment

Operating System: All Platform: Macintosh

Affected Versions

[current]

[glassfishrobot]

Reported by ritzmann@java.net

[glassfishrobot]

japod@java.net said: Starting...

Will go with: $ cvs -d:pserver:cvs.dev.java.net:/cvs export -r mr-21 jax-ws-sources

[glassfishrobot]

japod@java.net said: Updating the [how to reproduce] steps:

1. checkout [jax-ws-sources] project: $ cvs -d:pserver:cvs.dev.java.net:/cvs export -r mr-21 jax-ws-sources 2. build [jax-ws]: $ cd jax-ws-sources/jaxws-ri ; ant dist 3. install glassfish take it from https://glassfish.dev.java.net/downloads/v2-b38.html set AS_HOME to point to glassfish base directory 4. go to provider sample dir: cd dist/jaxws-ri/samples/provider 5. update classpath: in etc/deploy-targets.xml: change: <property name="lib.home" value="$

{env.JAXWS_HOME}

/lib"/> to: <property name="lib.home" value="$

{env.AS_HOME}

/lib"/> 6. update [etc/AddNumbers.wsdl]: (will attach it) 6.1. add namespaces defs: -cut here- xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" -cut here- 6.2.attach the following policy to binding: -cut here-

-cut here- 7\. run glassfish: $ $AS_HOME/bin/asadmin start-domain 8\. build and deploy server: $ ant server 9\. build client: $ ant client 10\. run client: $ ant -Dlog=true run [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: A header representing a Message Addressing Property is not valid and the message cannot be processed [java] at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:163) [java] at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:94) [java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:236) [java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:206) [java] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:103) [java] at $Proxy29.addNumbers(Unknown Source) [java] at provider.client.AddNumbersClient.main(Unknown Source) [java] Java Result: 1

[glassfishrobot]

japod@java.net said: Created an attachment (id=291) updated wsdl with addressing policy attached

[glassfishrobot]

japod@java.net said: In [com.sun.xml.ws.assembler.PipelineAssemblerFactoryImpl], WSA pipe is not created although following gets invoked: p = context.createWsaPipe(p);

i.e. not a policy issue

Will attach a snapshot from debugger...

[glassfishrobot]

japod@java.net said: Created an attachment (id=292) wsa pipe is not created properly in pipeline assembler

[glassfishrobot]

japod@java.net said: Reassigning to jaxws-runtime since I think the root cause is in [com.sun.xml.ws.api.pipe.ServerTubeAssemblerContext] in [createWsaTube] method:

-cut here- public Tube createWsaTube(Tube next)

{ if (binding instanceof SOAPBinding && AddressingVersion.isEnabled(binding) && wsdlModel!=null) return new WsaServerTube(wsdlModel, binding, next); else return next; }

-cut here-

Here it checks AddressingVersion.isEnabled(binding), which fails but before that [com.sun.xml.ws.addressing.policy.] had added addressing feature to appropriate WSDLPort (see the snapshots I will attach in a minute)

It seems that the addressing feature does not get propagated to [SOAPBindingImpl] properly...

Will attach also the testcase archive.

Notice: I have tried adding the feature also to port.getBinding() in [AddressingModelConfiguratorProvider], but did not work anyway

[glassfishrobot]

japod@java.net said: Created an attachment (id=293) addFeature gets called on WSDLPort after parsing service wsdl file

[glassfishrobot]

japod@java.net said: Created an attachment (id=294) but wsa pipe is not created

[glassfishrobot]

japod@java.net said: Created an attachment (id=295) testcase archive

[glassfishrobot]

japod@java.net said: Adding Vivek to cc list

[glassfishrobot]

ritzmann@java.net said: reassigning to owner of subcomponent

[glassfishrobot]

vivekp@java.net said: Assigning to Rama.

[glassfishrobot]

vivekp@java.net said: In case of Provider and Dispatch the wsdl extensibility elements are looked at only if RespectBindingFeature is enabled.

So what I would suggest (after discussing with Rama) is that annotate your endpoint with @RespectBinding, I guess it should work fine then.

[glassfishrobot]

ritzmann@java.net said: Vivek, I'm not sure I'm following entirely. We are not talking about a WSDL extensibility element, but a policy assertion that is being translated into a WebServiceFeature. The feature is not being picked up.

[glassfishrobot]

vivekp@java.net said: policy elements in the wsdl is extensibility elements. So anything that policy parses and sets equivalent features on WSDLPort is not looked into in case of Provider unless you annotate the Provider endpoint with @RespectBinding annotations. This is so much to comply by spec and keeping the Provider/Dispatch based applications to give all the control by default and anything that runtime wants to handle - needs to be enabled by the user.

[glassfishrobot]

mikeg@java.net said: This is the same issue as 421. As it turns out, JAX-WS and Policy both work correctly. The problem was that in the test case, the @RespectBinding was not present on the endpoint. For a Provider endpoint, this is a sensible and necessary requirement.

[glassfishrobot]

jitu@java.net said: setting target milestone 1.0

[glassfishrobot]

File: AddNumbers.wsdl Attached By: japod@java.net

[glassfishrobot]

File: addrModelConfigProvider.png Attached By: japod@java.net

[glassfishrobot]

File: provider.tar.gz Attached By: japod@java.net

[glassfishrobot]

File: svrTubeAssemblerContex.createWsaTube.png Attached By: japod@java.net

[glassfishrobot]

File: wsaPipeNotCreated.png Attached By: japod@java.net

[glassfishrobot]

Was assigned to ramapulavarthi@java.net

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-435

[glassfishrobot]

Marked as incomplete on Tuesday, November 13th 2007, 11:46:28 pm