Jerome Dochez wrote:
>
> On Aug 28, 2008, at 1:22 PM, Richard S. Hall wrote:
>
>> I was going to raise a similar comment as Sahoo...the embedded space
>> is one of the targets for OSGi...
> sorry I was unclear, I meant that embedded can optionally use or not use
> OSGi, I do agree that in most cases, folks will want to embed GF with
> OSGi runtime, I just don't want to make it a requirement.
Well, I doubt OSGi is currently a solution for the embedded market where
space/memory/technology are limited. On the contrary, I do think
applications/softwares that needs to embed a Web Container will not use
OSGi most of the time (why should they?).
So far OSGi bundle like Jetty-OSGi are not widely used (Tomcat don't
event have support), but Jetty/Tomcat are widely embedded in several
products. If we want to compete with them with V3/WebContainer, we must
have an alternative to OSGi (and forcing OSGi/Felix makes the bundle way
to big IMO).
At least from the Grizzly side/community, Grizzly has been integrated in
many software and I suspect one of the reason is because it is small and
easy to embed via a simple Java API. We do ship OSGi bundle, which are
used by far less than the pure Java approach.
I guess v3 should also offer more than one solution: OSGi and Kohsuke's
Embed interface (no OSGi under the hood).
>>
>>
>> However, I do agree that it is best to avoid dependencies on OSGi API
>> in the general case.
>>
> yes It makes our bundles a lot more reusable as well to have this
> duality of running on top of OSGi and on top of bare JDK.
+1 as well. We just need to take a look at the upcoming Spring
Application Server...they support OSGi without requiring the component
deployed into it to support OSGi (aka Tomcat). They have an emulation
layer as well :-)
A+
--Jeanfrancois
>
>> -> richard
>>
>> Sahoo wrote:
>>> Jerome,
>>>
>>> Jerome Dochez wrote:
>>>>
>>>> I have also seen places when people started using OSGi APIs
>>>> directly, I have said in previous communications, including the
>>>> engineering meeting that I do not want any OSGi API usage in the V3
>>>> codebase. The simple reason is that we want to have the flexibility
>>>> to run V3 without an OSGi runtime (embedded scenario)
>>> I beg to differ on this point. OSGi is very suitable for embeddable
>>> case. From the very beginning, I have been saying that it is asking
>>> for trouble to have an alternate runtime for GlassFish. It is too
>>> costly to have a glassfish with identical behavior on yet another
>>> platform in addition to OSGi.
>>>> and we can do that by providing a mock-up implementation of the hk2
>>>> interfaces which provides us with an isolation layer. So all OSGi
>>>> direct usage should be wrapped in an hk2 interface so we can ensure
>>>> that a mockup implementation can be done.
>>> web-glue uses OSGi API for good reasons,as it has to use OSGi's URL
>>> handler service. I hope you are not suggesting to even wrap that in HK2.
>>>> We already have external users/companies using V3 in such a
>>>> scenario, it's important we don't break them.
>>> Can you elaborate why those users object to us using OSGi as the
>>> runtime in embedded scenario? During ASARCH review process, I also
>>> raised this issue and I am yet to get a suitable answer. I have heard
>>> fast startup as a requirement. How fast do we want? Have we exhausted
>>> all our options while using OSGi that we have decided to use some
>>> other runtime to get the desired start up time?
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>