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