Harsha Godugu wrote:
> Could somebody help me understand a use-case scenario(s) where OSGi
> can be used effectively in embedded GlassFish.
> What would be the benefits to the end user (say a customer running a
> big show on the front/web)
>
> thanks..
I think the big win is not having to maintain two different code bases
for the two different environments.
-> richard
>
> Richard S. Hall wrote:
>> I was going to raise a similar comment as Sahoo...the embedded space
>> is one of the targets for OSGi...
>>
>> However, I do agree that it is best to avoid dependencies on OSGi API
>> in the general case.
>>
>> -> 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
>