search

jakartaee / authentication

Jakarta Authentication
https://eclipse.org/ee4j/jaspic
Other
23 stars 30 forks source link

TCK: spi/soap tests #215

Open brideck opened 1 month ago

brideck commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.