Ok, nevermind that last email. I just reread some of what Tatu wrote
and some other blog posts on the subject and the way the ServiceMix
folks handle it is much better. Take a look at their specs subproject
<
https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/>. You
can see they take and repackage the spec APIs, bundling with it their
locator code <
https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator/src/main/java/org/apache/servicemix/specs/locator/>
which includes an Activator and a generic OsgiLocator. Then, in the
modified specs they use the OsgiLocator to find the right service
provider. This is much better than what I was doing because it
doesn't require all the classloader scanning everytime. It is done
once on startup and each bundle then gets scanned as it's loaded.
This is the best way to handle the OSGi META-INF/services issue that
I've seen so far, except for the suggestion Peter Kriens has of
implementation bundles registering services for the api bundles to
use. But as Tatu mentioned, that requires more work to get
standardized.
Btw, the ServiceMix guys even have a modified jsr311-api
<
https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.0/>
with a FactoryFinder.java implementation that does this already!
Might be worth adopting, or at least referring people that want
OSGi-ified Jersey stuff to there. Though we'll still need to put the
OSGi headers back on the jersey-bundle artifact.
Rich
On Fri, Jun 12, 2009 at 12:22 PM, Richard Wallace<rwallace1979_at_gmail.com> wrote:
> Hey Paul,
>
> I know you said you wanted to work on this after JavaOne. Have you
> had a chance to get started on it yet? I created a few projects on
> GitHub that could be useful. They're forks of the dynamicjava.org
> jaxb-api and stax-api because I found some limitations/bugs in them.
> But I also pulled out the classloaders that are used internally into a
> separate project for better reuse. The projects are all under my
> account on GitHub <http://github.com/rwallace> and called,
> jaxb-api-bundle, stax-api-bundle and the classloaders are in
> osgi-bundle-classloaders. I've tested them quite a bit and they seem
> to work well. Let me know if you have any questions.
>
> Rich
>
> On Thu, Apr 30, 2009 at 3:28 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
>>
>> On Apr 30, 2009, at 2:43 AM, Jeanfrancois Arcand wrote:
>>
>>> 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...
>>>
>>
>> Indeed! that will be most useful, i may be asking you some questions in the
>> near future!
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>