[jboss-as7-dev] OSGi subsystem dependencies

[Thomas Diesler]

>  We could also do a hybrid approach that was suggested before, like
>  having a few bundle groups for commonly combined services (e.g. EE web
>  profile stuff, which by spec is already intermingled), but essentially
>  keeping the osgi module "pure".

Yes, this could be done. In fact that was our approach in AS6.
The jbosgi umbrella provided a set of bundles through the installer that made Tx and JNDI available in the OSGi registry


On 11/30/2010 09:20 PM, Jason T. Greene wrote:
> On 11/30/10 2:42 AM, Thomas Diesler wrote:
>> > In addition we already have a module dependency from
>> > domain to osgi.
>>
>> This is a bug.
>> Fixed in
>> https://github.com/jbosgi/jboss-as/commit/c68e62ec2662ecb6253c03eabc98ef753467701c
>>
>> ----
>>
>> IMHO it boils down to what you choose as the promoted service
>> integration layer. As it is with most AS7 subsystems today they
>> integrate via jboss-msc services. For system integration this is a
>> direct and efficient approach. For user deployments however, the uptake
>> of this is questionable. More likely we want to promote the integration
>> via standard OSGi services. I take the benefit of using an open standard
>> is generally accepted so I won't go into that much more.
>
> If you mean extending the AS, as in what we ourselves do, or what an ISV
> would do, I would expect they would be using our API/SPIs, that way they
> get the maximum capabilities. Those developing against an OSGi runtime,
> will of course prefer keeping it that way and relying on our OSGi
> support. EE deployments though should have options. They can either use
> our technologies, or they can intermix OSGi. Ultimately it's a question
> of using the best tool for the job at hand. Although, in most cases I
> suspect EE standard technologies (like CDI, or EJB singletons) will win
> out over using MSC *OR* OSGi. Class-loading is a different story though,
> and it's something that's traditionally always been a vendor defined 
> thing.
>
> Although that while supporting OSGi is a good thing, we shouldn't overly
> constrain ourselves to it. Especially considering that Java 8 will be
> directly competing with it.
>
>>
>> With respect to the (standard OSGi) Tx and JNDI services I said
>>
>> "The OSGi subsystem provides the OSGi service registry. Subsystem
>> Foo may choose to publish a service in that registry which would
>> then readily be available for installed bundles to use. The OSGi
>> subsystem does not need to know about Foo."
>>
>> http://community.jboss.org/thread/158822
>>
>> So if the OSGi service registry is the standard view of the MSC service
>> registry, It should readily be available whenever you want to publish a
>> service in a standard way.
> >
>>
>> From my perspective #2 would be a bad choice for the same reason that
>> you want to keep the MSC service registry generic (i.e. it does not know
>> about any specific service)
>
> I can see your point here. By the same argument it would prevent a
> trimmed AS using just osgi, something that would likely be valuable to 
> some.
>
>>
>> The current implementation uses #1 because I believe the OSGi service
>> registry should indeed be available to all subsystems that wish to
>> publish services that can be used by user deployments. As an alternative
>> I'd think #3 is reasonable. Every subsystem provides an OSGi bundle that
>> makes the respective subsystem services available in the OSGi service
>> registry.
>
> We could also do a hybrid approach that was suggested before, like
> having a few bundle groups for commonly combined services (e.g. EE web
> profile stuff, which by spec is already intermingled), but essentially
> keeping the osgi module "pure".
>
>> For simplicity reasons, I thought the abstraction in separate Service
>> classes is "good enough" and we won't need an additional mvn module. In
>> reality, the folks that maintain MSC service Foo would also provide the
>> OSGi Foo service. Hence, one mvn module.
>
> Sure, that certainly was the simplest to develop.
>


-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx