1 2 Previous Next 21 Replies Latest reply: Oct 1, 2008 5:56 AM by Adrian Brock RSS

OSGi integration

Ales Justin Master

Regarding recent discussion with Ivelin about OSGi support in Microcontainer, what are our exact plans?

As I see OSGi, there are two things to consider - implementation of framework (this what you started Scott, right) and basic services.

Our first impression is that we'll be able to do this simply with the current deployers (vfs), metadata, dependency (kernel) and spring-int like xml binding.

I'm about to go through the current v.4 specification, is there something I should consider more important?

  • 1. Re: OSGi integration
    Scott Stark Master

    Being able to support osgi deployments is the only real plan. What I started was an osgi bundle implementation on top of the vfs as a replacement for the unified class loader.

  • 2. Re: OSGi integration
    Ales Justin Master

     

    "scott.stark@jboss.org" wrote:
    Being able to support osgi deployments is the only real plan.


    This meaning what - or how does this fit into framework vs. services picture?
    Or is this similiar to what Spring is doing with their OSGi support?

    Since I just had a discussion with Apache Felix (full OSGi implementation) lead and an OSGi EG lead about our integration.
    They are willing to help, but we need to know exactly what we want to do.

    Are we going to a full implementation (which is a lot of work for spec r4), or we can base our impl on top of Felix with appropriate hooks (where possible - but we could be able to contribute some code to Felix for this) or just a simple 'Spring like' implementation (depending on other full impls - Felix, Equinox, Knopflerfish, ...).

    How much work does our new Deployers architecture take away?





  • 3. Re: OSGi integration
    Scott Stark Master

    To be able to deploy osgi services as mc components. I'm not interested in implementing osgi r4.

  • 4. Re: OSGi integration
    Ales Justin Master

     

    "scott.stark@jboss.org" wrote:
    To be able to deploy osgi services as mc components. I'm not interested in implementing osgi r4.


    Basically the same thing what Spring has done, right?
    Probabaly this can be done quickly - with deployers (vfs) + MC architecture.

    How do you then integrate OSGi framework into this?
    Integrated standalone MC + framework?

    btw: How much of a discussion was there between you, Adrian, Sacha and Ivelin about where we want to go with OSGi?



  • 5. Re: OSGi integration
    Scott Stark Master

     

    "alesj" wrote:

    Basically the same thing what Spring has done, right?
    Probabaly this can be done quickly - with deployers (vfs) + MC architecture.

    As far as I can see.

    "alesj" wrote:

    How do you then integrate OSGi framework into this?
    Integrated standalone MC + framework?

    Should not be much different than how service mbeans are done.

    "alesj" wrote:

    btw: How much of a discussion was there between you, Adrian, Sacha and Ivelin about where we want to go with OSGi?

    Only what is on the lists and a conf call with Peter Kriens of osgi. It should be driven by users and whatever esb integration usecases come about. Mark Little still has to look into how it fits into the esb.



  • 6. Re: OSGi integration
    Ales Justin Master

    I would like to pull the OSGi module out of the Microcontainer project into separate project (as Scott did with VFS) under 'https://svn.jboss.org/repos/jbossas/projects/osgi'. Why?

    I went over the r4 spec and Spring's OSGi integration - and this is probably really the same thing we want to have. What's really important is that Spring's OSGi spec (http://www.springframework.org/osgi/specification) was influenced a lot by the same people (core OSGi EG members) that we are also involved with - so doing something totally different doesn't make sense.
    Ok, the two impls would look a lot the same (if somebody has a problem with this, let me know), but I don't think we are here to reinvent the wheel. We are basically trying to put a good spec onto MC's behaviour.
    And with this similar OSGi approach and our (almost) ready Spring XML schema support, I think we would offer users / developers a good option of choosing what they want to use - full app. server or simple IoC container.

    Our OSGi project would be (similar to Spring's) divided into different modules. These are the one's that I currently have in mind:
    - core (integration with MC)
    - starter [extender] (Activator bundle)
    - test
    - examples [samples]
    - services (optional impl of OSGi services on top of our architecture - log, security, ...)

  • 7. Re: OSGi integration
    Scott Stark Master

    Its not clear that this is the right thing to do as mapping osgi onto spring on top of the mc is not what we want. What we want is a mapping of the osgi concepts onto the mc metdata/wiring of the beans with help from supporting osgi interface implementations.

    The starting point should be usecases decribing what we mean by support for osgi.

  • 8. Re: OSGi integration
    Ales Justin Master

     

    "scott.stark@jboss.org" wrote:
    Its not clear that this is the right thing to do as mapping osgi onto spring on top of the mc is not what we want. What we want is a mapping of the osgi concepts onto the mc metdata/wiring of the beans with help from supporting osgi interface implementations.

    I wouldn't go over Spring to map it to MC.
    I ment that we can go in the same impl direction - core + starter (extender) bundle. But definitely with our metadata/wiring.

    "scott.stark@jboss.org" wrote:

    The starting point should be usecases decribing what we mean by support for osgi.

    I would support similar things as the Spring spec (+ joined work of OSGi EG members) supports - as I went over that, I saw no problems that we might have with implementing this on top of MC.
    That is a simple introduction of additional OSGi based XML (annotation) definition - OSGi service, reference, ... - but wired with existing MC beans.

  • 9. Re: OSGi integration
    Ales Justin Master

    I did start with some initial deployment code, but I saw that doing the deployment differently from our deployers is not the way to go - since we already have a mechanism that finds appropriate deployer and deploys metadata.
    I will look how we can hook into existing OSGi framework deployment and write our deployer on top of that - probably replacing their 'scanner' mechanism.

  • 10. Re: OSGi integration
    Bill Burke Master

    I think I'm confused here. What is the plan?

    To allow OSGi bundles to be able to be deployed into JBoss Kernel? This means we will have to refactor our UCL layer to support their classloader notions.

    The other idea is to be able to deploy MC beans into an OSGi implementation. This seems like what you are currently doing Ales?

  • 11. Re: OSGi integration
    Ales Justin Master

     

    "bill.burke@jboss.com" wrote:
    The other idea is to be able to deploy MC beans into an OSGi implementation. This seems like what you are currently doing Ales?


    Yes.
    I take the bundle artifact and register it into the existing OSGi framework, set bundle as top level CL and then wire up beans (OSGi lookup or registry).
    The wiring is yet to be fully done, since I would like to have MC scoping before (just working on it).


  • 12. Re: OSGi integration
    Ales Justin Master

     

    "scott.stark@jboss.org" wrote:
    Being able to support osgi deployments is the only real plan. What I started was an osgi bundle implementation on top of the vfs as a replacement for the unified class loader.

    "bill.burke@jboss.com" wrote:
    This means we will have to refactor our UCL layer to support their classloader notions.

    "scott.stark@jboss.org" wrote:
    The class versioning in osgi comes from the bundle
    class loader, and its really a package level versioning. We will have an
    osgi compatible class loader in the mc/jboss5."


    Ok, so there was not a clear understanding. But it doesn't hurt to have both options (current impl with delegation to existing OSGi framework and new UCL layer) ;-).

    So basically we want to have a whole new CL layer with versioning on packages available, e.g.:
    Export-Package: org.osgi.util.tracker;version=1.3
    Import-Package: com.acme.foo;version="[1.23, 2)"
    


    And this is what was already started by Scott.
    Why the need of using OSGi interfaces - Bundle, Activator, ... ?

    How do we start this UCL refactoring?

    Once we have this, I think service lookup / registry via Class instance (or ClassName + version) is trivial, since MC at state machine level ([Abstract]Controller) is (String) name unaware - name is plain Object (eq. via hash).

  • 13. Re: OSGi integration
    Scott Stark Master

    There is no need for the osgi interfaces in the barely started ucl refactoring. I only included those to get a feel for how different the ucl was from the osgi bundle notion. I would have extracted those interfaces once its clear what was needed. That is how I would continue the ucl refactoring.

    Alternatively you could already start with two versions: the BundleClassLoader impl in the osgi integration layer that delegates to new ULR/UCL, and the new ULR/UCL that supports the BundleClassLoader along with whatever else we need.

  • 14. Re: OSGi integration
    Ales Justin Master

    Ok, I'll first try to finish my current idea / impl, with delegation to existing OSGi framework.
    And then I'll try to carry on your work with refactoring of CL layer with package versioning.
    I think I'll bug you a lot then, with your huge CL experience. :-)

1 2 Previous Next