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