Salut,
Richard Wallace wrote:
> 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.
Shameless plug but I do think the explanation is quite clear:
http://codemeself.blogspot.com/2009/03/grizzly-osgi-http-service-guide.html
In short, Grizzly support the HttpService spec. That could probably
helps testing...
A+
--Jeanfrancois
>
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>