ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Doc for ACE-62
Date Thu, 17 Dec 2009 15:22:45 GMT
On Dec 17, 2009, at 15:26 , Toni Menzel wrote:

> On Mon, Dec 14, 2009 at 3:37 PM, Marcel Offermans <
> marcel.offermans@luminis.nl> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message