ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <>
Subject Re: AW: AW: Preparing for a new release...
Date Thu, 17 Apr 2014 10:09:31 GMT
Hash: SHA1

Hi Wilfried,

On 14/04/14 10:54, Sibla Wilfried wrote:
> Thanks a lot for your fast reply. Yes, that would solve my
> problem. Shame on me. I already saw this FrameworkUtil, but forgot
> about it. Event that's exactly what I would need for my usecase.

Good to hear!

> I would appreciate your recommendation on the following question:
> In my CustomController, managing the OSGi application bundles is
> only one part of its functionality. The other is interacting with
> these application bundles. One of them is responsible for
> delegating installation/update requests to the OS. Currently I
> implemented my CustomController in a certain bundle without any
> other dependencies and I'm embedding the ACE agent. I my Bundle
> Activator I'm instanciating, starting and stopping the ACE agent
> Activator and disabled the DefaultController by forwarding the
> corresponding system property agent.controller.disabled = true to
> the ConfigurationHandler. This means that my CustomControll was
> the master and controlled the ACE agent. With your new approach in 
> configuring a "agent.controller.class", the ACE agent would
> controll (or at least instatiate, start and stop) my Custom
> Controller.
> This worked for my usecase, or at least I got it working after
> some fixing loops ;-)
> Currently I'm not sure which solution I would favorize. Starting
> my Activator and controlling the ACE Agent, or starting the ACE
> Agent Activator and beeing controlled by him. While writing these
> lines and thinking a little bit more about this, I think I'l
> favorize a combination of both. Starting my Activator and
> instantiating and starting/stopping the ACE Agent Activator
> subsequently. Also configuring the agent.controller.class and
> publishing that service as an OSGi service and controlling it from
> my Application (as stated above, a little bit more than just a
> CustomController in term of ACE).

Let me rephrase your question to see if I understand it correctly: you
are not sure whether you want to let the lifecycle of your custom
controller managed by ACE or manage it yourself.

Personally, I'd opt for letting ACE manage the lifecycle for my custom
controller. This way, I would not have to worry about possible
threading issues and race conditions during starting and stopping the
controllers (which is one of the reasons why we changed the
implementation). If you look again at the custom controller
integration tests, you see that in
o.a.ace.agent.itest.CustomAgentControllerTest, the
CustomContextAwareController class implements AgentContextAware which
allows it to be part of the agent's lifecycle. Now, in the init()
method, you see that we register a custom OSGi service that can be
used by other bundles. Because of your custom controller, you are
already in control on how and when things (like: downloading an
update, installing it, and so on) get to be done.

Hope this helps you, please let us know if you have any more questions!

- -- 
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

/My world is revolving around PulseOn and Amdatu/

Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK   Apeldoorn
+31 88 586 46 30

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


View raw message