users@jersey.java.net

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

From: Richard Wallace <rwallace1979_at_gmail.com>
Date: Tue, 28 Apr 2009 09:33:37 -0700

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

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.

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