ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Doc for ACE-62
Date Thu, 17 Dec 2009 15:28:05 GMT
On Thu, Dec 17, 2009 at 4:22 PM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:

> 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.
>
Yes. the VM params are solely for the osgi vm. Sure, can go mad when
starting a lot more bundles that also make use of the sys environments.
but.. thats really minor.


>
> Greetings, Marcel
>
>


-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

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