OSGi component model support

Details

  • User impact:
    High
  • Similar Issues:
    None

Issue Links

blocks

New Feature - A new feature of the product, which has yet to be developed. MULE-400 Hot deployment of components and other artifacts

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Task - A task that needs to be done. MULE-479 Integrate Mule-JBI classloading model into Mule

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. MULE-894 Define feature set for 2.0, 2.x

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MULE-971 Split up packages to clarify public/private parts

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Holger Hoffstaette added a comment -

See also: http://jcp.org/en/jsr/detail?id=291

Show
Holger Hoffstaette added a comment - See also: http://jcp.org/en/jsr/detail?id=291
Hide
Permalink
Andrew Perepelytsya added a comment -

So, I think we are not looking at embracing all layers of OSGi spec at the moment, aren't we? Module layer fits very nicely with whatever we already have.

I have a big whitespace in my mind, though, at the moment. It's the OSGi core framework. Granted, there are a number of already available (open source) framework implementations, it doesn't make sense to roll out our own. So, something embeddable, and preferrably OSGi 4.x compliant would do the trick, like http://cwiki.apache.org/FELIX/index.html , though it has to be evaluated with proper diligence, of course.

With Spring having an OSGi module coming out, it gets even more confusing

Show
Andrew Perepelytsya added a comment - So, I think we are not looking at embracing all layers of OSGi spec at the moment, aren't we? Module layer fits very nicely with whatever we already have. I have a big whitespace in my mind, though, at the moment. It's the OSGi core framework. Granted, there are a number of already available (open source) framework implementations, it doesn't make sense to roll out our own. So, something embeddable, and preferrably OSGi 4.x compliant would do the trick, like http://cwiki.apache.org/FELIX/index.html , though it has to be evaluated with proper diligence, of course. With Spring having an OSGi module coming out, it gets even more confusing
Hide
Permalink
Holger Hoffstaette added a comment -

The different core platform implementations should be more or less compatible with each other, so Felix/Knoplerfish/Equinox should not make that big a difference. Maybe for bringing up core architecture Equinox is best since it is actively developed and probably the most compliant. They also provide interesting extensions, this one caugt my eye: http://www.eclipse.org/equinox/incubator/monitoring/
A good question is of course the license of the core platform. I don't know if eclipse license (EPL) is compatible for us, AFAIK it is more or less Apache.

Show
Holger Hoffstaette added a comment - The different core platform implementations should be more or less compatible with each other, so Felix/Knoplerfish/Equinox should not make that big a difference. Maybe for bringing up core architecture Equinox is best since it is actively developed and probably the most compliant. They also provide interesting extensions, this one caugt my eye: http://www.eclipse.org/equinox/incubator/monitoring/ A good question is of course the license of the core platform. I don't know if eclipse license (EPL) is compatible for us, AFAIK it is more or less Apache.
Hide
Permalink
Holger Hoffstaette added a comment -

Andrew, sorry for my previous comment - it did not really address your first point. Obviously at least module layer is required but real benefits only come from including lifecycle layer i.e. start/stop/hotdeploy functionality. As far as I can tell this is the #1 thing that many people are missing in Mule: 24/7 uninterrupted operation, being able to update a config without taking down the entire app.
Service layer could help ourselves with consistent development and Security layer would be cool but can be taken as second or third step.

Show
Holger Hoffstaette added a comment - Andrew, sorry for my previous comment - it did not really address your first point. Obviously at least module layer is required but real benefits only come from including lifecycle layer i.e. start/stop/hotdeploy functionality. As far as I can tell this is the #1 thing that many people are missing in Mule: 24/7 uninterrupted operation, being able to update a config without taking down the entire app. Service layer could help ourselves with consistent development and Security layer would be cool but can be taken as second or third step.
Hide
Permalink
Andrew Perepelytsya added a comment -

AFAIK, Equinox is based on OSGi 3.x, not 4. Just for the record.

Show
Andrew Perepelytsya added a comment - AFAIK, Equinox is based on OSGi 3.x, not 4. Just for the record.
Hide
Permalink
Holger Hoffstaette added a comment -

First sentence on the home page: "From a code point of view, Equinox is an implementation of the OSGi R4 core framework specification"

Show
Holger Hoffstaette added a comment - First sentence on the home page: "From a code point of view, Equinox is an implementation of the OSGi R4 core framework specification"
Hide
Permalink
Holger Hoffstaette added a comment -

Spring & OSGi mailing list: http://groups.google.com/group/spring-osgi/

Show
Holger Hoffstaette added a comment - Spring & OSGi mailing list: http://groups.google.com/group/spring-osgi/
Hide
Permalink
Travis Carlson added a comment -

OSGi Presentation from MuleCon 2007:
http://mule.mulesource.org/download/attachments/4585/Mule+and+OSGi+-+Travis+Carlson.pdf

Show
Travis Carlson added a comment - OSGi Presentation from MuleCon 2007: http://mule.mulesource.org/download/attachments/4585/Mule+and+OSGi+-+Travis+Carlson.pdf

People

Vote (7)
Watch (8)

Dates

  • Created:
    Updated:
    Resolved: