karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Karaf database"ing"
Date Wed, 26 Jan 2011 09:15:13 GMT
This discussion seems to be like it's going into way too much specific
details as how you want to deploy your karaf environments.  There are
so many possible requirements and possible solutions that I don't
think it's wise to mandate any of those.
For example, using an embedded database for storing configuration does
not make much sense to me, as if it's only available to one karaf
instance, properties are way easier to deal with imho, so unless you
have a real database somewhere available, I don't see much value.   As
for the nosql stuff, I don't think we should go that direction as it
imposes lots of constraints onto how/where you deploy your server.

I agree we could have a wiki page explaining how to set up various
things, but I'm not really sure we can go much further without
becoming too specific.

On Tue, Jan 25, 2011 at 21:44, karafman <mvangeertruy@comcast.net> wrote:
> 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
> simple.
> 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.
> -----
> Karafman
> 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.

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message