Workaround for "All Providers for type class java.net.URL returned a null value"

[volosied]

In the WebSocket TCK, we have an app should fail to deploy due to misconfiguration. Some server implementations provide a placeholder URL while others do not provide any URL..

In the latter case (no URL), our server implementation encounters this exception:

java.lang.RuntimeException: Could not lookup value for field protected java.net.URL com.sun.ts.tests.websocket.common.client.WebSocketCommonClient.url
        at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:68)
        at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:51)
        at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:48)
         …

Caused by: java.lang.RuntimeException: All Providers for type class java.net.URL returned a null value: [org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider@573d07e6]
        at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:126)
        at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:66)

Example Test: https://github.com/jakartaee/platform-tck/blob/core-tck-11.0.0/websocket/spec-tests/src/main/java/com/sun/ts/tests/websocket/negdep/invalidpathparamtype/srv/onclose/WSCClientIT.java

URL Resource: https://github.com/jakartaee/platform-tck/blob/main/tcks/apis/websocket/common/src/main/java/com/sun/ts/tests/websocket/common/client/WebSocketCommonClient.java#L75C2-L75C20

Is there any workaround for this scenario? Or should a URL resource simply not be used in these cases?

If deployment fails, I wouldn't expect any URLs. (Though the test still wants to validate no endpoints are available) If the test used @ShouldThrowException, would that change the behavior any?

Appreciate any feedback. Thanks!

[jamezp]

The URL and URI are discovered via the ProtocolMetaData. This meta data is created when the deployment is done. If the deployment fails, the meta data is not retrieved and the org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider returns null.

There really isn't a way around this. One option is to inject the URI into the methods that need it instead. That should work in 1.9.2.Final+ of Arquillian.

That said, what is the reason for the failed deployment? I'm only asking because I wonder if there is something else we can do.

As a potential fix, one option might be to add an @AllowNull annotation or something similar to Arquillian which we could use as a qualifier to allow @ArquillianResource injections to allow a null injection point.

[volosied]

Thanks for the reply.

The websocket TCK has a suite of tests to validate compliance with the websocket specification. A number of tests check the misconfiguration of various applications which should result in the server removing the offending endpoint, but also removing all other endpoints. When an issue arises, a DeploymentException is thrown. A comment here details this.

Do you have an example of One option is to inject the URI into the methods that need it instead.? Maybe we can give that a shot -- though we are looking at various alternatives (including updating our Arquillian plugin).

[jamezp]

You'd just do something like:

@Test
public void invalidTypeOnCloseTest(@ArquillianResource final URI uri) throws Exception {
    // do test
}

That said, it still won't work if the deployment failed.

There is some discussion in #661 and #587 about similar issues. Similar in that it seems like a deployment shouldn't be required for this type of information to be resolved.

The idea behind having the deployment required is the URI or URL returned has the path to the deployments context. One option might be to add support the @ContainerResource annotation to allow injection of the URI or URL. However, I think that will likely take changes to implementations too so it might not be a simple change.