Felix Meschberger wrote:
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.
This idea came up a while back on the Oscar mailing list too, but never
quite made it to fruition.
The three examples you give are reasonable and all exist in some fashion
in the framework already, so they could likely be refactored slightly to
make them stand-alone in cases where they are not.
The only one that is currently problematic is the capability/requirement
stuff since it is still undergoing changes in the framework. There could
also be some debate here as to whether this should be defined here or in
OBR itself.
Of course, with the maven-bundle-plugin, we can eliminate some worries
about placement of this stuff, since we can just suck it in where it is
needed to make various distributions for different purposes.
-> richard
