OSGi Service Platform Release 4.0 - Early Draft

[mikevan <mv...@comcast.net>]

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?
- 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.
- 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.
- 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.

-----
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.

Re: OSGi Service Platform Release 4.0 - Early Draft

[mikevan <mv...@comcast.net>]

All,

The Draft has a couple of different subsystem implementations: Application,
Composite Bundle, and Feature.  The primary differentiator of a feature
subsystem is that it does not impose any isolation. In Karaf provisioning,
we simply identify a set of bundles to deploy at the same basic time.  We do
not impose any modular restrictions above and beyond what is already
provided by the bundles.  The technical solution in the RFC allows packages
to be available within the subsystem that are not available outside of the
subsystem, all in the same OSGI container.  This functionality would need to
be implemented in Karaf or Felix.

Regarding the Bundle Collision Hook, from the draft:
/"The OSGi R4.3 Core specification also introduced a new framework
configuration option called org.osgi.framework.bsnversion. The default value
of this configuration option is “single” which specifies the framework will
only allow a single bundle to be installed for a given symbolic name and
version. The value of “multiple” completely disables this invariant and
allows multiple bundles to be installed having the same symbolic name and
version. This was a requirement for isolation layers (e.g. subsystems) to
allow the same bundle to be installed multiple times into multiple isolation
units (or scopes) within the same OSGi framework instance."/

I haven't had a business case to test this, but I wonder if karaf/felix
implemented this.


David Jencks wrote:
> 
> 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 :-)
> 
> thanks
> 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.
> 


-----
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-tp3417498p3417664.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: OSGi Service Platform Release 4.0 - Early Draft

[David Jencks <da...@yahoo.com>]

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 :-)

thanks
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.