Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of fmeschbe@gmail.com designates
 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=jYhJmwMsFa0IjX0S95KkWTh0fpkayWUj3Nu10KNET6PYYDDYyIfaGQGaMu0cQ+yWSsEm9AYRiim4u4tkaaPbCHNQ47KHqGw2OhQYYucLA3mcqVelqxuQyXkfctaGqfMselP/t6SMxOIzs7rCPARm1Nw1XoBFu25rWE31BepBdAg=
Message-ID: <ae03024e0703190056o372aaa9cwdc61dd9de2f3b1fb@mail.gmail.com>
Date: Mon, 19 Mar 2007 08:56:32 +0100
From: "Felix Meschberger" <Felix.Meschberger@day.com>
Sender: fmeschbe@gmail.com
To: "Apache Felix Dev List" <felix-dev@incubator.apache.org>
Subject: Felix Util Bundle
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,

Over the last few days, I started thinking about whether it would be
worth it to have some kind of Felix Util Bundle. This bundle would
take all sorts of utility classes, which may be used by different
bundles. In this sense this would be kind of a library bundle. The
reason for this is, that there is some functionality, which is used
over and over and which tends to be reimplemented repeatedly, for
example:


Logging

Logging is defined in the LogService Specification, but it might not
always be around or only be registered after first use. The simple
workaround is to create a helper class, which uses the LogService if
available or write to stdout/stderr otherwise. The Felix Util bundle
could provide such a helper class to prevent reinventing the wheel or
copying source code over and over ...


Read-Only Case-Insensitive String-Key Dictionary

Another common definition found all over the OSGi specs is the
Dictionary which has String keys, which are treated ignoring case and
in some situations are read-only (see Config Admin and Service
Compontents). The Felix Util bundle could provide such a Dictionary.


Requirement/Capability Abstractions

Both the bundlerepository bundle and in the framework use
Requirement/Capability abstractions of the [Dynamic]Import-Package and
Export-Package headers. In a (currently internal) project I use the
same abstraction to build a Bundle Repository Server. In providing
these abstractions in the Felix Util bundle, the common functionality
may be reutilized.


I see two use cases for this Felix Util bundle: In the standard case
of using the Felix framework, the bundle would be placed on the class
path with the o.a.f.framework jar and the packages be defined as
framework system packages. If using a different OSGi framework such as
Equinox or Knopflerfish the Felix Util bundle may simply be deployed
as another bundle.


What do you think of such a util bundle ? If there is any interest I
could also provide some initial implementation.

Regards
Felix