users@jersey.java.net

Re: [Jersey] Jersey & OSGi <was> Re: [Jersey] Jersey 1.0.3 released

From: Richard Wallace <rwallace1979_at_gmail.com>
Date: Wed, 29 Apr 2009 13:31:12 -0700

On Wed, Apr 29, 2009 at 1:10 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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 ) ?
>

There is a servlet container, but it's not used by deploying war
files. Instead, bundles register Servlets with the HttpService
<http://www.osgi.org/javadoc/r4v41/org/osgi/service/http/HttpService.html>.
The servlet container behind the HttpService then handles initializing
the Servlet after it's been registered.

>
>> 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).
>

Yup, that is done. The problem is, if you look at that HttpService
interface, there is no way to register context listeners like you were
talking about. Meaning that we couldn't use them to do the
initialization of the ResourceConfig, etc.

> Perhaps it would be best if the servlet factory returned instance of
> Servlet?
>

That's fine, ServletContainer is already an instance of Servlet, isn't it?

Rich

> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>