Wiremock: java.lang.NoSuchMethodError: org.eclipse.jetty.util.ssl.SslContextFactory.selectCipherSuites([Ljava/lang/String;[Ljava/lang/String;)[Ljava/lang/String;

[HasseGbg]

I use version 2.4.1 of wiremock.

In the method customize for class:
com.github.tomakehurst.wiremock.jetty9.CustomizedSslContextFactory.CustomizedSslContextFactory, there's a line that looks like this:
sslEngine.setEnabledCipherSuites(super.selectCipherSuites(sslEngine.getEnabledCipherSuites(), sslEngine.getSupportedCipherSuites()));

the problem is that although the method selectCipherSuites returns String[] for version 9.2.13.v20150730 of jetty which is defined in the pom file for wiremock, the newest version returns void for the same method and since the pom file doesn't have a hard dependency I get version 9.3.11.v20160721.

That causes this error when I try to configure wiremock with a httpsPort:
java.lang.NoSuchMethodError: org.eclipse.jetty.util.ssl.SslContextFactory.selectCipherSuites([Ljava/lang/String;[Ljava/lang/String;)[Ljava/lang/String;
at com.github.tomakehurst.wiremock.jetty9.CustomizedSslContextFactory.customize(CustomizedSslContextFactory.java:55)
at org.eclipse.jetty.util.ssl.SslContextFactory.newSSLEngine(SslContextFactory.java:1499)
at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:69)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:260)
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:235)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:390)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.github.tomakehurst.wiremock.jetty9.JettyHttpServer.start(JettyHttpServer.java:118)
at com.github.tomakehurst.wiremock.WireMockServer.start(WireMockServer.java:143)
at com.github.tomakehurst.wiremock.junit.WireMockClassRule$1.evaluate(WireMockClassRule.java:66)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

[tomakehurst]

WireMock's dependency on Jetty is fixed, but if you've got a newer version in your Maven deps, that's the one your app will get. Currently WireMock isn't compatible with Jetty 9.3.x so I suggest you either:

• Pin your app's version of Jetty to the one WireMock requires, or
• Use the standalone version of WireMock

[obarcelonap]

Hi @tomakehurst , is it in the roadmap the update to Jetty 9.3.x?
As long is it not fixed Wiremock is incompatible to the current release of Spring Boot.
Thank you

[tomakehurst]

Hmmm....that's a conundrum. The reason it's stuck on 9.2.x at the moment is that upgrading would require dropping JDK7 support, which quite a few folks have lobbied to keep for the time being.

I've been considering publishing a additional JAR specifically to pull up the Jetty version, but haven't found the time to figure out how to get Gradle to do this.

[tomakehurst]

@obarcelonap does using the standalone version serve as a workaround for you? It should because it shades Jetty so it should be possible for both to coexist.

[wojciechbulaty]

Another workaround is to run Wiremock as a standalone process using a https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.html

[delta-bravo]

@wojciechbulaty ProcessBuilder workaround doesn't work for me with Dropwizard and wrapped Wiremock. It forces Wiremock to be started with Dropwizard's Jetty in the classpath.

[tomakehurst]

What about the standalone JAR as a dependency?

[delta-bravo]

@tomakehurst thanks, thought about this, however this increases build times and tests complexity. Dropped https tests for now as they aren't highest priority.

[tomakehurst]

I'm surprised to hear that. I routinely use the standalone JAR on my projects now and I find the build time impact is negligible. The test complexity isn't affected at all.

[delta-bravo]

@tomakehurst sorry, I probably used incorrect wording. I meant test setup complexity in our environment - if you spawn the Wiremock jar from your tests code you need to synchronize and wait until Wiremock opens ports, etc, etc. I guess it depends on infrastructure. So the solution of forking a process, embedded Wiremock or Standalone JAR isn't ideal for us at this point.

[tomakehurst]

I think you're misunderstanding me. All I mean is switching the dependency to use standalone and otherwise doing everything exactly the same.

[delta-bravo]

@tomakehurst I do perfectly understand you. This approach suits us in many but not all cases because of how our tests are built. Thanks for your help.

[tomakehurst]

I still think we're talking at cross purposes but I won't press the matter any further.

[mgmarino]

We saw this same error message, and was solved by simple replacement in our gradle file, e.g.:

...
  testCompile "com.github.tomakehurst:wiremock-standalone:2.6.0"
...

(wiremock was simply replaced by wiremock-standalone). I believe this is what @tomakehurst was saying in the thread above, but just wanted to give an explicit example for others who encounter this same problem.

[tomakehurst]

Thanks @mgmarino , that is what I meant.

I'm going to close this off now, don't think there's anything more to be said.

[smurugu]

if you are experiencing issues with Spring boot older release try Spring boot 2.2.4.RELEASE which seems to fix the problem