celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Celix and the OSGi Specification
Date Fri, 22 Jun 2012 19:09:52 GMT
Hi all,

In another message Ferry asked if Celix is only implementing the module
layer of the specification. While this should also be added to the website,
I want to list what Celix currently implements and what the status of this
is. I'll use the r4.3 core specification as a reference for this.

- Security Layer
Not implemented. Is there any need/interest for this?

- Module Layer
This is currently a rather difficult item to explain. Looking at Celix one
could say it doesn't implement a runtime module layer, but only a compile
time one (also not a "link time" one).
The module layer in Java is used to "extend" the classpath of bundles with
a specified part of another bundle. This is also possible at runtime in
Java because the classpath can be extended. Lets call this code sharing for
now.
In C this is not directly possible, the library path is defined at startup,
and libraries are linked to other libraries when this is needed.

Within Celix the choice was made to keep bundles isolated, ie the library
of one bundle isn't linked to the library of another bundle. So with Celix
it is not possible to share code between bundles. As such all information
needs to be present at compile time. This clearly has some limitations, for
example data structures need to be declared in a public header file to be
able to use them. If a complexer data type is needed a service has to be
introduced or extended to be able to use those complex types.
But, to complicate matters even more, a little while ago we started the
Native-OSGi project, and one of the issues we want to solve is code
sharing. More information about this can be found on the Native-OSGi page
[1].

So strictly speaking, at this moment Celix implements a rather limited
Module Layer. It can't be extended at runtime or link time, and information
needs to be available at compile time (via header files). In the future we
want to follow the Native-OSGi "specification" which supports code sharing.

- Life Cycle Layer
This one (together with the Service Layer) is probably the most complete.
Celix provides a bundle life cycle according to the specification, bundles
can be installed, started, stopped, uninstalled etc.
Also there is a bundle context implementing most of the specified
functions. It isn't a complete implementation, but most missing functions
can be added easily, there just hasn't been any need for those yet.

- Service Layer
Celix provides a service registry, to which services can be registered and
from which services can be retrieved (listener/trackers are available as
well).
Service can be registered and queried using attributes and filters. Again,
this implementation isn't complete, but can be extended when needed.

- Start Level
Not implemented.

I think this lists the most important parts of the Core specification.
Besides this there are some Compendium Specification Services implemented
as part of Celix:
* Deployment Admin (currently coupled to an Apache Ace client)
* Device Access (donated by Thales Netherlands)
* Log Service and Writer
* Remote Service Admin implementation (using http/json)

Not following any spec, but also note worthy:
* Shell and Shell-TUI (these do not follow the newer Command method for
adding new commands, but the "old" mechanism Felix uses for there  "old"
shell).


[1]: https://github.com/abroekhuis/NativeOSGi/wiki/Draft-Module-Layer
-- 
Met vriendelijke groet,

Alexander Broekhuis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message