basic interop issue that Metro web service cannot be understood by JAX-WS RI client
Below are the background details:
JAXWS 2.2 TCK fails this one tests when running tests using JDK7 PIT build:
FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/refps/Client.java#RequestReferenceParametersTest_from_standalone
Here is strack trace:
04-27-2010 18:04:36: RequestReferenceParametersTest
04-27-2010 18:04:36: ERROR: Exception occurred
04-27-2010 18:04:36: ERROR: java.lang.IllegalStateException: Error in parsing
WSDL: http://localhost:8080/WSAJ2WDLReferenceParamsTest_web/jaxws/AddNumbers?wsdl
at
com.sun.xml.internal.ws.spi.ProviderImpl.createW3CEndpointReference(ProviderImpl.java:232)
at
com.sun.xml.internal.ws.spi.ProviderImpl.createW3CEndpointReference(ProviderImpl.java:170)
at
javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder.build(W3CEndpointReferenceBuilder.java:338)
at
com.sun.ts.tests.jaxws.wsa.j2w.document.literal.refps.Client.RequestReferenceParametersTest(Client.java:424)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
at
com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
at com.sun.ts.lib.harness.EETest.run(EETest.java:204)
at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:27)
Caused by: javax.xml.ws.WebServiceException:
com.sun.xml.internal.ws.policy.PolicyException: WSP1015: Server side assertion
validation failed for
"{http://www.w3.org/2006/05/addressing/wsdl}UsingAddressing" assertion.
Assertion was evaluated as "UNKNOWN".
at
com.sun.xml.internal.ws.policy.DefaultPolicyResolver.validateServerPolicyMap(DefaultPolicyResolver.java:85)
at
com.sun.xml.internal.ws.policy.DefaultPolicyResolver.resolve(DefaultPolicyResolver.java:48)
at
com.sun.xml.internal.ws.policy.PolicyWSDLParserExtension.postFinished(PolicyWSDLParserExtension.java:944)
at
com.sun.xml.internal.ws.wsdl.parser.DelegatingParserExtension.postFinished(DelegatingParserExtension.java:176)
at
com.sun.xml.internal.ws.wsdl.parser.WSDLParserExtensionFacade.postFinished(WSDLParserExtensionFacade.java:323)
at
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:160)
at
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:120)
at
com.sun.xml.internal.ws.spi.ProviderImpl.createW3CEndpointReference(ProviderImpl.java:213)
... 15 more
Caused by: com.sun.xml.internal.ws.policy.PolicyException: WSP1015: Server side
assertion validation failed for
"{http://www.w3.org/2006/05/addressing/wsdl}UsingAddressing" assertion.
Assertion was evaluated as "UNKNOWN".
at
com.sun.xml.internal.ws.policy.DefaultPolicyResolver.validateServerPolicyMap(DefaultPolicyResolver.java:77)
... 22 more
04-27-2010 18:04:36: ERROR: RequestReferenceParametersTest failed
04-27-2010 18:04:36: ERROR: Exception at:
04-27-2010 18:04:36: ERROR: com.sun.ts.lib.harness.EETest$Fault:
RequestReferenceParametersTest failed
at
com.sun.ts.tests.jaxws.wsa.j2w.document.literal.refps.Client.RequestReferenceParametersTest(Client.java:440)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
at
com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
at com.sun.ts.lib.harness.EETest.run(EETest.java:204)
at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:27)
04-27-2010 18:04:36: cleanup ok
STATUS:Failed.Test case throws exception: RequestReferenceParametersTest failed
Rama states:
Since this seems like a from java test, I am assuming the wsdl is
dynamically generated by jaxws.
If its generating assertion
{http://www.w3.org/2006/05/addressing/wsdl}UsingAddressing in the wsdl,
I suspect Metro runtime runtime is picked up by the server-side instead
of JAX-WS RI.
To answer some questions about environment:
JDK used?
Container used?
How did you install JAX-WS to the container?
Did you install Metro on to the container?
using GF from here:
>
> %which asadmin
>
/net/galapago.east/files/share/hudson/hudson_home/jobs/jaxws-tck-pit-solaris-jdk7/workspace/default/stage/glassfish/bin/asadmin
>
>
> config/asenv.conf has entry
> AS_JAVA=/space/jdks/jdk1.6.0_14
> where /space/jdks/jdk1.6.0_14 happens to be a symlink to jdk1.6.0_13
> (yes i know it's a bit confusing, but due to space reasons i had to
> just symlink to installed version of jdk)
>
> %ls -alrt /space/jdks/jdk1.6.0_14
> lrwxrwxrwx 1 root root 20 Apr 25 17:07
> /space/jdks/jdk1.6.0_14 -> /usr/jdk/jdk1.6.0_13/
>
> /space/jdks/jdk1.6.0_14/bin/java -version
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
>
> so if that is what you are asking then it's jdk1.6.0_13
>
> however, the shell that i'm running tests from,and where i execute
> asadmin start-domain domain1 has JAVA_HOME and PATH set to get java
> from JDK7:
>
> %which java
>
/net/galapago.east/files/share/hudson/hudson_home/jobs/jaxws-tck-pit-solaris-jdk7/workspace/default/jaxws-test/local.jdk/jre/bin/java
>
>
> %echo $JAVA_HOME
>
/net/galapago.east/files/share/hudson/hudson_home/jobs/jaxws-tck-pit-solaris-jdk7/workspace/default/jaxws-test/local.jdk/jre
>
>
>
> %java -version
> openjdk version "1.7.0-internal"
> OpenJDK Runtime Environment (build
> 1.7.0-internal-jprtadm_2010_04_14_00_04-b00)
> Java HotSpot(TM) Server VM (build 18.0-b02, mixed mode)
>
> >> Container used?
> GFv3
>
http://javaweb.sfbay.sun.com/java/re/glassfish/10.0.1/promoted/fcs/latest/archive/bundles/latest-glassfish.zip
>
>
> >> How did you install JAX-WS to the container? Did you install Metro on to
> >> the container?
> do i need to? i thought GFv3 already had jaxws installed.
>
> please let me know if you see something wrong with configuration that
> i need to change
> i.e. server side setting of AS_JAVA in asenv.conf should be changed to
> point to JDK7? or...?
To which Rama states:
I expected this combination based on the behavior. Basically when you
are using V3 on the server-side, you are running service with Metro
runtime and (assuming) you are running the client with standalone JAX-WS
either in RI or JDK 7.
We are mixing two products here. With the current combination, you are
like testing interop between Metro server-side and JAX-WS client-side.
Metro runtime is adding some policy assertions in the wsdl for
compatibility with Metro 1.x behavior which are not standard and not
understood by the JAX-WS standalone runtime.
I understand this is boils down as a basic interop issue that Metro web
service cannot be understood by JAX-WS RI client. Please file a bug
on standalone JAX-WS RI as a interop issue with Metro service.
I believe problem is about using Metro 2.0 on Server and just JAX-WS 2.2 RI on
client.
Can you also please confirm how you setup the classpath for wsimport in
your testing. Are you using JDK7 pit utility jars int the wsimport classpath?
On the TCK client side i do :
TS_HOME/bin/ts.jte file contains
jaxws.classes=$JAVA_HOME/lib/rt.jar:/home/jbenoit/alan/jdk7-jaxws-ant-tasks.jar:/home/jbenoit/alan/jdk7-jaxws-http-transport.jar
>
>
> but i believe i normally just set it to:
>
> jaxws.classes=$JAVA_HOME/lib/rt.jar
>
> because i don't rebuild anything, i just deploy pre-built .war's and run
>
> TS_HOME/bin/ts.jte file also contains these values:
>
> tools.jar=${jdk.home}/lib/tools.jar
>
> ###########################################################################
>
> # various flags used by the Vendors generation tools
> # @wsgen.ant.classname Complete package name of the Vendors wsgen tool
> # @wsgen.classpath Classpath to the Vendors jars that contain the
> wsgen tool
> # @wsgen.verbose Verbose flag
> # @wsgen.debug Debug flag
> # @wsimport.ant.classname Complete package name of the Vendors
> wsimport tool
> # @wsimport.classpath Classpath to the Vendors jars that contain
> the wsimport tool
> # @wsimport.verbose Verbose flag
> # @wsimport.debug Debug flag
> # @wsimport.jvmargs JVM args to pass to Vendors wsimport tool
> ###########################################################################
>
> wsgen.ant.classname=
> wsgen.classpath=${jaxws.classes}${pathsep}${tools.jar}
> wsgen.verbose=true
> wsgen.debug=false
> wsimport.ant.classname=
> wsimport.classpath=${jaxws.classes}${pathsep}${tools.jar}
>
> so wsimport.classpath is set to
>
>
$JAVA_HOME/lib/rt.jar:/home/jbenoit/alan/jdk7-jaxws-ant-tasks.jar:/home/jbenoit/alan/jdk7-jaxws-http-transport.jar:${jdk.home}/lib/tools.jar
>
>
> but before Alan added the utility jars to jaxws.classes property value
> it was just
>
> $JAVA_HOME/lib/rt.jar:${jdk.home}/lib/tools.jar
>
> does this answer your question? (Alan can clarify if required, as to
> why he added utility .jars to jaxws.classes property value, but i
> think he added them so he could rebuild, which i don't normally do, so
> i don't need these utility jars for JDK pit testing of jaxws tck).
the use of JDK 7 utility jars is for PIT testing to utilize the jax-ws impl in
JDK. Basically in your setup, you are primarily invoking the tools in JDK via
the ant wrapper tasks.
Art states:
> When we test the jaxws2.2 TCK with GFv3 we are testing the JAX-WS 2.2
> > bits that are within
> > GFv3 and test using SE6 only which is only supported in GFv3. Again we
> > use endorsed.dirs mechanism
> > to point to newly endorsed API jars for JAXWS2.2 and JAXB2.2.
Yes, I understand that you use GFv3 on server-side. But, in your TCK
environment, how do you set up the wsimport.classpath?
I am guessing that you would just use metro libraries in GFv3 instead of
standalone RI, and thats the reason wsimport will have no problem
processing that wsdl.
In Jon's case, he is not using libraries from GFv3, he is using JDK's
rt.jar, and few utility jars.
Bug
Resolved
Major
Metro web service cannot be understood by JAX-WS RI client
To summarize this in short, Standalone JAX-WS RI cannot consume Web Services
deployed on GFv3 utilizing Metro runtime though it the servcie does not use any
WSIT features.
The problem:
When a Web Service is annotated with @Addressing(required=true), JAX-WS RI adds
wsam:Addressing assertion in the wsdl. Metro 2.0 (WSIT) runtime for its
compatibility with Metro 1.x also adds non-standard wsaw:UsingAddressing
assertion. The assertion added by WSIT is not understood by standalone JAX-WS RI
wsimport/clients causing the interop issue.