Providers are not exposed correctly when layering Spring and Guice

[ThrawnCA]

If a Spring configuration imports a Guice module with @EnableGuiceModules, and that module binds a Provider, but the Spring configuration is in turn packaged in a SpringModule, then the "outer" injector cannot see the bound Provider.

We're attempting to migrate an application from Guice to Spring in stages, and this is a minor hindrance. Modules that just bind classes can simply be imported for now and dealt with later, but any provider bindings have to be rewritten as Spring beans or moved to different modules.

[twicksell]

So I understand a Spring config which uses @EnableGuiceModules to work with legacy Guice library code. And I understand SpringModule being used when you have Spring code to be used in a Guice-based application. But I don't understand having a Spring config with @EnableGuiceModules that is then packed inside of a SpringModule.

Wouldn't it be simpler for those modules binding Provider types to be installed directly into the Injector as a sibling module to your SpringModule?

Let me know if I'm just missing something here. It sounds like this may be fixable, but I want to be sure I'm understanding what you're doing.

[ThrawnCA]

We use Guice-Servlet, Guice-Persist, and Guice-Struts. So, we extend ServletModule and set up a PersistFilter, which will manage transactions on each request, then StrutsPrepareFilter and StrutsExecuteFilter.

What we would actually like to do is replace Struts with Spring MVC. However, we would then need to inject a bunch of Guice-controlled objects into our Spring controllers. We could perhaps do that with @EnableGuiceModules - but many of those objects involve the data layer, so we need them to pass through the PersistFilter. So, I've tried creating a DispatcherServlet within the servlet module, and giving it a config that uses EnableGuiceModules to pull in the relevant part of our Guice config. No luck; persistence isn't initialized properly.

So we've had to go the other way, replacing the data layer - and the service layer, because we need to manage transactions - with Spring, as a prelude to replacing the web layer. Unfortunately, that was complicated by the fact that the Spring module couldn't properly reuse other bits of our Guice config. For example, if we used EnableGuiceModules to pull in a module that bound a Provider for an email Transport, Spring wouldn't be able to autowire that; thus this issue. It also seemed to strip type parameterisation and have trouble autowiring objects that used it.

I've actually succeeded in migrating the data and service layers of one of our applications, but in the end I had to dump EnableGuiceModules and just recreate the relevant beans directly in Spring config. And I still have yet to actually replace Struts, which was the original goal. And we have three more applications to migrate after this, each larger and more complex than this one.

[twicksell]

There are some merged but unreleased changes that may help with parameterized types being lost, but I'll need @dsyer's help in getting a release out.

I'll see if I can reproduce this issue and make up a fix, but if you have the time and can submit a simplified test case that might speed things along.

[dsyer]

I tried to write a test for what @ThrawnCA was describing. I'm pretty sure I haven't got it because, while I found a bug (see fd83548), it was revealed via an exception that he or she didn't mention. If we don't get a sample app, should we just do a release?

[twicksell]

I would think so. We've been testing these last set of changes for a while now and it seems fairly stable.

[dsyer]

Done (1.1.3.RELEASE is out). We can keep this issue open in case @ThrawnCA can provide a sample.