Apache Karaf Cave preview

During the Karaf birthday concall, the Karaf team launched the idea of implementing an easy to use OBR (OSGi Bundle Repository) server, and extending it to provide a Karaf Features Repository (KFR).

Welcome to Apache Karaf Cave 😉

Cave is an Apache Karaf sub-project.

The core OBR is a service (RepositoryAdmin service) that can automatically install a bundle, with its deployment dependencies, from a repository.

Cave is a work in progress in the Karaf Sandbox SVN. I think it’s time to provide an initial overview about what we can do with Cave.

Cave already provides the following features:
– Storage: Cave includes a storage backend to host the artifacts. The default storage is a filesystem. We designed the Cave backend to be plug and play. This means that you can implement your own storage backend. For instance, I hope to provide implementations to store the bundles into a database, a LDAP server, or use directly a Maven repository manager as Apache Archiva.
– OBR Metadata Generation: Cave automatically looks for valid OSGi bundles and generates the OBR metadata.
– OBR Service Registration: Cave allows you to directly register a Cave Repository into the OBR RepositoryAdmin service.
– Populate Repository: of course, we can upload a single artifact in a Cave Repository, but you can also grab resources from a remote repository (for instance a Maven repository) via HTTP.
– Proxy Repository: Cave is also able to generate OBR metadata locally, referencing resources present on a remote repository.
– HTTP Wrapper Service: Cave exposes OBR metadata and bundles in an embedded HTTP server, allowing a OBR client to remotely access the Cave Server resources.
– REST Service: Cave provides a REST service layer, to let you administer the Cave Server using a REST client.
– Administration: Cave provides a set of MBeans, allowing you to complete administration of the Cave Server using a JMX client.
– Client Proxy: Cave also provides a Cave Client. It’s an OBR RepositoryAdmin service implementation which delegates the method calls to a remote Cave Server. This means that Karaf will see a local OBR RepositoryAdmin service which is actually using a remote Cave Server.

Checkout and build Cave

The Cave sources are on the Karaf sandbox subversion. You can checkout with svn:


svn co http://svn.apache.org/repos/asf/karaf/cave/trunk cave

To be able to build Cave, you have to use JDK 1.6 and Maven 3.0.3. Simply do, in the directory where you have checkout Cave:


mvn clean install

You should see something like:


[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Karaf :: Cave .............................. SUCCESS [1.221s]
[INFO] Apache Karaf :: Cave :: Server .................... SUCCESS [0.101s]
[INFO] Apache Karaf :: Cave :: Server :: API ............. SUCCESS [2.779s]
[INFO] Apache Karaf :: Cave :: Server :: Storage ......... SUCCESS [4.287s]
[INFO] Apache Karaf :: Cave :: Server :: Management ...... SUCCESS [0.879s]
[INFO] Apache Karaf :: Cave :: Server :: Command ......... SUCCESS [1.372s]
[INFO] Apache Karaf :: Cave :: Server :: HTTP ............ SUCCESS [0.873s]
[INFO] Apache Karaf :: Cave :: Assembly .................. SUCCESS [7.400s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.558s
[INFO] Finished at: Thu Aug 25 19:01:33 CEST 2011
[INFO] Final Memory: 46M/531M
[INFO] ------------------------------------------------------------------------

Install Cave

To install Cave Server in a running Karaf instance, you have to register the Cave features descriptor:


karaf@root>> features:addurl mvn:org.apache.karaf.cave/apache-karaf-cave/3.0.0-SNAPSHOT/xml/features

You should be able to see the cave-service feature:


karaf@root> features:list|grep -i cave
[uninstalled] [3.0.0-SNAPSHOT ] cave-server repo-0

To install and start Cave, simply install the cave-server feature:


karaf@root> features:install cave-server

NB: the installation of the cave-server feature will install others features, such as obr, http, war, and cxf. It could require several minutes depending of your Internet connection speed.

You can see the Cave bundles installed:


karaf@root> la|grep -i cave
[ 134] [Active ] [ ] [ ] [ 60] Apache Karaf :: Cave :: Server :: API (3.0.0.SNAPSHOT)
[ 135] [Active ] [Created ] [ ] [ 60] Apache Karaf :: Cave :: Server :: Storage (3.0.0.SNAPSHOT)
[ 136] [Active ] [Created ] [ ] [ 60] Apache Karaf :: Cave :: Server :: Management (3.0.0.SNAPSHOT)
[ 137] [Active ] [Created ] [ ] [ 60] Apache Karaf :: Cave :: Server :: Command (3.0.0.SNAPSHOT)
[ 138] [Active ] [ ] [ ] [ 60] Apache Karaf :: Cave :: Server :: HTTP (3.0.0.SNAPSHOT)

and the Cave commands are now available:


karaf@root> cave:
cave:create-repository cave:destroy-repository cave:list-repositories cave:populate-repository
cave:proxy-repository cave:register-repository cave:scan-repository cave:upload-artifact

Cave Repositories

There is no limit in number of Cave Repositories you can create.

A Cave Repository is a container for:
– the OSGi bundles (jar file resources)
– the OBR metadata (repository.xml descriptor)

By default, with the filesystem storage, Cave uses the KARAF_BASE/cave directory to store the repositories.

You can change this storage location in the etc/org.apache.karaf.cave.server.storage.cfg configuration file:


# default value
storage.location=cave
# custom storage location
#storage.location=/path/to/your/storage/folder

Create a Cave Repository

The cave:create-repository command create a Cave Repository:


karaf@root> cave:create-repository cave-repo

A Cave Repository is identified by a name.

Cave creates the repository storage in the global storage location. In our example, we can see a cave-repo directory in the default storage location:


shell$ ls cave/
cave-repo

You can use an existing directory (which can already contain artifacts) using the -l or –location option:


karaf@root< cave:create-repository -l /home/jbonofre/.m2/repository m2

By default, Cave creates the OBR metadata. If you don’t want to create the OBR metadata at repository creation time, you have to use the -nu or –no-update option:


karaf@root> cave:create-repository -nu -l /home/jbonofre/.m2/repository m2

A Cave Repository is directly register in the OBR service. If you don’t want this, you can use -nr or –no-register option:
You can also directly register the Cave Repository in the OBR service as soon as it’s created. To do this, use the -r or –register option.

List of Cave Repositories

You can list the Cave Repositories:


karaf@root> cave:list-repositories
Name Location
[cave-repo] [/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo]
[m2] [/home/jbonofre/.m2/repository]

Remove and destroy a Cave Repository

You can remove a Cave Repository using the cave:remove-repository command:


karaf@root> cave:remove-repository cave-repo

This command only removes the Cave Repository from the repositories registry. It doesn’t physically delete the OBR metadata or the artifacts. It means that you can create the repository using the existing location.

If you want to destroy the Cave Repository including the artifacts and the storage directory, you have to use:


karaf@root> cave:destroy-repository cave-repo

Generate OBR metadata

At any time, you can generate/update the OBR metadata using:


karaf@root> cave:update-repository cave-repo

Cave will scan the repository storage, looking for OSGi bundles, and generate (or update) the OBR metadata.

Register Cave Repository

Once your Cave Repository contains OBR metadata, you can directly register the repository into the OBR service:


karaf@root> cave:register-repository cave-repo

As you will see later in this article, you are now ready to use OBR commands.

We will also see that your repository is remotely available using the Cave HTTP Wrapper Service or the Cave Client.

Populate a Cave Repository

Upload a single artifact

The first way to populate your Cave Repository is by uploading a single artifact:


karaf@root> cave:upload-artifact cave-repo file:/home/jbonofre/.m2/repository/org/apache/servicemix/bundles/org.apache.servicemix.bundles.asm/3.3_2/org.apache.servicemix.bundles.asm-3.3_2.jar
karaf@root> cave:upload-artifact cave-repo http://svn.apache.org/repos/asf/servicemix/m2-repo/org/apache/qpid/qpid-broker/0.8.0/qpid-broker-0.8.0.jar

As you can see, you can use file: or http: URL. But you can also use Maven URL (mvn:groupId/artifactId/version):


karaf@root> cave:upload-artifact cave-repo mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ant/1.7.0_5

Populate from an external repository

If you have a bunch of artifacts to upload, it’s not very efficient to use the cave:upload-artifact command.

The cave:populate-repository command allows you to upload a set of artifacts from an “external” repository:


karaf@root> cave:populate-repository cave-repo file:/home/jbonofre/.m2/repository

In this example, Cave will browse the file:/home/jbonofre/.m2/repository location, looking for OSGi bundles, and will copy the artifacts in your Cave Repository storage location.

Cave supports file: but also http: URL. It means that Cave is able to browse a remote repository.

For instance, you can populate your Cave Repository with all Ant ServiceMix bundles available on the Maven Central Repository:


karaf@root> cave:populate-repository cave-repo http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.ant/

You can also populate your Cave Repository using the whole Maven Central Repository:


karaf@root> cave:populate-repository cave-repo http://repo1.maven.org/maven2

*WARNING*: the Maven Central Repository is really huge and it will require very very long time and space on the hard drive. It’s just for demonstration purpose, not really usable in the real life 😉

By default, Cave updates the OBR metadata at population time. If you don’t want it, you can use the -nu or –no-update option:


karaf@root> cave:populate-repository -nu cave-repo http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles/

Once your have populated your Cave Repository, you don’t need an Internet connection anymore as the bundles are present in the Cave Repository storage.

Proxy a Repository

A great advantage of Cave Repository population is that the bundles are locally present on the Cave Server (in the Cave Repository storage location).

But, you may also prefer to have the bundles on a remote repository (like the Maven Central Repository) and let Cave only handles the OBR metadata.

In that case, you can use the cave:proxy-repository command. The bundles stay on the “external” repository, the Cave Repository only stores the corresponding OBR metadata for the remote artifacts:


karaf@root> cave:proxy-repository cave-repo http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-lang/

*NB*: in this situation, the Cave Repository handles only the OBR metadata, it doesn’t monitor the remote repository for new artifacts or removed artifacts. It means that, if the remote repository changes (for instance, new artifacts are available), you have to re-execute the cave:proxy-repository command to update the OBR metadata.

*NB*: a best practice is to create a Cave Repository dedicated to a remote repository proxy.

OBR commands

When you have register your Cave Repository in the OBR service (using the cave:register-repository command), you can see it using the obr:list command:


karaf@root> obr:listurl
file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/repository.xml

and the bundles present in your Cave Repository are available in the OBR service:


karaf@root> obr:list
[...]
slf4j.log4j12 - slf4j-log4j12 (1.6.1)
slf4j.simple - slf4j-simple (1.6.1)
org.springframework.aop - Spring AOP (3.0.5.RELEASE)
org.springframework.asm - Spring ASM (3.0.5.RELEASE)
org.springframework.beans - Spring Beans (3.0.5.RELEASE)
org.springframework.context - Spring Context (3.0.5.RELEASE)
org.springframework.core - Spring Core (3.0.5.RELEASE)
org.springframework.expression - Spring Expression Language (3.0.5.RELEASE)
org.springframework.web - Spring Web (3.0.5.RELEASE)
org.springframework.osgi.extensions.annotations - spring-osgi-annotation (1.2.1)
org.springframework.osgi.core - spring-osgi-core (1.2.1)
org.springframework.osgi.extender - spring-osgi-extender (1.2.1)
org.springframework.osgi.io - spring-osgi-io (1.2.1)
stax2-api - Stax2 API (3.1.1)
stax2-api - Stax2 API (3.0.2)
woodstox-core-asl - Woodstox XML-processor (4.1.1)
org.apache.ws.xmlschema.core - XmlSchema Core (2.0.0)

You can also get detailed information about a bundle:


karaf@root> obr:info slf4j.api,1.6.1
---------
slf4j-api
---------
id: slf4j.api/1.6.1
description: The slf4j API
symbolicname: slf4j.api
presentationname: slf4j-api
uri: file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/slf4j-api-1.6.1.jar
size: 25496
version: 1.6.1
Requires:
package:(&(package=org.slf4j.impl)(version>=1.6.0))
ee:(|(ee=J2SE-1.3))
Capabilities:
bundle:{manifestversion=2, symbolicname=slf4j.api, presentationname=slf4j-api, version=1.6.1}
package:{package=org.slf4j, version=1.6.1}
package:{package=org.slf4j.spi, version=1.6.1}
package:{package=org.slf4j.helpers, version=1.6.1}

*NB*: in Karaf, the OBR entry format is symbolicname,version

You have detailed information about an OSGi bundle, especially the bundle requirements and capabilities.

The OBR service (client) is able to resolve the dependencies between bundles, depending the requirements and capabilities of each bundle.

For instance, we have the following commons-pool bundle details:


karaf@root> obr:info org.apache.servicemix.bundles.commons-dbcp
--------------------------------------------
Apache ServiceMix :: Bundles :: commons-dbcp
--------------------------------------------
id: org.apache.servicemix.bundles.commons-dbcp/1.4.0.1
description: This OSGi bundle wraps commons-dbcp 1.4 jar file.
documentation: http://www.apache.org/
symbolicname: org.apache.servicemix.bundles.commons-dbcp
presentationname: Apache ServiceMix :: Bundles :: commons-dbcp
license: http://www.apache.org/licenses/LICENSE-2.0.txt
uri: file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar
size: 159721
version: 1.4.0.1
Requires:
package:(&(package=javax.naming))
package:(&(package=javax.naming.spi))
package:(&(package=javax.sql))
package:(&(package=javax.transaction))
package:(&(package=javax.transaction.xa))
package:(&(package=org.apache.commons.pool)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.apache.commons.pool.impl)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.xml.sax))
package:(&(package=org.xml.sax.helpers))
Capabilities:
bundle:{manifestversion=2, symbolicname=org.apache.servicemix.bundles.commons-dbcp, presentationname=Apache ServiceMix :: Bundles :: commons-dbcp, version=1.4.0.1}
package:{package=org.apache.commons.dbcp.cpdsadapter, uses:=org.apache.commons.dbcp,javax.naming,javax.sql,org.apache.commons.pool.impl,org.apache.commons.pool,javax.naming.spi, version=1.4.0}
package:{package=org.apache.commons.dbcp, uses:=org.apache.commons.pool.impl,org.apache.commons.pool,javax.sql,javax.naming,javax.naming.spi,org.apache.commons.jocl,org.xml.sax, version=1.4.0}
package:{package=org.apache.commons.dbcp.managed, uses:=org.apache.commons.dbcp,javax.sql,org.apache.commons.pool.impl,javax.transaction,org.apache.commons.pool,javax.transaction.xa, version=1.4.0}
package:{package=org.apache.commons.dbcp.datasources, uses:=javax.sql,org.apache.commons.pool,javax.naming,org.apache.commons.dbcp,javax.naming.spi,org.apache.commons.pool.impl, version=1.4.0}
package:{package=org.apache.commons.jocl, uses:=org.xml.sax.helpers,org.xml.sax, version=1.4.0}

We can see that commons-dbcp requires org.apache.commons.pool package (in version range 1.3.0 and 2.0.0).

If we take a look on commons-pool bundle details:


karaf@root> obr:info org.apache.servicemix.bundles.commons-pool
--------------------------------------------
Apache ServiceMix :: Bundles :: commons-pool
--------------------------------------------
id: org.apache.servicemix.bundles.commons-pool/1.5.4.3
description: This OSGi bundle wraps commons-pool 1.5.4 jar file.
documentation: http://www.apache.org/
symbolicname: org.apache.servicemix.bundles.commons-pool
presentationname: Apache ServiceMix :: Bundles :: commons-pool
license: http://www.apache.org/licenses/LICENSE-2.0.txt
uri: file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/org.apache.servicemix.bundles.commons-pool-1.5.4.3.jar
size: 97332
version: 1.5.4.3
Capabilities:
bundle:{manifestversion=2, symbolicname=org.apache.servicemix.bundles.commons-pool, presentationname=Apache ServiceMix :: Bundles :: commons-pool, version=1.5.4.3}
package:{package=org.apache.commons.pool.impl, uses:=org.apache.commons.pool, version=1.5.4}
package:{package=org.apache.commons.pool, version=1.5.4}

This bundle provides package org.apache.commons.pool capability.

It means that if we deploy the commons-dbcp bundle, the OBR should also deploy the commons-pool bundle:


karaf@root> obr:deploy org.apache.servicemix.bundles.commons-dbcp
Target resource(s):
-------------------
Apache ServiceMix :: Bundles :: commons-dbcp (1.4.0.1)

Required resource(s):
---------------------
Apache ServiceMix :: Bundles :: commons-pool (1.5.4.3)

Deploying...done.

Done: the OBR has resolved that commons-pool has capabilities corresponding to the commons-dbcp requirements and so installed the commons-pool bundle in the same time of commons-dbcp.

*NB*: in the obr:deploy command, if we don’t explicitly mention the bundle version, the OBR will take the higher version available for the bundle symbolic name.

*NB*: the obr:deploy command doesn’t start the bundle, it only installs. I will enhance this command to add a -s option to start the bundles.

Cave HTTP Wrapper Service

When you install the Cave Service, it automatically starts an HTTP wrapper service.

This service allows you to access the OBR metadata and bundle artifacts via HTTP.

OBR metadata

For instance, you have the following Cave Repositories:


karaf@root> cave:list-repositories
Name Location
[cave-repo] [/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo]
[m2] [/home/jbonofre/.m2/repository]

You can access the OBR metadata using the following URL in your favorite browser:


http://localhost:8181/cave/m2-repository.xml

*NB*: the 8181 port number is the default one used by the Karaf HTTP service.

To access the OBR metadata, the URL format is:


http://[cave_server_hostname]:[http_service_port]/cave/[cave_repository_name]-repository.xml

It means that you can register the Cave Repositories on a remote Karaf instance.

In the remote Karaf instance, you just have to install the obr feature and register the Cave HTTP Wrapper repository.xml URL:


karaf@other> features:install obr
karaf@other> obr:addurl http://cave_server:8181/cave/cave-repo-repository.xml

OSGi bundles access

Cave HTTP Wrapper Service also exposes the bundles via HTTP.

For instance, if you have registered the cave-repo Cave Repository in the OBR service using:


karaf@localhost> cave:register-repository cave-repo

you have the following bundles available in the OBR service:


karaf@localhost> obr:list
org.apache.servicemix.bundles.commons-dbcp - Apache ServiceMix :: Bundles :: commons-dbcp (1.4.0.1)
org.apache.servicemix.bundles.commons-pool - Apache ServiceMix :: Bundles :: commons-pool (1.5.4.3)

If we take a look on the commons-dbcp bundle details:


karaf@localhost> obr:info org.apache.servicemix.bundles.commons-dbcp
--------------------------------------------
Apache ServiceMix :: Bundles :: commons-dbcp
--------------------------------------------
id: org.apache.servicemix.bundles.commons-dbcp/1.4.0.1
description: This OSGi bundle wraps commons-dbcp 1.4 jar file.
documentation: http://www.apache.org/
symbolicname: org.apache.servicemix.bundles.commons-dbcp
presentationname: Apache ServiceMix :: Bundles :: commons-dbcp
license: http://www.apache.org/licenses/LICENSE-2.0.txt
uri: file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar
size: 159721
version: 1.4.0.1
Requires:
package:(&(package=javax.naming))
package:(&(package=javax.naming.spi))
package:(&(package=javax.sql))
package:(&(package=javax.transaction))
package:(&(package=javax.transaction.xa))
package:(&(package=org.apache.commons.pool)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.apache.commons.pool.impl)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.xml.sax))
package:(&(package=org.xml.sax.helpers))
Capabilities:
bundle:{manifestversion=2, symbolicname=org.apache.servicemix.bundles.commons-dbcp, presentationname=Apache ServiceMix :: Bundles :: commons-dbcp, version=1.4.0.1}
package:{package=org.apache.commons.dbcp.cpdsadapter, uses:=org.apache.commons.dbcp,javax.naming,javax.sql,org.apache.commons.pool.impl,org.apache.commons.pool,javax.naming.spi, version=1.4.0}
package:{package=org.apache.commons.dbcp, uses:=org.apache.commons.pool.impl,org.apache.commons.pool,javax.sql,javax.naming,javax.naming.spi,org.apache.commons.jocl,org.xml.sax, version=1.4.0}
package:{package=org.apache.commons.dbcp.managed, uses:=org.apache.commons.dbcp,javax.sql,org.apache.commons.pool.impl,javax.transaction,org.apache.commons.pool,javax.transaction.xa, version=1.4.0}
package:{package=org.apache.commons.dbcp.datasources, uses:=javax.sql,org.apache.commons.pool,javax.naming,org.apache.commons.dbcp,javax.naming.spi,org.apache.commons.pool.impl, version=1.4.0}
package:{package=org.apache.commons.jocl, uses:=org.xml.sax.helpers,org.xml.sax, version=1.4.0}

we can see that the URI is file:/home/jbonofre/apache-karaf-2.2.2/cave/cave-repo/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar.

The Cave HTTP Wrapper Service also exposes the bundle on:


http://localhost:8181/cave/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar

Cave is able to handle bundle URI relatively to the repository one.

If means that, if you register the cave-repo Cave Repository on a remote Karaf instance using the HTTP service:


karaf@remote> features:install obr
karaf@remote> obr:addurl http://cave_server:8181/cave/cave-repo-repository.xml

you can take a look on the commons-dbcp bundle details:


karaf@remote> obr:info org.apache.servicemix.bundles.commons-dbcp
--------------------------------------------
Apache ServiceMix :: Bundles :: commons-dbcp
--------------------------------------------
id: org.apache.servicemix.bundles.commons-dbcp/1.4.0.1
description: This OSGi bundle wraps commons-dbcp 1.4 jar file.
documentation: http://www.apache.org/
symbolicname: org.apache.servicemix.bundles.commons-dbcp
presentationname: Apache ServiceMix :: Bundles :: commons-dbcp
license: http://www.apache.org/licenses/LICENSE-2.0.txt
uri: http://cave_server:8181/cave/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar
size: 159721
version: 1.4.0.1
Requires:
package:(&(package=javax.naming))
package:(&(package=javax.naming.spi))
package:(&(package=javax.sql))
package:(&(package=javax.transaction))
package:(&(package=javax.transaction.xa))
package:(&(package=org.apache.commons.pool)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.apache.commons.pool.impl)(version>=1.3.0)(!(version>=2.0.0)))
package:(&(package=org.xml.sax))
package:(&(package=org.xml.sax.helpers))
Capabilities:
bundle:{manifestversion=2, symbolicname=org.apache.servicemix.bundles.commons-dbcp, presentationname=Apache ServiceMix :: Bundles :: commons-dbcp, version=1.4.0.1}
package:{package=org.apache.commons.dbcp.cpdsadapter, uses:=org.apache.commons.dbcp,javax.naming,javax.sql,org.apache.commons.pool.impl,org.apache.commons.pool,javax.naming.spi, version=1.4.0}
package:{package=org.apache.commons.dbcp, uses:=org.apache.commons.pool.impl,org.apache.commons.pool,javax.sql,javax.naming,javax.naming.spi,org.apache.commons.jocl,org.xml.sax, version=1.4.0}
package:{package=org.apache.commons.dbcp.managed, uses:=org.apache.commons.dbcp,javax.sql,org.apache.commons.pool.impl,javax.transaction,org.apache.commons.pool,javax.transaction.xa, version=1.4.0}
package:{package=org.apache.commons.dbcp.datasources, uses:=javax.sql,org.apache.commons.pool,javax.naming,org.apache.commons.dbcp,javax.naming.spi,org.apache.commons.pool.impl, version=1.4.0}
package:{package=org.apache.commons.jocl, uses:=org.xml.sax.helpers,org.xml.sax, version=1.4.0}

we can see that the URI is now http://cave_server:8181/cave/org.apache.servicemix.bundles.commons-dbcp-1.4.0.1.jar.

We can use directly obr:deploy command as previously:


karaf@root> obr:deploy org.apache.servicemix.bundles.commons-dbcp
Target resource(s):
-------------------
Apache ServiceMix :: Bundles :: commons-dbcp (1.4.0.1)

Required resource(s):
---------------------
Apache ServiceMix :: Bundles :: commons-pool (1.5.4.3)

Deploying...done.

It’s completely transparent for the Karaf instance.

Cave REST Service

Cave Server also provides a REST service API, allowing you to handle the Cave Repositories (create, remove, destroy, etc).

By default, the REST Service is bound on http://localhost:8181/services/cave.

I will write a dedicated blog about that.

*NB*: Cave REST Service uses CXF JAX-RS implementation.

Administrate Cave Server

When you install Cave Server, it provides a set of MBeans. These MBeans allow you to monitore and administer the Cave Server.

It means that you can manipulate the Cave Server using a simple JMX client, like jconsole.

I wil write a dedicated blog about that.

Cave Client

The Cave Client is an implementation of the OBR RepositoryAdmin service which proxy all method calls to a remote Cave Server.

For the Karaf instance, the OBR service looks local, but in fact, each method call is forwarded/proxied to a remote Cave Server.

The Cave Client is still a work in progress and not yet available in this preview. However, you can already use a remote Cave Server using the Cave HTTP Wrapper Service as seen above.

TODO

I hope that this first Cave preview answer to some of your questions.

The current Cave TODO list is:
– finalize the REST service
– finalize the JMX MBeans
– finalize the Cave Client (OBR RepositoryAdmin proxy)
– add the Karaf Features Repository (KFR) support, both for the server and the client
– add a plug for the Karaf Web-Console

Feel free to post any comments, remarks, or questions, it’s exactly the purpose of this blog 😉

Comments

Post a Comment

Popular posts from this blog

Exposing Apache Karaf configurations with Apache Arrow Flight

Image
This blog post shows how to use Apache Arrow and Arrow Flight in Apache Karaf runtime. The code base is available here: https://github.com/jbonofre/karaf-arrow . Apache Arrow ? Apache Arrow is composed by: The Arrow format (specification). Format implementations with different languages (C, Java, Go, Rust, ...). Extra subprojects like Flight, Flight SQL, ADBC, nanoarrow, ... Apache Arrow format is a in-memory columnar format, super efficient for scanning and iterating a large chunks of data. In traditional memory buffer, we focus on "row". Apache Arrow format "groups" data per column, which is much more efficient on modern CPUs/GPUs. The Apache Arrow format is basically a specification. We have several implementations for this specification: C C++ C# Go Java Python Ruby Rust As the purpose of this blog post is to show Apache Arrow in Apache Karaf, we will use Arrow Java. In addition, Apache Arrow also provides several...
Read more

Getting started with Apache Karaf Minho

Image
Apache Karaf Minho Apache Karaf Minho is a new runtime, completely created from scratch. The objectives are: super easy to use and run ligtning fast, including GraalVM support Kubernetes compliant to be easily used on the cloud helping to optimize cloud costs by supporting applications colocation providing turnkey services allowing you to create Minho applications in a minute Minho is composed by: minho-boot is the core of Minho. It contains the runtime launcher and the core services (service registry, lifecycle service, configuration service, ...). minho-* services provided additional functionnalities in the runtime. You can use these services to create your own services, it's also where you will find the services managing sepcific kind of applications, allowing colocation. minho-tooling optionally provide convenient tools to create your own runtime. It includes minho-maven-plugin for instance. In this blog post, we will take a quick tour on A...
Read more

Using Apache Karaf with Kubernetes

Image
In a previous blog post ( http://blog.nanthrax.net/?p=893 ), I introduced the “new” docker support in Karaf and the use of Karaf static distribution. This post follows the previous one by illustrating how to use Karaf docker image with a Kubernetes cluster. Preparing Karaf static docker image As in the previous blog post, we are preparing a Karaf static distribution based docker image. For this blog post, I’m using the example provided in Karaf: https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist . I’m just building the distribution as usual: karaf-docker-example-static-dist$ mvn clean install Preparing kubernetes testing cluster For this blog, I’m using a minikube installed locally. The installation is pretty simple: Download minikube from https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 Rename minikube-linux-amd64 as minikube Copy minikube in your path, for instance /us...
Read more