-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatiblity with Dropwizard 1.0? #95
Comments
I haven't seen this exception before, can you supply a runnable code sample that reproduces the issue? Also, can you make sure you're running version 1.0.0.2 of dropwizard-guice |
I'm definitely on 1.0.0.2: +--- com.hubspot.dropwizard:dropwizard-guice:1.0+ -> 1.0.0.2 The failing unit test is for a core element in our classes and tied in with everything. I'd have to spend a while crafting something from scratch. Here's more context on the error though, maybe that'll help. It's when using jaxws UriBuilder.
|
Well, it's something classpath related, not code related. Even this tiny test has the same a failure:
Maybe I need to specifically exclude a library or a transitive dependency? I changed only these dependencies to point the latest version of each:
Here is the "gradle dependencies" output:
|
I haven't had a chance to dig into the code yet, but my guess is that since |
If it works with 1.0.0.1 that would confirm my suspicion |
Yep, you nailed it. If I specify 1.0.0.1 the test passes, with 1.0.0.2 it fails. If there's anything you'd like me to try, let me know, I'm happy to help. |
So this is interesting/odd....that particular test passes, but a different test in another module fails with the same error even with 1.0.0.1. So putting 1.0.0.1 didn't fix the problem, it just shuffled the classpath such that some UriBuilder invocations work and some don't. |
I'm guessing the underlying problem is related to this: Apparently, there's a cyclic dependency introduced with Jersey2 and Guice, and Dropwizard 1.0 pulls in Jersey2. |
+1 to find a solution to this issue. |
I believe this happens when |
+1 to find a solution to this issue. |
For me reverting to 1.0.0.1 version works. Client client = ClientBuilder.newClient(new ClientConfig().register(HelloClient.class)); After reverting back a version , the above code worked for me |
I am not sure if this helps, but I had a similar issue with classes using I was able to solve by running a test containing public class GuiceCompatibilityTest {
@ClassRule
public static DropwizardAppRule<FleetServiceConfiguration> rule = new DropwizardAppRule<>(
TestApplication.class,
TestApplication.getConfigFilepath()
);
@Test
public void testBlank() {
assertTrue(true);
}
@After
public void tearDown() throws Exception {
JerseyGuiceUtils.reset();
}
} |
I ran into the same issue, but I didn't want to run a DropwizardAppRule. Not only does that feel more like an integration test to me, but it also takes a lot longer to initialize. So, I decided to write a junit rule to connect a guice injector to jersey, following the code used in the GuiceBundle class. import org.glassfish.hk2.api.ServiceLocator;
import org.glassfish.hk2.extension.ServiceLocatorGenerator;
import org.junit.rules.ExternalResource;
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.Stage;
import com.google.inject.servlet.ServletModule;
import com.squarespace.jersey2.guice.JerseyGuiceModule;
import com.squarespace.jersey2.guice.JerseyGuiceUtils;
/**
* Code copied from {@link com.hubspot.dropwizard.guice.GuiceBundle}
* to create a guice injector for jersey2 for unit testing.
*/
public class JerseyGuiceRule extends ExternalResource {
@Override
protected void before() throws Throwable {
Injector baseInjector = Guice.createInjector(Stage.TOOL, new ServletModule());
JerseyGuiceUtils.install(new ServiceLocatorGenerator() {
@Override
public ServiceLocator create(String name, ServiceLocator parent) {
if (!name.startsWith("__HK2_Generated_")) {
return null;
}
return baseInjector.createChildInjector(new JerseyGuiceModule(name))
.getInstance(ServiceLocator.class);
}
});
}
@Override
protected void after() {
JerseyGuiceUtils.reset();
}
} To use in your test class, simply create a class rule: import static org.junit.Assert.*;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.Status;
import org.junit.ClassRule;
import org.junit.Test;
public class JerseyTest {
@ClassRule
public static JerseyGuiceRule rule = new JerseyGuiceRule();
@Test
public void testJersey() {
Response response = Response.status(Status.BAD_REQUEST).build();
assertEquals(Status.BAD_REQUEST.getStatusCode(), response.getStatus());
}
} |
I am getting |
what about newer versions of dropwizard-guice? |
Unfortunately this appears to be a side effect of the fix for #88
With the new dependency order this warning is gone, but it means that you won't be able to use any Jersey classes (including the client) without first populating the I see the following options to fix:
|
+1 for fixing this issue |
+1 for a fix |
I'm using 1.0.0.2 with Dropwizard 1.0.5 and I'm seeing both the warning #88 tries to fix and the error this issue describes:
Reverting to 1.0.0.1 doesn't help. Reverting Dropwizard to 1.0.4 doesn't help. Going down to 1.0.3 does, even with dropwizard-guice version 1.0.0.2. I'm still seeing the warning from #88, though. |
+1 seeing With DW 1.0.5, and DW guice 1.0.0.2 |
I believe Squarespace/jersey2-guice#39 will fix the issue with using Jersey client in tests (specifically this line). I haven't had time to work on compatibility beyond dropwizard 1.0.0 but I'll try to get to it soon |
I'll be following up with jersey2-guice maintainers to see if we can get this fixed on their end. In the meantime you should be able to work around this by adding something like this to your tests: @BeforeClass
public void ensureServiceLocatorPopulated() {
JerseyGuiceUtils.reset();
} |
@peterbecker
|
I just released version 1.0.6.0 of dropwizard-guice which uses dropwizard 1.0.6. It should show up in Maven central soon and if you use that version you should be able to use dropwizard 1.0.6 without exclusions or mucking with versions. Still no reply from the jersey2-guice maintainers on the other issue though. |
Thanks JerseyGuiceUtils.reset(); did the trick (with dropwizard 1.1.0, jersey 2.25.1 and dropwizard-guice 1.0.6.0). |
@panghy can you tell me exactly what you did to make dw-guice run with dw 1.1.0? I'm getting a
error... |
I'm trying to upgrade to Dropwizard 1.0 and I'm getting a failure running a unit test (haven't tried production yet since I'm fixing the tests first).
I filed it in the Dropwizard product and the fellow there says it looks like an incompatibility in libraries with the Guice module used by dropwizard-guice. Specifically he says "This looks like an incompatibility between HK2 (used by Jersey) and Google Guice which shows by including the dropwizard-guice module."
Is dropwizard-guice supposed to work with Dropwizard 1.0 or is that still in the works?
Here's the exception trace I get:
The text was updated successfully, but these errors were encountered: