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
