TCK: spi/soap tests

[brideck]

I'm not sure if all of this is a challenge or if I just don't understand how the ported spi/soap tests in the 3.1.x TCK are supposed to work.

First, for purposes of EE 11 implementations, shouldn't these tests be optional? The test application requires SOAP/XML WS which were removed as technologies from the platform in EE 11. As such, we'd want a property to control their execution in the TCK, similar to the skipJACC one that's already available for those tests.

Second, is it understood that a user is supposed to make some pom-level changes in order to make these work? There's nothing in particular in the TCK guide about these tests. I'm attempting to execute them against Open Liberty and they blow up on the test side with this exception:

java.util.ServiceConfigurationError: com.sun.xml.ws.assembler.metro.dev.ClientPipelineHook: Provider com.sun.enterprise.security.webservices.client.ClientSecurityPipeCreator not found
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:601)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1233)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1242)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1292)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1328)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1412)
	at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:282)
	at com.sun.xml.ws.util.ServiceFinder.toArray(ServiceFinder.java:227)
	at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.loadSPs(SecurityTubeFactory.java:363)
	at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.getClientTublineHooks(SecurityTubeFactory.java:280)
	at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.createTube(SecurityTubeFactory.java:217)
	at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:53)
	at com.sun.xml.ws.assembler.MetroTubelineAssembler.createClient(MetroTubelineAssembler.java:112)
	at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:312)
	at com.sun.xml.ws.client.Stub.<init>(Stub.java:279)
	at com.sun.xml.ws.client.Stub.<init>(Stub.java:212)
	at com.sun.xml.ws.client.Stub.<init>(Stub.java:227)
	at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:68)
	at com.sun.xml.ws.client.WSServiceDelegate.getStubHandler(WSServiceDelegate.java:806)
	at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:795)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:426)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:392)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:373)
	at jakarta.xml.ws.Service.getPort(Service.java:139)
	at ee.jakarta.tck.authentication.test.basic.soap.HelloService.getHelloPort(HelloService.java:72)
	at ee.jakarta.tck.authentication.test.basic.SoapProfileSPITest.runOnce(SoapProfileSPITest.java:80)
        ...

The com.sun.xml.wss.provider.wsit stuff in that stack comes from the glassfish dependency defined in the pom and doesn't have anything to do with Open Liberty. Before porting, these tests would have been run through the JavaTest environment which allows an implementation to define the classpath, etc. in ts.jte for test execution.

[arjantijms]

First, for purposes of EE 11 implementations, shouldn't these tests be optional? The test application requires SOAP/XML WS which were removed as technologies from the platform in EE 11. As such, we'd want a property to control their execution in the TCK, similar to the skipJACC one that's already available for those tests.

True, we should do a maintenance release to include such property.

Before porting, these tests would have been run through the JavaTest environment which allows an implementation to define the classpath, etc. in ts.jte for test execution.

The idea is indeed that instead of editing ts.jte, one would edit pom.xml. There's also a system property for SOAP/XML WS for the provider that takes precendence; "jakarta.xml.ws.spi.Provider". Obviously whatever it points to has to be on the class path.

[brideck]

The idea is indeed that instead of editing ts.jte, one would edit pom.xml. There's also a system property for SOAP/XML WS for the provider that takes precendence; "jakarta.xml.ws.spi.Provider". Obviously whatever it points to has to be on the class path.

This probably needs to be documented somewhere then. It only really talks about using the Glassfish example as a guide, but all of the properties used there are for the servlet tests, not the SOAP ones. The SOAP ones just get to work as-is because of the contents of the spi/soap/pom.xml.

[arjantijms]

The SOAP ones just get to work as-is because of the contents of the spi/soap/pom.xml.

Yes, SOAP has indeed been a bit of an afterthought, mainly because of all the deprecation around SOAP. We should also have deprecated the support for SOAP in Authentication itself. My bad.

[markt-asf]

Please label this issue as a formal TCK challenge. All the tests that depend on SOAP either need to be optional along the lines of the existing skipXxxx properties or removed completely.

[arjantijms]

All the tests that depend on SOAP either need to be optional along the lines of the existing skipXxxx properties or removed completely.

Indeed. We discussed a "skipXxxx" property before, so that would be the prefered solution for this challenge I think.

[brideck]

Indeed. We discussed a "skipXxxx" property before, so that would be the prefered solution for this challenge I think.

Working on changes to that effect as we speak. I still intend to have something up by the end of the week.

[brideck]

@markt-asf Do you want the two tomcat profiles in the top-level POM to default skipSOAP to true?

[markt-asf]

Yes please. Tx.