Re: DWR/Guice Integration Question
Tim,
> Also, ServerContextFactory.get().getServletContext() won't work in settings
> with more than one servlet context that provides DWR services. That wouldn't
> have mattered when the Injector was tied to the ServletContext (back before
> the introduction of CustomInjectorServletContextListener, which now allows
> an Injector to be shared by multiple ServletContexts), but at this point I
> don't see a way to completely avoid the need for something like
> withServletContext.
How often do apps end up with multiple ServletContexts? Because web
containers create their own classloader for each deployment, can't
this only happen if the DWR jar is hosted in the app server's lib
directory (higher level classloader)?
As for the withServletContext stuff - my issue is just that the way
the Guice Providers are implemented it makes it a lot more difficult
than I think it needs to be. For example, I have a Guice component
called FooRunner. A new one is created an executed as a background
thread. As it runs, it needs to send AJAX updates back to anyone
viewing the URL "/foo". In that code, I would expect that FooRunner
could directly call get on Provider<ServletContext> and/or
Provider<ServerContext> without any additional work or API
dependencies (ie: withServletContext).
It sounds like our disconnect stems from the desire to have multiple
ServletContexts, so perhaps we should start there. I really did think
there was generally only one for the vast majority of most deployments
:)
(Continue reading)