Hi Jan 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.
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). Thx & Greetings Wilfried > -----Ursprüngliche Nachricht----- > Von: Jan Willem Janssen [mailto:[email protected]] > Gesendet: Sonntag, 13. April 2014 14:41 > An: [email protected] > Betreff: Re: AW: Preparing for a new release... > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Wilfried, > > On 13/04/14 00:04, Sibla Wilfried wrote: > > As recommended by Jan a default control should be implemented by as a > > class implementing the AgentContextAware and the Runnable interface > > and configuring it by setting the corresponding property (something > > like agent.controler...class). > > > > In a test this works fine and it looks like a very simple and flexible > > way to do this. But I need some more additional OSGi service within my > > custom controller. And that's currently my problem. Following Jan's > > recommendation such a AgentContextAware implementation is instantiated > > by the ACE agent and the methods init, start and stop are called. And, > > if Runnable is implemented, the custom controller is started as a > > separate thread. But in this custom controller I have no change to > > lookup for some OSGi services I need. > > > > Can you give me a hint how I could solve this? I don't have access to > > the BundleContext to lookup for the required services and to register > > others. > > If you take a look at CustomContextAwareController in > org.apache.ace.agent.itest.CustomAgentControllerTest, you see just how to do > that: there the FrameworkUtil is used to obtain the bundle (and thus the > bundle context) for a given class. > > Does this give you enough information to proceed with your refactoring? > > - -- > 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 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTSoXOAAoJEKF/mP2eHDc4YCoP/3+La9dQjLQ3mEVVqzZKTlHR > HaySdXjERw+W0NQRSzHqOUoLqtbe489ntIflPTOfvyKX22W0jTYVUDPcNMBejZHd > I4aBYtPmAGJ8BHu0uc68nrU73iFBk6Wt4Vo222U2vqFYLCFMRtqxKLJYDyEFoYf0 > QBtaBWKFZpPFM+ZF8mXyvdOOPCvba0ChT6fvD4/6ZM5qKw9EU7f4iFtJX3BX7+mx > y6f3DfCLyTfsDORjBfqSByEEb9UMaHgI7pIPq/7fTdQ2N0xRaJkvxGsZA0a4Dnng > HcAm0oGFuDCP13+xr8dhkexv74MbO7/3SCG1CerJeFlZ6tBvFNcFyt/tpseQm5Z8 > HH484C7uPv+Gp0XSzd5Ms7P129mRCrvDSkewwx/9EiU5E/Cn6hK7CitvDu2ybE3p > fw2NhzleRyzNLv3+nMiJu655veztbfyN36DilzbCmxy1NFMZBioP7HGHxhFs4fvB > +XQNJRrhgbrPQD4p7+SdRRdVEfq35u4SmDiDC0sJ1ZBhBo47fBM+971EeqDMA866 > NX9SYUgHviw86glf0CdlQoSdQ8LA/LLGuxjvsfNrV2FF5SmDyXJ7cAtU3Uo5/Ji6 > lmS0xji2wC1xgR8xtVBfWUxq+WEHpdTnrjWqWA7e+oHeEKFZgSoJ4A4ux4FKJgF4 > mqcSvx+lBRARFzJBjYs0 > =xvk6 > -----END PGP SIGNATURE-----
