ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Preparing for a new release...
Date Fri, 11 Apr 2014 16:30:54 GMT
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

Greetings, Marcel

On 10 Apr 2014, at 21:35 pm, Sibla Wilfried <> 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 []
>> 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

View raw message