Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: domain of jgawor@gmail.com designates
 209.85.212.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=QWA1EqAuKDcnP0cpd75I6Qsh9HXbht1uMsX44jhpwfCVv9LMrONlxZQ69qTptdpV02
         N9bd/G2DtCp9erVRAcelzW4GcqMFO8ZAtsLiSbgitR0PcXkDpsTnXXc+y4uN860Fa8wt
         lQ2IckZcUU8s0mXre32LRyKrVIEstCh4r2I3s=
MIME-Version: 1.0
Date: Thu, 3 Sep 2009 15:43:31 -0400
Message-ID: <5eb405c70909031243l11de5cc1naccf9cd6e6a8a200@mail.gmail.com>
Subject: Apache Karaf info
From: Jarek Gawor <jgawor@gmail.com>
To: dev <dev@geronimo.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hey,

Apache Karaf was mentioned a couple times on this list as something we
want to consider for using in/for Geronimo 3.0. So, I've been looking
at it for last few days to get a better understanding how it works,
what it does, etc. and thought maybe others want to know what I
learned about it. Overall, I think it fits pretty well for what we
want to do with Geronimo.

What does Karaf have?

- JMX (rfc 139): it actually uses the RI from OSGi Alliance
- Blueprint (rfc 124): it uses Geronimo implementation. It actually
uses Blueprint to deploy and configure all of the services it
provides. For example, the JMX connector, rmi registry, mbean server,
gshell commands, all are configured via Blueprint. It also uses the
Blueprint features that were deleted from the official spec but we
still kept it in the Geronimo impl - i.e. the Configuration Admin
service support and namespace handler extensions.
- GShell: provides commands for osgi operations (install bundle,
uninstall bundle, stop, start, etc.), adding/changing/deleting
configurations (for Configuration Admin service support), some basic
shell commands (exec, grep, etc)., some commands for creating Karaf
instances (same idea as in Geronimo), some for inspecting logs, and
some ssh commands. I think you can install ssh daemon and ssh into the
console but I have not tried that.
- Logging service: provided by Pax Logging, exposes all the logging
API (slf4j, commons logging, etc.)
- Additional url handlers for mvn and wrap urls. That's provided by
Pax Url bundles. The mvn: url handler allow you to specify a url in
mvn://group/artifacts/version/type format, and the handler will go out
to a specified set of repositories (local or remote) and resolve the
bundle and install it. The wrap: url handler allows transform and
install non OSGi jar files into OSGi bundles. See Pax Url for more
details.
- It also comes with Preference Service and Configuration Admin
Service - both provided by Felix.
- "File Install" bundle provided by Felix. It provides hot
deployment/update functionality. For example, you can drop bundles
into the "deploy" directory and they will be automatically deployed
(just like in Geronimo) and also, it can watch configuration files
(those in "etc" directory) and update the corresponding Configuration
objects (from Configuration Admin service). More on this below.
- Some JAAS security support which I haven't looked at yet.

How does it work?

Karaf can work on top of any OSGi framework and in fact comes with
Equinox and Felix jars but by default it boots Felix. Karaf starts by
instantiating the OSGi framework and than reads etc/startup.properties
file which contains an ordered list of bundles (and their run level)
to start. The bundles in the startup.properties file are specified in
mvn format. That's one of the places where Pax Url is used. Pax Url is
actually configured (see etc/org.ops4j.pax.url.mvn.cfg) to use the
"system" directory as a default local maven repo. It's also configured
with a few remote repos. The "system" directory is in mvn layout and
has all the bundles that Karaf needs (mentioned above). However,
during startup Karaf actually installs the bundles from the "system"
bundle into the framework. And with Felix, when you install a bundle
it actually copies the bundle jar file into its own "data" directory.
So after starting Karaf for the first time, you pretty much will have
the jars in the "system" directory duplicated in the "data" directory.
I guess that's the price for being OSGI framework independent. But we
might be able to improve it. Also, if you install a bundle
dynamically, it goes into the Felix's "data" directory and not the
"system" directory.

After all the bundles are installed and framework started, all the
rest of the work is done via Blueprint.

Configuration

In OSGi things are configured via Configuration Admin service.
ConfigAdmin service provides Configuration objects which basically
have multiple name=value properties and each Configuration object has
an unique id. In Karaf and with the help of "File Install" bundle
these Configuration objects are represented as simple text
configuration files under the "etc" directory with ".cfg" extension.
The name of the file corresponds to the id of the Configuration
object. And if you change the .cfg file at runtime the Configuration
object should be updated as well. Geronimo Blueprint implementation
has Configuration Admin support so all this nicely integrates
together.

Features

Karaf has this concept of "features". Features can have dependencies
on other features, they contain a list of bundles, and can have some
configuration data. So installing a feature, can trigger installation
of multiple bundles. For example, installing "http" feature installs
Geronimo Servlet spec jar bundle, Jetty bundle, and Pax Web bundle.
All are automatically downloaded from the maven repos specified in
etc/org.ops4j.pax.url.mvn.cfg.

There is also a "webconsole" feature that installs Felix's webconsole
bundle and some Karaf specific console extensions. And there are other
predefined features besides "http" or "webconsole".

As far I can tell right now, features are just external metadata and
are not usually embedded within bundles. However, feature metadata can
be deployed at runtime and actually during deployment it is turned
into a bundle.

Anyway, that's what I learned about Karaf so far. Of course, I might
have missed a few things or not provided 100% complete descriptions.
I'm sure Guillaume or others can correct me.

Jarek