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
>