I have an application that uses Jersey/JAX-RS for web services (annotations, etc) and Guice to inject service implementations. I don't really like the way Guice works with servlets directly, I prefer the Jersey way, so I had to do a bit of fussing to get the service injections to work since Guice wouldn't be creating my servlet classes, and I didn't want to deal with the HK2-Guice bridge. I did this by creating a listener class (called Configuration) that sets up the injectors in static fields upon application startup and then manually effecting the injections in each servlet class by creating a parent class that all my servlets extend with a constructor that contains the following:
public MasterServlet() {
// in order for the Guice #Inject annotation to work, we have to create a constructor
// like this and call injectMembers(this) on all our injectors in it
Configuration.getMyServiceInjector().injectMembers(this);
Configuration.getDriverInjector().injectMembers(this);
}
I know it's kind of hacky, but this works just fine in my servlets. I can use the Guice #Inject annotations on my services and switch between named implementations and so on. The problem comes when I go to set up my unit tests. I'm using JerseyTest to do my tests, but running a test against my servlets results in a 500 error with Guice saying the following:
com.google.inject.ConfigurationException: Guice configuration errors:
1) No implementation for com.mycompany.MyService was bound.
while locating com.mycompany.MyService
for field at com.mycompany.servlet.TestGetServlet.service(TestGetServlet.java:21)
while locating com.mycompany.servlet.TestGetServlet
The test looks like this:
public class TestServletTest extends JerseyTest {
#Test
public void testServletFunctional() {
final String response = target("/testget").request().get(String.class);
assertEquals("get servlet functional", response);
}
#Before
public void setup() {
Configuration configuration = new Configuration();
configuration.contextInitialized(null);
}
#Override
protected Application configure() {
return new ResourceConfig(TestGetServlet.class);
}
}
You'll notice in the setup method I am manually creating my Configuration class since I can't rely on the test container (Grizzly) to create it (I get NullPointerExceptions without those two lines). More about this below.
And here's the servlet being tested:
#Path("/testget")
public class TestGetServlet extends MasterServlet {
#Inject
MyService service;
#GET
#Produces({"text/plain", MediaType.TEXT_PLAIN})
public String testGet() {
//service = Configuration.getServiceInjector().getInstance(MyService.class);
return "get servlet functional";
}
}
Notice the commented line in the testGet() method? If I do that instead and remove the #Inject annotation above, everything works fine, which indicates that Grizzly is not creating my servlets the way I expect.
I think what's happening is that Grizzly doesn't know about Guice. Everything seems to suggest that Grizzly isn't seeing the Configuration class, despite the fact that by putting it in my test's #Before method it seems to be at least available to the classes that use it (see: the commented line in the TestGetServlet class). I just don't know how to fix it.
I'm still trying to figure this out but in the meantime I switched from Guice to HK2, which took a bit of doing but I figured this might be helpful for anyone who runs into this problem in the future.
I consider this an answer because truthfully my attempt to bypass the Guice-HK2 bridge but still use Guice with Jersey might not have been the best idea.
Switching from Guice to HK2 takes a bit of doing and there's no comprehensive guide out there with all the answers. The dependencies are really fussy, for example. If you try to use Jersey 2.27 you may run into the famous
java.lang.IllegalStateException: InjectionManagerFactory not found
error. Jersey 2.27 is not backwards compatible with previous versions due to HK2 itself. I am still working on getting that all to work, but in the meantime I had to downgrade all my Jersey dependencies to 2.26-b06 to get HK2 working properly.
Jersey thankfully already implements a bunch of HK2 boilerplate, so all you need to get injection working is proper use of #Contract, #Service (see HK2 docs for those), and then two new classes that look like this:
public class MyHK2Binder extends AbstractBinder {
#Override
protected void configure() {
// my service here is a singleton, yours might not be, so just omit the call to in()
// also, the order here is switched from Guice! very subtle!
bind(MyServiceImpl.class).to(MyService.class).in(Singleton.class);
}
}
And this:
public class MyResourceConfig extends ResourceConfig {
public MyResourceConfig() {
register(new MyHK2Binder());
packages(true, "com.mycompany");
}
}
Simple enough, but this only works for the application itself. The test container knows nothing about it, so you have to redo the Binder and ResourceConfig yourself in your test class, like this:
public class TestServletTest extends JerseyTest {
#Test
public void testServletFunctional() {
final String response = target("/testget").request().get(String.class);
assertEquals("get servlet functional", response);
}
#Before
public void setup() {
}
#Override
protected Application configure() {
return new TestServletBinder(TestGetServlet.class);
}
public class TestServletBinder extends ResourceConfig {
public TestServletBinder(Class registeree) {
super(registeree);
register(new MyHK2Binder());
packages(true, "com.mycompany");
}
}
}
Having to do this is actually fine because you can switch out the Binder for a test binder instead, in which you've bound your service to a mocked service instead or something. I haven't done that here but that's easy enough to do: replace new MyHK2Binder() in the call to register() with one that does a binding like this instead:
bind(MyTestServiceImpl.class).to(MyService.class).in(Singleton.class);
And voila. Very nice. Obviously you could achieve a similar result with Named bindings, but this works great and might even be simpler and more clear.
Hope this helps someone save the hours I spent screwing around to get this working.
Related
Here is my abstract class which starts Jersey with given Spring context:
public abstract class AbstractJerseyTest extends JerseyTest {
public void setUp() throws Exception {
super.setUp();
}
#AfterClass
public void destroy() throws Exception {
tearDown();
}
#Override
protected URI getBaseUri() {
return URI.create("http://localhost:9993");
}
#Override
protected Application configure() {
RestApplication application = new RestApplication();
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(ServerProperties.BV_SEND_ERROR_IN_RESPONSE, true);
properties.put("contextConfigLocation", "classpath:spring-context-test.xml");
application.setProperties(properties);
application.register(this);
return application;
}
}
So, the problem is that I need to access Spring bean from my test to populate database with some data.
Jersey version is 2.6
Also I found a similar question here
But it's related to Jersey 1.x so it doesn't work for Jersey 2.x
Could anyone point me in the right direction?
Solution was really simple.
I added:
#Autowired
private Repository repository;
to the AbstractJerseyTest and this field was automatically autowired during test startup. I don't know details about how it works, but it seems that when I register instance of the test in REST application
application.register(this);
it automatically autowires all beans in the test.
Normally in your case, I'd just say work with mocks, but there are cases where you may need to expose the services in the test class.
To do this without any "ugly hacks", you will need to get a handle on the ServiceLocator (which is analogous to Spring's ApplicationContext). When the Jersey app boots up, all the Spring services from the ApplicationContext are put into the ServiceLocator through HK2's Spring bridge.
The problem is JerseyTest does not expose the ServiceLocator in any way. The only way I can think of to get a hold of it, is to create your own TestContainerFactory, and create the ApplicationHandler, which exposes the ServiceLocator.
Trying to implement your own TestContainerFactory is not a walk in the park, if you don't know what you're doing. The easiest thing to do is just look at the source code for Jersey's InMemoryTestContainerFactory. If you look at the constructor for the inner class InMemoryTestContainer, you will see it creating the ApplicationHandler. This is how you can expose the ServiceLocator, through the appHandler.getServiceLocator().
So if you copied that class, and exposed the ServiceLocator, you could create your JerseyTest extension, and call the ServiceLocator.inject(Object) method to inject the test class.
public abstract class AbstractServiceLocatorAwareJerseyTest extends JerseyTest {
private final ServiceLocatorAwareInMemoryTestContainerFactory factory
= new ServiceLocatorAwareInMemoryTestContainerFactory();
private ServiceLocator locator;
#Override
public TestContainerFactory getTestContainerFactory() {
return factory;
}
#Before
#Override
public void setUp() throws Exception {
super.setUp();
this.locator = factory.getServiceLocator();
if (injectTestClass()) {
this.locator.inject(this);
}
}
public boolean injectTestClass() {
return true;
}
public ServiceLocator getServiceLocator() {
return locator;
}
}
And if for any reason you needed it, the ServiceLocator also has the ApplicationContext, which you could also expose to your test class if needed.
I put together a GitHub project, with a complete implementation, with tests if you want to take a look at it.
UPDATE
Though the OP's answer to this question works, I believe the fact that it works, is a bug. I originally deleted this answer, after the OP posted their answer, but after some testing, I believe that solution is a bug, so I've undeleted this post for anyone who doesn't like the warning1 you get when you use that solution
1. "WARNING: A provider SimpleTest registered in SERVER runtime does not implement any provider interfaces applicable in the SERVER runtime. Due to constraint configuration problems the provider SimpleTest will be ignored."
I have a Test NG listener class, that is invoked every time a test fails:
public class MyListener implements ITestListener {
#Inject
private MyBean myBean;
#Override
public void onTestFailure(ITestResult result) {
myBean.logDetails();
// log certain information about the failure,
// using the injected object.
}
}
When a test fails, the method is called, this part works fine.
The problem is the object isn't injected - it's just null. I have checked everything, and the usual conditions for CDI working are all ok.
The class has an empty constructor, and I am not calling new() on it anywhere.
Is there any way to get the object injected?
I have looked at this question but I can't see how to do CDI in the test listener.
I've also tried annotating the listener class as a TestNG test, and also making the listener a subclass of a guice factory class, but no luck and I'm a bit lost as to how to do it.
Thanks!
Currently, TestNG doesn't allow injection (with Guice) in listeners and it doesn't provide hook on listener creation (TestNG is calling new on listener itself).
https://github.com/cbeust/testng/issues/279
But if you run TestNG with code, you may ask an instance to your injection framework and provide it to TestNG.
Using one of the replies of the previously linked github issue (thanks #juherr) here the TestNG 7.4.0 answer, without #Inject but working nonetheless.
To use the baked in Guice dependency injection container from a listener, you need to get the instance of the Injector from the suite in this way:
#Override
public void onTestFailure(ITestResult result) {
final Injector parentInjector = result.getTestContext().getSuite().getParentInjector();
final YourGuiceModule module = parentInjector.getInstance(YourGuiceModule.class);
final MyBean myBean = parentInjector.createChildInjector(module).getInstance(MyBean.class);
myBean.logDetails();
}
For this to work, you need to make sure that every test running this listener have YourGuiceModule and MyBean should be provided by that forementioned module.
The exact answer to your question will be possible to solve in version 7.5.0, but still only if you use Guice.
Here a utility method i've created in Kotlin to provide any instance:
private fun <T> ISuite.getInstanceOf(clazz: Class<T>): T =
with(this.parentInjector) {
getInstance(YourModule::class.java)
.let {
createChildInjector(it)
.getInstance(clazz)
}
}
Opinion: i prefer (and suggest) to have a compile-time check for dependency injection provided objects: In another solution, I've solved this by using dagger and by ditching completely the testng dependency injection provider.
I'm writing custom JAX-RS 2.0 application (under Jersey 2.3.1) which holds some data for use by all the resources.
public class WebApp extends org.glassfish.jersey.server.ResourceConfig {
public WebApp() {
packages("my.resources.package");
}
}
(I could use API's javax.ws.rs.core.Application as well, the described result is the same)
Then I inject the object into a resource
#Path("test")
public class Test {
#Context
Application app;
#GET
#Path("test")
public String test() {
return "Application class: " + app.getClass();
}
}
However, the result of a call is
Application class: class org.glassfish.jersey.server.ResourceConfig$WrappingResourceConfig
which makes me use some ugly tricks like
if (app instanceof WebApp) {
return (WebApp) app;
} else if (app instanceof ResourceConfig) {
return (WebApp) ((ResourceConfig) app).getApplication();
}
My understanding of JAX-RS 2.0 spec section 9.2.1:
The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the #Context annotation. Access to the Application subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the Application subclass itself since this would create a circular dependency.
is that application-supplied Application subclass is mine WebApp, not JAX-RS implementation-specific wrapper.
Also, changing this fragment
#Context
Application app;
to this
#Context
WebApp app;
causes app to be null, due to ClassCastException during context injection, so the declared type doesn't matter.
Is it a bug in Jersey or my misunderstanding?
UPDATE: I checked the behaviour under RESTEasy 3.0. The injected object is my WebApp, without any wrappers. I'd call it a bug in Jersey.
This doesn't seem like a bug. According to JAX-RS 2.0 spec you can inject Application into your resource classes (for example) but it does not say anything about directly injecting custom extensions of the Application. Not sure what your use-case is but you can register custom HK2 binder that will allow you to inject directly WebApp into resources:
public class WebApp extends org.glassfish.jersey.server.ResourceConfig {
public WebApp() {
packages("my.resources.package");
register(new org.glassfish.hk2.utilities.binding.AbstractBinder() {
#Override
protected void configure() {
bind(WebApp.this);
}
});
}
}
I too have encountered this using Jersey 2.4.1.
FWIW: I agree it seems like a bug according to the spec para 8.2.1. The statement "The instance of the application-supplied Application subclass" seems perfectly clear.
I have an alternative workaround that doesn't involve glassfish.hk2 but still concentrates the Jersey-specific code in the Application-derived class.
public class MyApp extends ResourceConfig {
...
static MyApp getInstance( Application application) {
try {
// for a conformant implementation
return (MyApp) application;
} catch (ClassCastException e) {
// Jersey 2.4.1 workaround
ResourceConfig rc = (ResourceConfig) application;
return (MyApp) rc.getApplication();
}
}
...
}
public class MyResource {
...
#Context Application application;
...
SomeMethod() {
... MyApp.getInstance( application);
}
}
Hope this is useful.
This appears to be fixed in a later version og Jersey. The same approach works for me with Jersey 2.16 at least. My injected Application object is of the correct subclass without any wrapping whatsoever.
Edit: Or maybe the version is irrelevant after all. Please see the comments to this answer.
At the moment I'm using a static singleton to obtain the singleton service that Guice 3.0 builds for me through DI - I believe this a terrible hack and not at all the intended way to use Guice for DI, and complicates unit testing.
public class ServiceProvider {
private static ServiceProvider instance = new ServiceProvider();
private MyService myService;
public ServiceProvider() {
Injector myInjector = Guice.createInjector(new MyModule());
myService = noobmeterInjector.getInstance(MyService.class);
}
public static MyService getMyService() {
return instance.myService;
}
}
However, I'm not quite sure how to fix that, as I need that service in at least four different spots:
Stripes ActionBeans - I think the Stripes Guice plugin would help me there, and I did connect it but ended up with multiple parallel MyServices
ServletContextListener - I think possibly the Guice Servlet module can help somehow, although I'm struggling with the documentation as it mostly discusses replacing web.xml with Guice configuration (not my priority at this point) and injecting HttpServletRequests into Guice-constructed objects (again not what I want to do)
Quartz Jobs - here I found something relevant, but not sure if it won't end up still creating a "parallel" MyService to the other ones
Batch processes run from command line - this is the easy part
The MyService service is intended to be a singleton (other services it owns open DB/MQ connections, etc., so creating multiple of these would be bad).
Is there some simple way how to do this in Guice that I'm missing?
So there's a few issues with your code snippet.
You should no longer be implementing singletons as static variables; let Guice do the lifecycle management for you.
In this example, ServiceProvider is basically a Service Locator implementation, which is unnecessary since you're using Guice.
It's good practice to keep the Injector creation as "high" up as possible. The main method where your server starts would be a good place.
I've added some code to demonstrate.
public class Server {
public static void main(String[] args) {
Injector injector = Guice.createInjector(new MyModule());
// Your code here.
}
}
public class MyModule extends AbstractModule {
protected void configure() {
// Assuming MyService implements Service
bind(Service.class).to(MyService.class).in(Singleton.class);
}
}
I have a Jersey Resource that I want to test with JUnit. The resource uses Guice Providers to inject certain fields:
#Path("/example/")
class ExampleResource {
#Inject
Provider<ExampleActionHandler> getMyExampleActionHandlerProvider;
#GET
#Produces(MediaType.APPLICATION_JSON)
public List<ExamplePojo> getExampleList() {
ExampleActionHandler handler = getMyExampleActionHandlerProvider.get();
handler.doSomething();
...
This all works beautifully when using a real server to serve the API, however testing it is problematic.
My test class currently looks something like:
public class ApiTest extends JerseyTest {
public ApiTest() throws Exception {
super();
ApplicationDescriptor appDescriptor = new ApplicationDescriptor();
appDescriptor.setContextPath("/api");
appDescriptor.setRootResourcePackageName("com.my.package.name");
super.setupTestEnvironment(appDescriptor);
}
#Test
public void testHelloWorld() throws Exception {
String responseMsg = webResource.path("example/").get(String.class);
Assert.assertEquals("{}", responseMsg);
}
}
Clearly, Guice isn't getting the opportunity to initialize the fields in ExampleResource so that the handler.doSomething() call doesn't result in a NullPointerException.
Is there a way to tell Jersey to instantiate the ExampleResource class using Guice so that the Provider works?
One way to do it is to break the tests to few steps. You need to create the injector you're configuring the service with and test that injector (see Testing Guice Servlet bindings and Testing Guice can init servlets). Using these tests you make sure you have the right bindings in place.
Once you have the injector, get the ApplicationDescriptor object from it with
ExampleResource exampleResource = injector.getInstance(ExampleResource.class);
Assert.assertEquals(myList, getExampleList());