Comment #14 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
> Wouldn't you want to use a delegating approach, so you can handle
multiple pipelines at the same time?
What does a delegating approach really mean in this case? I want to run
multiple unit tests in
parallel where each @Test method gets a separate Injector and web server
to run against.
Usually I'd run that sort of test (ie. more integration test than unit
test) in an isolated classloader or jvm to avoid static clashes elsewhere
in the app or container, but I can see what you're trying to achieve.
This issue covers many use-cases, and while a last-one-wins approach is
fine for your test use-case it won't work for our situation where we want
to manage multiple injectors concurrently under a single filter instance.
For example, injector A maps /a -> servletA while at the same time injector
B maps /b -> servletB.
A delegating approach sounds like we're saying: if server 1 cannot handle
a request, server 2
should try to, then server 3 and so on. That sounds more like fail-over
to me and doesn't really
make sense for my unit test use-case.
Our use-case is a plugin system, with one injector per-plugin running
inside the same servlet container. Each plugin can contribute servlet
bindings, so we have a central delegating filter that checks each active
pipeline to see whether it can handle the incoming request.
> 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.
Agreed, which is why I'd prefer adding code to GuiceFilter that
automatically tries grabbing a
FilterPipeline from GuiceServletContextListener at init() time. If I
understand your use-case
correctly, you want to be able to modify the filter pipeline multiple
times over the lifetime of
the Filter (whereas I only want it set once). What we can do is have
init() pick up reasonable
defaults and add the setter method you proposed. This way both our
use-cases are possible.
Sure, you could easily build a single solution on top of the patch from
issue 618.
--
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.
