1 2 3 Previous Next 37 Replies Latest reply: Nov 23, 2009 8:46 AM by Adrian Brock RSS

Service integration with MC

Ales Justin Master

and vice versa.

* Service --> MC

"adrian@jboss.org" wrote:

The service layer is not so well integrated with the MC. It does just enough to
be "OSGi compliant" (of course that's not yet tested). So this is at the
moment very simple.
The OSGiServiceState which should eventually turn into an MC context implementation
has two "facades", the standard ServiceRegistration and ServiceReference interfaces.


* MC --> Service
"adrian@jboss.org" wrote:

Services are also largely complete. What's missing is that we want to expose
MC pojos and JMX MBeans etc. as OSGi services.

The proper way to do this would be to push the OSGi Filter into kernel project
and use the MDR INSTANCE scope as the attributes.
There would be a gotcha in that OSGi expect attributes to have case insensitive names,
but we would only have to enforce that for OSGi created services.


Unless you already started on this, I would like to have a crack at it once I return from JBW.

  • 1. Re: Service integration with MC
    Ales Justin Master

     

    "adrian@jboss.org" wrote:

    The big problem with doing this now is that it would make it difficult to drop the OSGi
    layer into existing jboss releases since we can't change their MC implementations to do this.

    There's probably some compromise we can reach between the two extremes
    and leave the proper solution to a future major release of JBoss.

    I don't understand what the big problem you see is?


  • 2. Re: Service integration with MC
    Ales Justin Master

     

    "alesj" wrote:
    "adrian@jboss.org" wrote:

    The big problem with doing this now is that it would make it difficult to drop the OSGi
    layer into existing jboss releases since we can't change their MC implementations to do this.

    There's probably some compromise we can reach between the two extremes
    and leave the proper solution to a future major release of JBoss.

    I don't understand what the big problem you see is?

    Ah, scratch this. :-)

    Re-reading it once again, and actually using tiny part of the brain that is not asleep yet, helped.

    I wouldn't bother with previous releases. Or should we?
    As we're already using CL and Deployers snapshots,
    I guess we could fix Dependency and Kernel as well, still on the 2.0.x branch, to fit our needs.
    In the worst case making new 2.1.x branch, same as we did for VFS and Man,
    which could still be part of JBoss 5.x (aka "existing" jboss releases), leaving bigger MC 2.2.x refactorings for 6.x.

  • 4. Re: Service integration with MC
    Ales Justin Master

    I'm actually wondering what's the best or proper way to expose or use this services in MC.
    What should be the keys that we expose or match.

    "alesj" wrote:

    * Service --> MC

    In OSGi service we expose classes and properties.

    Probably the key could look something like this:
    * org.jboss.acme.X,org.jboss.acme.Y;(a=b)
    a set of FQNs and a filter.
    Only matching services that expose all the FQNs and match the filter.

    Perhaps if there are no properties, we could directly expose service under registered classes?

    "alesj" wrote:

    * MC --> Service

    This looks easier from matching pov - simply do an intersection on the contexts that type match given FQNs (classes).

    But how to mock (or even get) beans bundle?

    Where this mock could be done, what about its "using bundles"?
    Only count this in previous mock bundle, but ignore plain MC bean injection / usage?

    "adrian@jboss.org" wrote:

    The proper way to do this would be to push the OSGi Filter into kernel project
    and use the MDR INSTANCE scope as the attributes.
    There would be a gotcha in that OSGi expect attributes to have case insensitive names,
    but we would only have to enforce that for OSGi created services.

    Or what exactly did you have in mind here?


  • 5. Re: Service integration with MC
    Ales Justin Master

     

    "alesj" wrote:

    * Service --> MC

    What to do about tracking this "OSGi --> MC" injection?

    If we add this service to bundle's inUse, then there is no proper callback to decrease inUse count.
    Which in the case of ServiceFactory (SF) means SF::ungetService might never be called.

    We can completely ignore bundle service count + serviceCache,
    but potentially some service unregister could invoke SF::ungetService,
    although we would still be using it in MC bean.



  • 6. Re: Service integration with MC
    Adrian Brock Master

     

    "alesj" wrote:
    I'm actually wondering what's the best or proper way to expose or use this services in MC.
    What should be the keys that we expose or match.

    "alesj" wrote:

    * Service --> MC

    In OSGi service we expose classes and properties.

    Probably the key could look something like this:
    * org.jboss.acme.X,org.jboss.acme.Y;(a=b)
    a set of FQNs and a filter.
    Only matching services that expose all the FQNs and match the filter.

    Perhaps if there are no properties, we could directly expose service under registered classes?


    What do you mean by key?
    The name of the OSGi service context should be something generated that won't change
    or interfere with other names
    e.g. a UID or $OSGiService + serviceID

    Ideally you need an index (rather than a key) by class name to optimize the search
    but we don't currently do that in the OSGi prototype.
    You should already have something similar for the anonymous injection
    and the install callbacks which should be more efficient than what is currently used?

    The only thing that is probably missing is the security check?

  • 7. Re: Service integration with MC
    Adrian Brock Master

     

    "alesj" wrote:
    "alesj" wrote:

    * Service --> MC

    What to do about tracking this "OSGi --> MC" injection?

    If we add this service to bundle's inUse, then there is no proper callback to decrease inUse count.
    Which in the case of ServiceFactory (SF) means SF::ungetService might never be called.

    We can completely ignore bundle service count + serviceCache,
    but potentially some service unregister could invoke SF::ungetService,
    although we would still be using it in MC bean.


    The service tracking needs moving into the MC as part of this integration.
    The issue is what you track against.

    As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's
    deployment level metadata. You should extend this concept so that the
    dependency project can look for a "ServiceTracker" in the MDR rather than
    a DeploymentUnit. The deployers project would then add the ServiceTracker
    attachment by the default to the deployment level metadata.

    If there is no such data (e.g. for MC contexts created by the bootstrap)
    then you should track against the "SystemBundle", i.e. a shared default deployment.

    The OSGi stuff would then just delegate to those items for service tracking
    instead of having to do it itself in the AbstractBundleState.

  • 8. Re: Service integration with MC
    Ales Justin Master

     

    "adrian@jboss.org" wrote:

    What do you mean by key?

    Both "keys".
    What to register against and how to do lookup.

    Register against:
    Exposing classes when there are also properties doesn't seem right.

    Lookup against:
    Same as "register against", doing lookup just on registered classes when there are existing properties, shouldn't match.

    Or should we treat this just as a MatchAllFilter lookup and type/class matching is actually enough / the right way?

    "adrian@jboss.org" wrote:

    The name of the OSGi service context should be something generated that won't change
    or interfere with other names
    e.g. a UID or $OSGiService + serviceID

    That's already done - it's GUID.

    "adrian@jboss.org" wrote:

    Ideally you need an index (rather than a key) by class name to optimize the search
    but we don't currently do that in the OSGi prototype.
    You should already have something similar for the anonymous injection
    and the install callbacks which should be more efficient than what is currently used?

    We have such mechanism already in KernelController, but it requires KernelControllerContext.
    I'll see if (or how) I can make that less restrictive.

    "adrian@jboss.org" wrote:

    The only thing that is probably missing is the security check?

    The whole MC is missing this. ;-)


  • 9. Re: Service integration with MC
    Ales Justin Master

     

    "adrian@jboss.org" wrote:

    The service tracking needs moving into the MC as part of this integration.
    The issue is what you track against.

    Actually I had more fine grained tracking in mind.
    Like I tried to explain, and I probably failed, I was thinking about OSGi service unget callbacks.

    In MC we simply nullify injections at un-configure.
    But in case the injected service is an OSGi service, we should also somehow invoke the unget.

    We need something like ValueMetaData:release,
    which in InjectionMetaData impl it would call ControllerContext::releaseTarget.
    Or something like that ...

    "adrian@jboss.org" wrote:

    As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's
    deployment level metadata. You should extend this concept so that the
    dependency project can look for a "ServiceTracker" in the MDR rather than
    a DeploymentUnit. The deployers project would then add the ServiceTracker
    attachment by the default to the deployment level metadata.

    If there is no such data (e.g. for MC contexts created by the bootstrap)
    then you should track against the "SystemBundle", i.e. a shared default deployment.

    The OSGi stuff would then just delegate to those items for service tracking
    instead of having to do it itself in the AbstractBundleState.

    What's the use of this vs. KernelController's contextual tracking?
    Since this would already be part of dependency whereas that is part of kernel?

    If we use this, what would we gain by putting this in deployment level
    instead of server level - which should be available for bootstrap beans as well?


  • 10. Re: Service integration with MC
    Adrian Brock Master

    I think we're talking at cross purposes. Let's start again from scratch with the requirements.

    What is required is to be able to do "service tracking".

    So we add a "ServiceTracker" to the MDR which for deployments will be in the deployment level (really the application/top level deployment)
    for others it will be as you say a default one at the Server level, what osgi calls the "SystemBundle".
    You can imagine others might choose to track at some other level. e.g.
    for JavaEE we might choose to track at sub-deployment level, what MDR
    confusingly calls the deployment level. :-)

    When you do any type of injection (or the api is invoked from somewhere else)
    this should invoke the equivalent of get/unget of the ServiceTracker for that context.

    In MC terms that is getTarget() for get. But we don't currently invoke an ungetTarget()
    at "uninjection" so that needs doing.

    Of course the OSGiServiceStates become ControllerContexts and
    delegate to the same api.

    Once that is done, the queries can go through the ServiceTracker at the relevant level.
    The deployment level for normal OSGiBundleState and the server level for the
    SystemBundle.

    You still need a "global" list of services for the getXXXServiceXXX() queries.
    That should primarily be based on an index by class (it doesn't have to be
    its a performance optimization and only available when you have been asked
    to query by class). But once you've subsetted by class then you do a
    "read and skip" over those contexts to locate the ones that match any passed filter on
    the properties (instance level MDR).

    We might choose to expand the queries to include things other than class and
    filter for out private api, but this won't be available using the OSGi api.

    Don't think of this as just for OSGi. It is something that is available for
    other deployments as well. It's just motivated by OSGi since it comes from their api.

  • 11. Re: Service integration with MC
    Ales Justin Master

     

    "adrian@jboss.org" wrote:

    When you do any type of injection (or the api is invoked from somewhere else)
    this should invoke the equivalent of get/unget of the ServiceTracker for that context.

    What kind of logic would you hide in this get/unget ServiceTracker invocations?
    Or what would be the benefit of ServiceTracker actually getting the context as a parameter, and not just (for example) type parameter?


  • 12. Re: Service integration with MC
    Thomas Diesler Master

    Hi Ales,

    when working on this, please also keep in mind that the standard wiring and injection mechanism in OSGi is Blueprint. If there is some sort of integration between MC and BP beans and services it should show up in the BP descriptor.

    The BP descriptor has a namespace extension mechanism build into it which could be used to declare or reference MC beans. If you also think of bringing the notion of OSGi service to the MC descriptor then that would be of secondary importance.

    Anyhow, could you please describe how the MC/OSGiService integration would work from the user perspective.

    Not sure if you are aware of this, but we already have some sort of MC/OSGiService integration which is detailed in the MicrocontainerService

    http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedBundles.html#SecBundleMicrocontainer

    and tested by

    http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedExamples.html#SecMicrocontainerServiceExample

    Could you please add a comment to https://jira.jboss.org/jira/browse/JBOSGI-141 that details what added benefits your current integration work will bring to the user?

    Thanks a bunch

  • 13. Re: Service integration with MC
    Ales Justin Master

     

    "thomas.diesler@jboss.com" wrote:

    Anyhow, could you please describe how the MC/OSGiService integration would work from the user perspective.

    This would be transparent to user, either one, MC or OSGi.
    * OSGi services will be exposed as MC beans
    * MC beans will be listed as a OSGi services

    "thomas.diesler@jboss.com" wrote:

    Not sure if you are aware of this, but we already have some sort of MC/OSGiService integration which is detailed in the MicrocontainerService

    This doesn't look very transparent. :-)
    I guess it's the MCService that checks for proper bean (type) access?

    You could probably use OSGi's ServiceFactory here,
    where the actual underlying bean name would be part of service's properties.

    "thomas.diesler@jboss.com" wrote:

    Could you please add a comment to https://jira.jboss.org/jira/browse/JBOSGI-141 that details what added benefits your current integration work will bring to the user?

    * http://java.dzone.com/articles/a-look-inside-jboss-microconta

  • 14. Re: Service integration with MC
    Ales Justin Master

     

    "adrian@jboss.org" wrote:

    In MC terms that is getTarget() for get. But we don't currently invoke an ungetTarget() at "uninjection" so that needs doing.

    This is tricker than it looks like, as we don't have just plain configuration injection.

    Ctor and properties injection have natural undeploy / uninjection.
    I could also somehow squeeze in create, start and installs.

    But what to do with stop, destroy and uninstalls?
    try {
     uninstallMethod.invoke(target, VMD::get)
    } finally {
     VDM::unget
    }
    

    whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory,
    as ServiceFactory::unget could modify the actual created service.
    Leave it to the expense of the user? :-)

    Should we also do unget on the callbacks, or a callback doesn't really have proper usage
    if it's not "backed-up" by uncallback (which will actually take care of unget)?


1 2 3 Previous Next