karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From karafman <mvangeert...@comcast.net>
Subject Re: Karaf database"ing"
Date Tue, 25 Jan 2011 20:44:16 GMT

Thanks for re-addressing this.

Some other items to consider are:
1) Do we use a lightweight database inside of Karaf to initially hold
configuration information and if so, which one?  The selection criteria
should be that the database have a small footprint, and its license should
be the same as the Karaf license.  If we go this route, we will want to
mandate the database, schema, etc.  Also, do we want an internal database to
be relational or nosql?  Nosql would definately provide a lightweight
database as we would only be fetching name-value pairs, but would make it
less accessable to users as there are more users familiar with relational
aspects than nosql.
2) At what point should Karaf go to the database for information? Should the
trigger be the existance (or non-existance) of the ./etc directory?
3) How do we put configurations into the database?  For example, if someone
wants to use an external database to hold thier configurations, do we create
a config:database command that allows them to enter connection information,
schema, table name, etc at runtime?
4) How much do we want to leverage the internal database?  For example, do
we want to push all the ./etc configurations into the internal database and
then have the configAdmin service read from that?
5) What changes need to be made to the configAdmin service to preserve
Karaf's dynamic configuration feature when using a backend database?
6) What changes would need to be made to the console to allow the editing of
configurations stored in an external database from within Karaf?  Are any
changes necessary, can we assume the user will be using a tool from their
database to make changes to configurations?

In my original proposal I suggested an all-or-nothing approach which may not
be what everone would like.  In that proposal I suggested using a small OSGi
friendly database (like H2) inside of Karaf. On startup if the ./etc file
was missing, Karaf would attempt to load configurations from the database. 
If the internal database were empty, Karaf would prompt the user to indicate
the location of ./etc configurations (assuming they are in files somewhere),
load them into the internal database, and then continue starting up the
system.  If the user wanted to use an external database already populated
with configurations, Karaf would allow them to enter the database connection
information on startup, put it into the internal database, and would use
that connection information to obtain configurations from the external
database. Karaf would also need to initially look for the existance of
connection information in the internal database. The database schema would
be very simple:  numeric key | configuration property name | configuration
property value.

I agree with Guillaume that we should not mandate the use of an ORM like
JPA, as this would unnecessarily complicate the implementation.

Regarding Guillaume's suggested implementations:
Implementing a backend for felix configAdmin would be a difficult thing to
do.  After looking at the configAdmin code, this would by no be means

Writing a bundle that polls the db and pushes data into config admin seems
like the better approach; however, this would need to regularly poll the
database to allow dynamic configurations to be possible.

Slayer of the JEE
Pounder of the Perl Programmer

View this message in context: http://karaf.922171.n3.nabble.com/Karaf-database-ing-tp2302963p2333955.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

View raw message