Comments inline. > > 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) #2 doesn't mean that the OSGi service registry has any special knowledge of the service - it just means that in addition to setting up the OSGi service registry, the subsystem (not the registry itself) also populates it with known services.

All your comments make most sense when you see Tx and JNDI as core services and OSGi providing an additional view on those services. From the user experience this is in fact the case now. Tx and JNDI start at boot time and their respective OSGi services are not available. Only when the OSGi subsystem starts the Tx and JNDI services also become available in the OSGi registry. I still maintain that the OSGi subsystem provides the core infrastructure and should not have an every changing set of dependencies on X, Y, Z. Instead X, Y, Z can create lazy services that depend on the the system BundleContext when it becomes available. The code should nevertheless live with X, Y, Z and perhaps if you really care it could live in X-OSGi, Y-OSGi, Z-OSGi, but not in the OSGi subsystem.

Sorry, I don't quite follow your config example. I'd say <subsystem xmlns="foo"/> enables plain service foo. If you also have <subsystem xmlns="osgi"/> then foo might show up in the OSGi registry if subsystem foo chooses to do so. The OSGi subsystem would not know about foo. -thomas On 11/30/2010 08:37 PM, David M. Lloyd wrote: > Comments inline. > > On 11/30/2010 09:42 AM, Thomas Diesler wrote: >> IMHO it boils down to what you choose as the promoted service >> integration layer. > Actually this has nothing to do with it at all. It's all about the user > experience from the configuration standpoint. > > If I have the OSGi subsystem enabled, and I have the Txn subsystem > enabled, it's completely reasonable to expect that OSGi transactions > would be available. However this is an aspect of the OSGi subsystem, > not the Txn subsystem. There is certainly no rule which says "one > subsystem equals one OSGi service" at all. A subsystem is a > configuration entity only. > >> 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." > There's nothing which says a subsystem cannot provide more than one > capability to the user - this is a completely artificial constraint that > you've put upon yourself. > >> 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) > #2 doesn't mean that the OSGi service registry has any special knowledge > of the service - it just means that in addition to setting up the OSGi > service registry, the subsystem (not the registry itself) also populates > it with known services. > >> 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. > #3 means that instead of saying: > > <subsystem xmlns="blah osgi"> > <!-- generic stuff here --> > </subsystem> > > and having txn and naming automatically turn on, you'd have to say: > > <subsystem xmlns="blah osgi"> > <!-- generic stuff here --> > </subsystem> > <subsystem xmlns="blah osgi txn"/> > <subsystem xmlns="blah osgi naming"/> > > In other words, no reasonable defaults, and the user has to add a whole > mess of subsystems for basic things to work. I think #2 is best in this > regard - it's easier to set up, easier to read and understand, and > easier to configure after the fact for the user, who would never think > that they'd have to configure additional subsystems in order to enable > services in OSGi that they've already turned on and have working in a > non-OSGi sense. > >> For simplicity reasons, I thought the abstraction in separate Service >> classes is "good enough" and we won't need an additional mvn module. > Yeah of course each thing could be its own service - there is absolutely > no requirement that a subsystem be constrained to a single service. > >> In reality, the folks that maintain MSC service Foo would also provide the OSGi Foo service. Hence, one mvn module. > Maybe in some cases. In other cases (core services for example) this is > not the case - OSGi is an additional aspect which the core service > maintainer may not want to have to worry about. > >> cheers >> -thomas >> >> >> >> >> On 11/29/2010 07:07 PM, Jason T. Greene wrote: >>> This was talked about briefly on the pull request list, but no >>> resolution was made. >>> >>> The issue is that JBAS-8585 and JBAS-8599 both add module dependencies >>> from some of the core subsystems on to the osgi subsystem (naming and >>> transactions). In addition we already have a module dependency from >>> domain to osgi. So for all intents and purposes, we are moving towards >>> AS7 having osgi as a required base level component. Before progressing >>> much further in this direction we should evaluate whether this is the >>> right thing to do, and how this solution compares to alternative >>> approaches. I can think of three approaches right off the bat. >>> >>> 1. Continue as is, osgi is a core required component >>> Pros: OSGi subsystem module is simpler, no additional subsystems or >>> modules needed >>> Cons: AS7 must always have OSGi binaries no matter the configuration >>> >>> 2. Change the osgi subsystem to use optional dependencies on all of the >>> subsystems it maps. >>> Pros: No additional subsystems are needed >>> AS7 no longer requires OSGi binaries >>> Cons: osgi subsystem code will need to do a lot of conditional >>> checking for handling different subsystems being available >>> >>> 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming, >>> osgi-transactions, etc) >>> Pros: OSGi subsystem code is simpler >>> AS7 no longer requires OSGi binaries >>> Cons: More subsystems are introduced, almost one per functional >>> subsystem. >>> >>> Let the debate begin :) >>>

Forwarding an response from Thomas that doesn't seem to have made it to the mailing list... David -------- Original Message -------- Subject: Re: [jboss-as7-dev] OSGi subsystem dependencies Date: Tue, 30 Nov 2010 09:42:56 +0100 From: Thomas Diesler&lt;thomas.diesler(a)jboss.com&gt; To: Jason T. Greene&lt;jason.greene(a)redhat.com&gt; CC: jboss-as7-dev@lists.jboss.org&lt;jboss-as7-dev(a)lists.jboss.org&gt; > 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. 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) 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. 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. cheers -thomas On 11/29/2010 07:07 PM, Jason T. Greene wrote: > This was talked about briefly on the pull request list, but no > resolution was made. > > The issue is that JBAS-8585 and JBAS-8599 both add module dependencies > from some of the core subsystems on to the osgi subsystem (naming and > transactions). In addition we already have a module dependency from > domain to osgi. So for all intents and purposes, we are moving towards > AS7 having osgi as a required base level component. Before progressing > much further in this direction we should evaluate whether this is the > right thing to do, and how this solution compares to alternative > approaches. I can think of three approaches right off the bat. > > 1. Continue as is, osgi is a core required component > Pros: OSGi subsystem module is simpler, no additional subsystems or > modules needed > Cons: AS7 must always have OSGi binaries no matter the configuration > > 2. Change the osgi subsystem to use optional dependencies on all of the > subsystems it maps. > Pros: No additional subsystems are needed > AS7 no longer requires OSGi binaries > Cons: osgi subsystem code will need to do a lot of conditional > checking for handling different subsystems being available > > 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming, > osgi-transactions, etc) > Pros: OSGi subsystem code is simpler > AS7 no longer requires OSGi binaries > Cons: More subsystems are introduced, almost one per functional > subsystem. > > Let the debate begin :) >