On Dec 17, 2009, at 15:26 , Toni Menzel wrote:

> On Mon, Dec 14, 2009 at 3:37 PM, Marcel Offermans <
> [email protected]> wrote:
> 
>> I was wondering if there is some kind of "bundle diff tool" that can show
>> us how we're doing (comparing Ant and Maven builds). Does anybody know of
>> such a tool?
>> 
> 
> Well, i was wondering writing such a tool. Then comparism should be
> graceful, so that it "highlights" the important spots and does not goes mad
> in bit level.
> Think it could make sense, if there's nothing out there yet.

I have not found anything yet, but I only did a quick search.

>> At the same time, if
>> we can provide some kind of runnable profile as part of Pax Runner, that
>> would be very convenient too, and launch it with something like:
>> 
>> pax-run.sh gateway-ID http://ace-host-address/
>> 
>> At least, the current management agent by default needs these two
>> parameters, its own ID and the address of the ACE server to connect to,
>> other "identification" and "discovery" services might automate this.
> 
> Yep, a configurator that allows those params from, say eviironment, the we
> are quite close..
> (pax-run.sh --profiles=org.apache.ace.gateway --args="-Dace.gateway.id=foo
> -Dace.gateway.server.url=http://foo.com/server";)
> would that be something that ok ?

We could do that, but I'd prefer a slightly different implementation, because:

The configurator bundle is only responsible for converting configuration files 
it finds in a specific folder to ConfigurationAdmin. In that sense it's like 
FileInstall but just for configuration data.

The management agent itself has two services it relies on:
1) Identification, which should somehow return a unique identification for a 
target
2) Discovery, which should somehow determine the (relay) server to talk to

The current management agent has an identification and discovery implementation 
that depend on ConfigurationAdmin settings.

If we want to do it differently, we can just provide alternative 
implementations for those two services that for example read system properties 
directly, instead of going through ConfigurationAdmin, which has the added 
bonus that the management agent then does not depend on ConfigurationAdmin 
anymore.

The downside is that system properties are global to the JVM, but the way Pax 
Runner works it will probably only start one OSGi framework per JVM anyway.

Greetings, Marcel

Reply via email to