ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sibla Wilfried <>
Subject AW: Preparing for a new release...
Date Sat, 12 Apr 2014 22:04:43 GMT
Hi Marcel

Thx for your explanation.
I'm fine with all you wrote.

Point 1, 2 and 4 are clear and I've already a running custom controller with the embedded
ACE agent.

But to point 3) some concerns came up within the past two days.
I'v implemented such a custom controller as recommended earlier by Jan. But in the meantime
he changed his implementation recommendation and didn't have time to refactor my custom controller.
But I could do this in the last two days.

Here a short description of my situation:
My earlier implementation using the AgenControl service worked fine.

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.

Thx and Greetings

> -----Urspr√ľngliche Nachricht-----
> Von: Marcel Offermans []
> Gesendet: Freitag, 11. April 2014 18:31
> An: ACE-users Apache ACE users
> Betreff: Re: Preparing for a new release...
> 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 <>
> 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