Comment #12 on issue 635 by [email protected]: GuiceFilter uses wrong instance of FilterPipeline if used with multiple servlet context and multiple injectors
http://code.google.com/p/google-guice/issues/detail?id=635
The key point is "with your desired strategy for locating pipelines". In my case, once the Injector is created by GuiceServletContextListener I'd like to set the pipeline to injector.getInstance(FilterPipeline.class).
Wouldn't you want to use a delegating approach, so you can handle multiple pipelines at the same time?
Unfortunately, I don't have access to the GuiceFilter instance associated with the current server.
Yes, we have control over both the Filter and ServletContextListener(s) in our prototype application, so we can therefore tell the Filter about new injectors. We use static injection to inject a list of pipelines - this list is then updated as servlet injectors are created. Our servlets share the same basic config, just like how Guice servlets extend the same base servlet module, and this is how we "call-home" as each injector is initialized. Then as requests come in we simply iterate over the pipeline sequence looking for one that can handle the request.
My patch moves this code into GuiceFilter.init() simply because that's the only way I found for linking GuiceFilter and GuiceServletContextListener... Now that I think about it, I guess I could still implement the same thing using your patch simply by overriding Filter.init() in my GuiceFilter subclass.
Exactly, if you extend GuiceFilter (plus the patch in Issue 618) then you can choose how they're linked - personally I'd use some form of injection to loosen the coupling between the filter and context listener.
One final point: I don't understand why GuiceFilter and GuiceServletContextListener need to be separate entities. If you're going to require users to subclass GuiceFilter why not simply merge the two? Asking users to introduce two separate classes into web.xml in order to take advantage of Guice is accident-prone. We're better off having one class (especially since the two need to share data).
I assume it's separation of concerns - GuiceFilter is responsible for filtering and dispatching requests, whereas GuiceServletContextListener is responsible for setting up the injector(s). This makes sense to me, and in fact it wouldn't make sense to combine these two classes for our particular application. Besides, afaict most people shouldn't have to extend GuiceFilter, and those that do need to extend it should know enough to be able to manage the two classes.
Anyway, this is just what works for us (I prefer small patches) - it may not suit your particular application.
-- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
