Neil Bartlett wrote:
> However it would certainly be
> very useful if there was an implementation of Config Admin with a
> pluggable persistance mechanism.

I wrote such an implementation of the ConfigAdmin service for osxa.
Unfortunately, something happened to our server, so that it's not
available for download currently.

The persistence backend for my ConfigAdmin is implemented using the
whiteboard pattern. I have two persistent backend implementations (and
one very simple one that just uses a hashtable), one uses XML files
(it's a read-only backend), the other uses SQL and was written for
Postgres. Both backend implementations have a corresponding
ManagedServiceFactory and can be configured using the ConfigAdmin
itself. For bootstrapping an XML-based Store can be configured using a
system property (URL or filename).

The implementation is not fully compliant (ignores the Bundle-Location
binding and doesn't use threads, currently), but mostly because it was
being used in a similar context as the one you described.

It should be fairly simple to fix the remaining issues. I had a plan to
implement all the multithreaded behaviour in osxa using another OSGi
service, so that it would be possible to either use threads created
using new Thread() or leverage existing worker-threads (e.g. using
message driven beans when used in an EJB container) -- but I never got
around to finishing that so right now all the calls that should be
asynchronous are just synchronous calls.

I'd be more than happy to provide a the source code if there is interest.



Harald
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to