From celix-dev-return-224-apmail-incubator-celix-dev-archive=incubator.apache.org@incubator.apache.org Fri Jun 22 19:10:20 2012 Return-Path: X-Original-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7553DCB43 for ; Fri, 22 Jun 2012 19:10:20 +0000 (UTC) Received: (qmail 13528 invoked by uid 500); 22 Jun 2012 19:10:20 -0000 Delivered-To: apmail-incubator-celix-dev-archive@incubator.apache.org Received: (qmail 13492 invoked by uid 500); 22 Jun 2012 19:10:20 -0000 Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: celix-dev@incubator.apache.org Delivered-To: mailing list celix-dev@incubator.apache.org Received: (qmail 13483 invoked by uid 99); 22 Jun 2012 19:10:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 19:10:20 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of a.broekhuis@gmail.com designates 209.85.160.175 as permitted sender) Received: from [209.85.160.175] (HELO mail-gh0-f175.google.com) (209.85.160.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 19:10:13 +0000 Received: by ghbz2 with SMTP id z2so1744546ghb.6 for ; Fri, 22 Jun 2012 12:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QLWeZRNQt15kzIZn9CHj6SFvlkhoQeMauJvUbkH8/VM=; b=zF6abcNUYMkpAi/1M7AedZxZZR3Sl/EQ3jrRT9PS/d9I0xck1e+X6wPHKwyxkBY/7n n4XOyoiSyPIfqOVSfGeCjGNF5j7uuTkk9pY7aIjPgq92Ea/2VZUj4TZjy9Nw8O7z5QKH +LWCcSqxeYWME0h8y6rxXdbvs35cZNCyxDvklo1RW5Pb2+v9Yo1bLN6/Fs7k5D3/Kkp3 RlQz2KxM69cSTd8qlZ7ujiZhodJCBA6zIaJofpRnlomOS1aEklYgi+2WO8hF2rG0/qDZ wUxzqU6BtrKE7Vsv5bSejx0+xZ1hA8vzszmFZS7UCIip7dkDTznkYGmdyNaSyVjJQihh D1uQ== MIME-Version: 1.0 Received: by 10.60.3.39 with SMTP id 7mr3132041oez.4.1340392192926; Fri, 22 Jun 2012 12:09:52 -0700 (PDT) Received: by 10.182.32.2 with HTTP; Fri, 22 Jun 2012 12:09:52 -0700 (PDT) Date: Fri, 22 Jun 2012 21:09:52 +0200 Message-ID: Subject: Celix and the OSGi Specification From: Alexander Broekhuis To: celix-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=e89a8f83ad2f84e43104c31460a7 --e89a8f83ad2f84e43104c31460a7 Content-Type: text/plain; charset=ISO-8859-1 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 --e89a8f83ad2f84e43104c31460a7--