Apache Karaf info

[Jarek Gawor <jg...@gmail.com>]

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

Re: Apache Karaf info

[Shawn Jiang <ge...@gmail.com>]

On Fri, Sep 4, 2009 at 3:43 AM, Jarek Gawor <jg...@gmail.com> wrote:

> 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
>

I noticed there's rfc 139 RI(ASL2) in Karaf too, I'm wondering if geronimo
can use this RI as rfc 139 implementation directly.

- 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.
>

This is like current plugin and plugin group of geronimo.

>
> 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
>
This is really a good summary of karaf, are there any further discussions on
how to reuse karaf(part or whole) in geronimo 3.0 ?


-- 
Shawn