On Apr 28, 2009, at 6:33 PM, Richard Wallace wrote:
> Hey Paul,
>
> The context listener looks ok for the general approach, but still
> doesn't solve the problem when running in OSGi because there isn't
> really a concept of servlet listeners there (sure you can use Pax Web
> and their extensions, but as of right now there is no standard way of
> registering context listeners).
>
Oh, i think i misunderstood, i thought a servlet container would still
be used? if not then how would HTTP requests be dispatched?
I guess i am not understanding the big picture of how things are glued
together. When an instance of ServletContainer is obtained what
happens next? would the ServletContainer be initialized by calling
Servlet.init(ServletConfig ) ?
> For the OSGi use-case, it really would be nice if we had an additional
> constructor that takes a ResourceConfig (to be used as the default
> ResourceConfig) and an IoCComponentProviderFactory. This constructor
> could even be restricted to package-only access if the implementation
> of ServletContainerFactory I suggested lived in the
> com.sun.jersey.spi.container.servlet package.
>
OK.
One problem is that the ServletContainer does require access to the
ServletConfig/ServletContext or FilterConfig/ServletContext, which is
obtained when a servlet container calls the init(ServletConfig ) or
init(FilterConfig respectively).
Perhaps it would be best if the servlet factory returned instance of
Servlet?
Paul.
> Rich
>
> On Tue, Apr 28, 2009 at 6:27 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi Richard,
>>
>> WebComponent is already composed within ServletContainer (in the
>> 1.0.3 code
>> base and beyond) but i agree the inheritance of SevletContainer for
>> Guice/Spring support is a problem.
>>
>> I wonder if we could instead declare Guice and/or Spring support
>> using
>> context listeners?
>>
>> The ServletContainer would then pick up those declarations. There
>> is already
>> support for the registration of one or more IoC frameworks by
>> registering
>> instances as singletons in the ResourceConfig, rather than via the
>> WebApplication.init method. This is how EJBs are supported.
>>
>> Some context associated helper classes for the registration and
>> initiation
>> of the IoC stuff should do it.
>>
>> A Spring context listener would do:
>>
>> ServletContext sc = ...
>> ConfigurableApplicationContext springContext = ...
>> Initializer sf = new SpringIoCInitializer(springContext);
>> JerseyContext.get(sc).registerInitializer(i);
>>
>>
>> public class SpringIoCInitializer implements Initializer {
>> ...
>>
>> void init(ResourceConfig rc) {
>> rc.getSingletons().add(new
>> SpringComponentProviderFactory(rc,
>> springContext));
>> }
>> }
>>
>>
>> Then the WebComponent would do:
>>
>> ResourceConfig rc = ...
>> ServletContext sc = ...
>> List<Initializer> il = JerseyContext.get(sc).getInitializers().;
>> for (Initializer i : il) {
>> sf.init(rc)
>> }
>>
>> Paul.
>>
>>
>>
>>
>> How about we modify things so Spring and/or Guice support is
>> declared using
>> web context listeners?
>>
>> I think we should modify registration
>>
>> On Apr 28, 2009, at 5:53 AM, Richard Wallace wrote:
>>
>>> Hey all,
>>>
>>> I was just taking a look at this and trying to see how Tatu's
>>> suggestion would apply. The most obvious thing is to create a
>>> ServletContainerProvider and register it in a BundleActivator. The
>>> only problem I have with that is we lose the ability to use Guice or
>>> any other IoC container because currently Jersey relies on using
>>> inheritance instead of composition to configure this stuff.
>>> Ideally,
>>> we could have something like the following interface
>>>
>>> public interface ServletContainerFactory {
>>> ServletContainer createServletContainer();
>>> ServletContainer createServletContainer(ResourceConfig rc);
>>> ServletContainer createServletContainer(ResourceConfig rc,
>>> IoCComponentProviderFactory iocCompnentProviderFactory);
>>> }
>>>
>>> We might not even want the 1st method that doesn't take any
>>> ResourceConfig because there is almost no reasonable way the
>>> classpath
>>> scanning is going to work. So we probably always want to require a
>>> ResourceConfig to be provided as in the 2nd and 3rd variations. The
>>> third variation would allow you to pass in the way in which
>>> components
>>> should be created.
>>>
>>> This is probably the ideal way we could do it (at least for
>>> servlets,
>>> I'm not sure about the Grizzly or other http providers), but would
>>> require some fairly significant refactoring of at leas the
>>> ServletContainer and the WebComponent classes to make them use
>>> composition as opposed to inheritance (which is a big WIN imho
>>> anyways).
>>>
>>> Rich
>>>
>>> On Mon, Apr 20, 2009 at 2:55 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
>>> wrote:
>>>>
>>>> On Apr 17, 2009, at 11:29 PM, Tatu Saloranta wrote:
>>>>
>>>>> On Fri, Apr 17, 2009 at 12:26 PM, Richard Wallace
>>>>> <rwallace1979_at_gmail.com> wrote:
>>>>>>
>>>>>> On Fri, Apr 17, 2009 at 9:07 AM, Tatu Saloranta <tsaloranta_at_gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, Apr 17, 2009 at 8:54 AM, Richard Wallace
>>>>>>> <rwallace1979_at_gmail.com> wrote:
>>>>>>> ...
>>>>>>>>
>>>>>>>> Anyways, even if the Jersey OSGi integration isn't perfect I
>>>>>>>> don't
>>>>>>>> think you should throw the baby out with the bath water with
>>>>>>>> the
>>>>>>>> jersey-bundle jar and remove all the manifest headers.
>>>>>>>
>>>>>>> I agree. For other projects I'm involved with, OSGi headers
>>>>>>> are added
>>>>>>> even if services-introspection isn't available: you can still
>>>>>>> instantiate implementation directly, or using injection-
>>>>>>> dependency
>>>>>>> framework.
>>>>>>>
>>>>>>>> I'm also curious if you guys ever tried something like is
>>>>>>>> mentioned
>>>>>>>> in
>>>>>>>> this blog
>>>>>>>> <http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html>.
>>>>>>>> I know it was brought up on the list before, but it doesn't
>>>>>>>> seem like
>>>>>>>> anything came of it. If you'd like I can try patching Jersey
>>>>>>>> and see
>>>>>>>
>>>>>>> For me the best suggestion (from comments there was) using a
>>>>>>> simple
>>>>>>> OSGi-services based solution. But that needs at least de facto
>>>>>>> standard between implementations of specific standard; and
>>>>>>> ideally a
>>>>>>> standard from within JSR in question.
>>>>>>> With Stax, for example, I did implement OSGi services based
>>>>>>> alternative included in Stax2 extensions (so far implemented by
>>>>>>> Woodstox and Aalto), and that was rather straight-forward. But
>>>>>>> the
>>>>>>> next step (settling on one approach, standardizing it) is the
>>>>>>> hard
>>>>>>> part.
>>>>>>>
>>>>>>
>>>>>> Well, I think it would be nice to at least get something going
>>>>>> for
>>>>>> Jersey. After that we can figure out how to get it
>>>>>> standardized and
>>>>>> get other implementations using it - let's just take it one
>>>>>> step at a
>>>>>> time. :)
>>>>>
>>>>> Fully agreed.
>>>>>
>>>>
>>>> Logged issue:
>>>>
>>>> https://jersey.dev.java.net/issues/show_bug.cgi?id=275
>>>>
>>>> so i do not forgot :-)
>>>>
>>>> Paul.
>>>>
>>>>>> As I said, I'm about to head out on vacation but I'll take a
>>>>>> look at
>>>>>> it in more detail when I get back. Which comment is it that
>>>>>> you're
>>>>>> talking about, the one from Christian Schneider? Can you provide
>>>>>
>>>>> Yes.
>>>>>
>>>>>> links to the work you did for Stax?
>>>>>
>>>>> It's trivially simple, Stax2 API is included withing woodstox
>>>>> repo, so
>>>>> javadocs at:
>>>>>
>>>>> http://woodstox.codehaus.org/4.0.3/javadoc/index.html
>>>>>
>>>>> and specifically package "org.codehaus.stax2.osgi",
>>>>>
>>>>>
>>>>> [http://woodstox.codehaus.org/4.0.3/javadoc/org/codehaus/stax2/osgi/package-frame.html
>>>>> ]
>>>>>
>>>>> are all there is. Plus trivial implementation of course.
>>>>>
>>>>> I suspect there may be better ways, and/or the whole concept
>>>>> could be
>>>>> further generalized, but seems simple enough.
>>>>>
>>>>> Getting Jersey to work bit better on 'generic' OSGi would be
>>>>> great.
>>>>>
>>>>> -+ Tatu +-
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>