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 Wilfried > -----Ursprüngliche Nachricht----- > Von: Marcel Offermans [mailto:[email protected]] > 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 <[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 > >
