Since the Guice Injector is being configured based on the module instances instead of just "static" configuration classes like in Spring, so in some cases it would be preferable to instantiate the Injector with instantiated and fully configured modules.

So I would like to propose an alternative way for enabling the Guice capabilitites on the test case, by giving the user complete control over how the Injector will be created. Example:

{code}

@RunWith(Arquillian.class)

publicclassCustomInjectorTestCase{

@Deployment

publicstaticJavaArchivecreateTestArchive(){

returnShrinkWrap.create(JavaArchive.class,"guice-test.jar")

.addClasses(Employee.class,

EmployeeService.class,DefaultEmployeeService.class,

EmployeeRepository.class,DefaultEmployeeRepository.class,

EmployeeModule.class);

}

@GuiceInjector

publicstaticInjectorcreateInjector(){

returnGuice.createInjector(newEmployeeModule());

}

@Inject

privateEmployeeServiceemployeeService;

@Test

publicvoidtestGetEmployees(){

List<Employee>result=employeeService.getEmployees();

assertNotNull("Method returned null list as result.",result);

assertEquals("Two employees were expected.",2,result.size());

}

}

{code}

The above code looks pretty much similar with one major difference, the static createInjector method annotated with @GuiceInjector. This way user can have complete control how the Injector can be instantiated and the actuall type that will be used. One of potential usage is for example registering JpaPersistModle which takes as the argument name of the JPA persistence unit.

{code}

returnGuice.createInjector(newEmployeeModule(), new JpaPersistModle("jpa-test-unit"));

Just so that you don't get desperate that people have no interest: your stuff looks really cool. It's kinda counterintuitive to use Guice and CDI at the same time, but CDI is so verbose that your lib comes as a god sent. I'm spending all my time saying "damn, it would be so easier to use plain Guice for that part".

Thanks, I'll try and evaluate your extension.

Sure it perverts the core principles of CDI, but I don't care as long as I can reduce the cost of using CDI

At the moment we don't have such support in the Guice extension. Although I already done similar thing in the Spring extension, so this is definetly doable. In Guice the only difference would be the fact that this would be more "invasive" and would require some way to capture the injector and bind it with the executing thread, the same injector can be accessed from the test afterwards. In Spring this is provieded out of the box through WebApplicationContextUtils. I could try to develop such functionality.

I had quick look at the Guice Servlet source code and I think we can go with two different aproaches:

Extension ServletContextListener

This can be done on two ways.

In the first approach we can introduce class that should replace the the GuiceServletContextListener and should be used instead of it. Although this can won't be usefull with the existing code and won't be usefull with integrating with extension that are based on the Guice Servlet module.

An alternative approach would be relay on the order of the executing listeners and add listener that would "capture" the injector created by the oder context listeners. The drowback would be that it would have to declared as a last listener in the web.xml, so this might be a bit error prone solution.

And afterards annotated your test with @GuiceWebConfiguration and that's it, you can automaticly inject any dependency that has been created within your servlet container. So you should be able to inject servlets, filters and any other Guice configured instances.

Example code:

{code}

@GuiceWebConfiguration

@RunWith(Arquillian.class)

public class WebInjectorTestCase {

/**

* Creates the test deployment.

*

* @return the test deployment

*/

@Deployment

public static Archive createTestArchive() {

return ShrinkWrap.create(WebArchive.class, "guice-test.war")

.addClasses(Employee.class,

EmployeeService.class, DefaultEmployeeService.class,

EmployeeRepository.class, DefaultEmployeeRepository.class,

EmployeeModule.class, EmployeeModuleContextListener.class)

.addAsWebInfResource("WEB-INF/web.xml", "web.xml");

}

/**

* <p>The injected {@link EmployeeService}.</p>

*/

@Inject

private EmployeeService employeeService;

/**

* <p>Tests the {@link EmployeeService#getEmployees()}</p>

*/

@Test

public void testGetEmployees() {

List<Employee> result = employeeService.getEmployees();

assertNotNull("Method returned null list as result.", result);

assertEquals("Two employees were expected.", 2, result.size());

}

}

{code}

I will ask for review and I think that after this change goes to master we could have Alpha 2 release. Stricly speaking there is no road map for the Guice Extension, but in the exchange we can have pretty often releases