Hello Wilfried, As you know we've had a few off-list discussions about custom controllers, so to keep everybody informed I am going to summarize that discussion and try to answer your questions.
The new management agent that we've build over the past months was designed to support a few new use cases that previously were not possible: 1) It can update itself. 2) Its default behaviour is smarter than before. 3) You can customize it to work exactly the way you want. 4) It is self-contained. There are a few implications as well: First of all, for the update mechanism to work, the management agent must always be a single bundle. This bundle can be put in the OBR, and the update strategy for the agent is to always go to the highest available version. Second of all, you can now replace the "default controller" which implements the complete behaviour of the agent and talks to the APIs of that agent. The default controller is quite versatile, but since we cannot always please everybody, we allow people to replace it with their own version. To do this, and keep the agent in a single bundle, that does mean you need to create your own management agent bundle (and I would suggest you give it your own Bundle-SymbolicName as well). Back to your questions, I would recommend you only use your own controller and embed that in a management agent bundle you build yourself. It can of course re-use all kinds of code of the standard agent. I would not split the agent into two bundles, that only complicates things. Theoretically you might still do that if you don't care about updating your management agent (or do it some other way) but creating a new agent bundle would definitely be my starting point. Greetings, Marcel On 10 Apr 2014, at 21:35 pm, Sibla Wilfried <[email protected]> wrote: > Nice to hear that you are going to prepare the new release. > > Yesterday I saw that you changed a little bit the ConfigurationHandler on the > agent. > The put method has been removed and the > AgentConstants.CONFIG_CONTROLLER_DISABLED has been set to deprecated. > I'm fine with this in principle. > But I'm using this to switch the ACE agent on/off in my Custom Controller. > And thus, I will have to deactivate the polling of the DefaultController > directly by setting the corresponding Syst. Prop at startup. > > In my current custom controller implementation I use the same property > (AgentConstants.CONFIG_CONTROLLER_DISABLED) for enabling/disabling the > polling, but when my custom controller is checking for updates, I disable the > ACE agent by forwarding disbled=true to the ACE agent. > Do I have to adjust my implementation or is there another option to stop > polling within the ACE Agent? > > Thx in advance > > Greetings > Wilfried > >> -----Ursprüngliche Nachricht----- >> Von: Marcel Offermans [mailto:[email protected]] >> Gesendet: Donnerstag, 10. April 2014 19:36 >> An: ACE-dev Apache ACE developers >> Cc: ACE-users Apache ACE users >> Betreff: Preparing for a new release... >> >> Hello all, >> >> Over the last couple of weeks we have been working towards a new release. >> Baselining is in place, the code moved to Java 7, we upgraded to the latest >> versions of some of our dependencies and fixed lots of issues. Overall, I >> think it is time we cut a new release. Since we are now using semantic >> versioning, I propose we use that to version our overall release as well. We >> have some major changes, which means our release should be 2.0.0. >> >> I would like to know if there are things that anybody would absolutely like >> to >> have in the upcoming release. If not, I propose we "feature freeze" the >> repository and start a vote soon. As always there is some work to be done on >> the website, so if anybody wants to help out with that, let me know. >> >> Greetings, Marcel >
