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".

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/c68e62ec2662ecb6253c03eabc98ef7... > > ---- > > 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.