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
>