[
https://issues.apache.org/jira/browse/KARAF-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986751#action_12986751
]
Michael Van Geertruy commented on KARAF-418:
--------------------------------------------
My comment:
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.
> Allow configurations (from ./etc) to be placed in a database.
> -------------------------------------------------------------
>
> Key: KARAF-418
> URL: https://issues.apache.org/jira/browse/KARAF-418
> Project: Karaf
> Issue Type: Brainstorming
> Reporter: Michael Van Geertruy
>
> There's been an ongoing dialogue on the dev's mailing list to discuss whether
> or not to allow configurations to be placed in a database instead of in the
> ./etc directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
