On Fri, Sep 4, 2009 at 3:43 AM, Jarek Gawor <[email protected]> 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
