Back to pax exam? :-(

[William la Forge]

Configuration is pretty simple. register a service as a managed service and drop a file into etc. Easy. Been there, done that.

Now what about testing, where the entire directory structure is created each time by pax exam?

I found this: http://www.liquid-reality.de/display/liquid/2011/09/23/Karaf+Tutorial+Part+2+-+Using+the+Configuration+Admin+Service

"After we have successfully used the Config Admin Service the only thing that remains to go into production is to deploy our bundle together with a default configuration. This can be done using a Karaf feature file. We define our feature with the bundles it needs and simply add a configfile element. This makes Karaf deploy the given file into the etc directory of our Karaf installation. If the file is already present then it will not be overwritten."

So all we need to do is (1) learn how to create features and (2) learn how to deploy them with pax exam and/or osgi.

[monster]

Well, idk how this configuration, or whatever you had in mind, should work.

But personally, I think the ideal configuration would work like dependency-injection. You have your actor, and it has "fields" containing what it needs to do it's job. That could be simple value properties, or singleton, or whatever. And you have your "configurator" (like a Guice module), that connects to whatever source of configuration information you want to use (local property file, LDAP directory, SQL DB, ... whatever) and somehow tracks changes. When changes happen, it pushes them to the "configured actors" using requests, which probably requires the actors to implement specific interfaces. So the actors do not need to know where the vales come from, and when they change. All they need to know, is that they don't change while they are processing a message/response. I think this is like a generalisation of what you do with the service tracker, right? So one issue is the "initialization", as the actor can probably not process any messages until it was fully configured once.

An alternative to creating specific configurators would be to have configuration listener interfaces, and automatically register actors that implement them as configurable actors.

What does that sound like?

[William la Forge]

Sounds like what Karaf has already built at the higher levels and is the main reason for sticking with the standard. Taking it one step further, Cellar supports configuration replication, just like my config project from JActor1.

Of course, there are other advantages to a standards compliant approach. Like being able to use pre-existing code.

--
You received this message because you are subscribed to the Google Groups "AgileWikiDevelopers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agilewikidevelo...@googlegroups.com.
To post to this group, send email to agilewiki...@googlegroups.com.
Visit this group at http://groups.google.com/group/agilewikidevelopers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[William la Forge]

Catch this. Nice features that are already part of Karaf 3.0.0, though probably not RC1.

[William la Forge]

forgot link: https://issues.apache.org/jira/browse/KARAF-888

[monster]

OK, but if Karaf itself push the changes, it won't be thread-safe; it won't be *between requests*. So I think we still need our own wrapper.

[William la Forge]

You can write your own ConfigurationAdmin, though I think a better approach would be an actor wrapper on the updates, like I did for ServiceEvents.

On Mon, May 20, 2013 at 7:00 PM, monster <skunki...@googlemail.com> wrote:

OK, but if Karaf itself push the changes, it won't be thread-safe; it won't be *between requests*. So I think we still need our own wrapper.