karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: OSGi Service Platform Release 4.0 - Early Draft
Date Thu, 13 Oct 2011 02:34:09 GMT

On Oct 12, 2011, at 6:50 PM, mikevan wrote:

> Today I took a long, hard look at 
> http://www.osgi.org/download/osgi-early-draft-2011-09.pdf OSGi Service
> Platform Release 4.0 - Early Draft . That document is going to require some
> fairly major changes to both karaf and felix.  I'd like to discuss those
> changes in this thread. My impressions could be wrong, so feel free to
> correct me. The changes I see we'll need to do is:
> - Subsystem: Reworking how we do provisioning.  We use features.xml files,
> the Subsystem section mandates the use of configuration files similar to a
> .jar file's MANIFEST.MF file. Another item to consider is where provisioning
> should take place. Should it be Karaf, or would it be more appropriate to
> have Felix perform provisioning?

I think conceptually the main difference is that the subsystem spec thinks of a subsystem
(such as a feature) as a single artifact whereas karaf only deals with feature repositories
containing 0...n features descriptors.  I think the spec idea is a lot better and would trivially
solve a lot of the extremely complex systems people are proposing to deal with picking the
features you want out of a feature repo you deploy.  Aries is the reference implementation
for subsystems and it's going to have a lot of the basic functionality, I expect including
a maven subsystem plugin.

Also I think subsystems can be cataloged using obr, although I haven't tried this out.

> - OBR: Feilx will need to change how it manages its bundles to comply with
> this.  Cave will likely need major changes as Felix will be managing the OBR
> directly.  Karaf and Felix will need to decide whether or not to continue
> the user of mvn: and file: URL's to get bundles.
> - JMX enhancements: This is most likely to be done in Felix. I don't see
> anything here that would need to be done with Karaf other than resolving any
> dependancies required by Felix changes.
> - Declarative Service Annotations: This also appears to be mostly
> Felix-related.  Unless Karaf has declarative services in it (maybe we do,
> dunno the answer here), then we're good. If we do, we'll probably need to
> include the new declaratives services annotations.  I dont' see anything in
> the document that discusses backwards-compatibility.

There are no DS in karaf, IMO unfortunately.

> - Bundle Collision Hook: To my knowledge, Karaf doesn't care if there are
> multiple instances of the same version of the same bundle deployed into a
> single instance of karaf.  As long as wiring can occur, Karaf is cool.

My experience is that 4.2 frameworks (felix and equinox) wont let you install two bundles
with the same symbolic name and version.  I think this might have to do with subsystems, but
I'm not familiar with this hook.

> - Version Update: This is actually a pretty cool improvement.  That said,
> its very likely not going to matter to us. Even when Felix is modified to
> use OBR, Karaf will simply leverage Felix' OBR functionality.
> - Declarative Services: If Karaf has any declarative service, they will need
> to be changed to work in a manner suggested by this RFC.

karaf doesn't have any, but you've sure piqued my interest :-)

david jencks

> -----
> Mike Van
> Mike Van's Open Source Technologies Blog 
> --
> View this message in context: http://karaf.922171.n3.nabble.com/OSGi-Service-Platform-Release-4-0-Early-Draft-tp3417498p3417498.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.

View raw message