You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Marcel Offermans <ma...@luminis.nl> on 2014/04/10 19:35:32 UTC
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
Re: Preparing for a new release...
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Damien,
Yes, and you can even split server and client (run them in 2 different VMs) and only restart the client (because that's where the workspaces are). That way, targets that poll can always connect to the server.
But, I managed to fix ACE-442 so if you could take a look and see if this helps, let me know!
Greetings, Marcel
On 11 Apr 2014, at 18:25 pm, Damien Martin-Guillerez <da...@iqspot.fr> wrote:
> Well that’s not a big issue for us since it is the server and we simply restarts it when the problem occurs. So I think it can be left for another release.
>
> Regards,
> — Damien
>
> On 11 Apr 2014, at 18:15, Marcel Offermans <ma...@luminis.eu> wrote:
>
>> Hello Damien,
>>
>> We do have an issue for adding time-outs in REST sessions (ACE-442) but we have not implemented a solution yet. I will look into this today as I have some time before my flight. Do you consider this a showstopper for the release, or just something you'd like to see implemented soon? I'm asking because with our baselining support enabled, it will become much easier for us to do releases (and at least I would like to do them way more often than about once a year). So we could schedule this for the next release as well.
>>
>> Regarding your offer to help a bit with documentation, that would be great. Articles, tutorials, etc. are all very welcome, as are code contributions. If you need any help, let me know.
>>
>> Greetings, Marcel
>>
>>
>> On 10 Apr 2014, at 19:47 pm, Damien Martin-Guillerez <da...@iqspot.fr> wrote:
>>
>>> Hello Marcel,
>>>
>>> That’s a great news.
>>>
>>> Something like a time-out on API REST session that delete them after sometimes (let say 24h) to avoid memory outage would be appreciated.
>>>
>>> I may help a bit in doing some documentation: we are writing a long series of blog entries about our experience around Apache ACE. Also I’m asking permission to my employee to open-source a bit of code we use to administrate Apache ACE (server and clients) using Oopscode Chef that might be of help.
>>>
>>> Regards,
>>> — Damien, iQSpot / Inria
>>> On 10 Apr 2014, at 19:35, Marcel Offermans <ma...@luminis.nl> wrote:
>>>
>>>> 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
>>>>
>>>
>>
>
Re: Preparing for a new release...
Posted by Damien Martin-Guillerez <da...@iqspot.fr>.
Well that’s not a big issue for us since it is the server and we simply restarts it when the problem occurs. So I think it can be left for another release.
Regards,
— Damien
On 11 Apr 2014, at 18:15, Marcel Offermans <ma...@luminis.eu> wrote:
> Hello Damien,
>
> We do have an issue for adding time-outs in REST sessions (ACE-442) but we have not implemented a solution yet. I will look into this today as I have some time before my flight. Do you consider this a showstopper for the release, or just something you'd like to see implemented soon? I'm asking because with our baselining support enabled, it will become much easier for us to do releases (and at least I would like to do them way more often than about once a year). So we could schedule this for the next release as well.
>
> Regarding your offer to help a bit with documentation, that would be great. Articles, tutorials, etc. are all very welcome, as are code contributions. If you need any help, let me know.
>
> Greetings, Marcel
>
>
> On 10 Apr 2014, at 19:47 pm, Damien Martin-Guillerez <da...@iqspot.fr> wrote:
>
>> Hello Marcel,
>>
>> That’s a great news.
>>
>> Something like a time-out on API REST session that delete them after sometimes (let say 24h) to avoid memory outage would be appreciated.
>>
>> I may help a bit in doing some documentation: we are writing a long series of blog entries about our experience around Apache ACE. Also I’m asking permission to my employee to open-source a bit of code we use to administrate Apache ACE (server and clients) using Oopscode Chef that might be of help.
>>
>> Regards,
>> — Damien, iQSpot / Inria
>> On 10 Apr 2014, at 19:35, Marcel Offermans <ma...@luminis.nl> wrote:
>>
>>> 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
>>>
>>
>
Re: Preparing for a new release...
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Damien,
We do have an issue for adding time-outs in REST sessions (ACE-442) but we have not implemented a solution yet. I will look into this today as I have some time before my flight. Do you consider this a showstopper for the release, or just something you'd like to see implemented soon? I'm asking because with our baselining support enabled, it will become much easier for us to do releases (and at least I would like to do them way more often than about once a year). So we could schedule this for the next release as well.
Regarding your offer to help a bit with documentation, that would be great. Articles, tutorials, etc. are all very welcome, as are code contributions. If you need any help, let me know.
Greetings, Marcel
On 10 Apr 2014, at 19:47 pm, Damien Martin-Guillerez <da...@iqspot.fr> wrote:
> Hello Marcel,
>
> That’s a great news.
>
> Something like a time-out on API REST session that delete them after sometimes (let say 24h) to avoid memory outage would be appreciated.
>
> I may help a bit in doing some documentation: we are writing a long series of blog entries about our experience around Apache ACE. Also I’m asking permission to my employee to open-source a bit of code we use to administrate Apache ACE (server and clients) using Oopscode Chef that might be of help.
>
> Regards,
> — Damien, iQSpot / Inria
> On 10 Apr 2014, at 19:35, Marcel Offermans <ma...@luminis.nl> wrote:
>
>> 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
>>
>
Re: Preparing for a new release...
Posted by Damien Martin-Guillerez <da...@iqspot.fr>.
Hello Marcel,
That’s a great news.
Something like a time-out on API REST session that delete them after sometimes (let say 24h) to avoid memory outage would be appreciated.
I may help a bit in doing some documentation: we are writing a long series of blog entries about our experience around Apache ACE. Also I’m asking permission to my employee to open-source a bit of code we use to administrate Apache ACE (server and clients) using Oopscode Chef that might be of help.
Regards,
— Damien, iQSpot / Inria
On 10 Apr 2014, at 19:35, Marcel Offermans <ma...@luminis.nl> wrote:
> 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
>
Re: AW: AW: Preparing for a new release...
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Wilfried,
On 14/04/14 10:54, Sibla Wilfried wrote:
> 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.
Good to hear!
> 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).
Let me rephrase your question to see if I understand it correctly: you
are not sure whether you want to let the lifecycle of your custom
controller managed by ACE or manage it yourself.
Personally, I'd opt for letting ACE manage the lifecycle for my custom
controller. This way, I would not have to worry about possible
threading issues and race conditions during starting and stopping the
controllers (which is one of the reasons why we changed the
implementation). If you look again at the custom controller
integration tests, you see that in
o.a.ace.agent.itest.CustomAgentControllerTest, the
CustomContextAwareController class implements AgentContextAware which
allows it to be part of the agent's lifecycle. Now, in the init()
method, you see that we register a custom OSGi service that can be
used by other bundles. Because of your custom controller, you are
already in control on how and when things (like: downloading an
update, installing it, and so on) get to be done.
Hope this helps you, please let us know if you have any more questions!
- --
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/
iQIcBAEBAgAGBQJTT6hbAAoJEKF/mP2eHDc4bkIP/0bOZorZKPoFC0pLdeGjFHCe
RB5jlTDuj1goImK/lHTx9vODpy2BLa1CBpfqomvfomH3NOnub6/afc1uWrm23fx1
U2JpVhJvSYgx0iu51OxVQDG/Xc1HR7ErhCcWjLeOX67nHAycKguIcVKiRcKZZl0j
BIfUivRWlGUFxoEY6qsGTZMwWbxojzy3jQ5pC/54+OQRwuftvGRuPB5RxlRbeRcX
7mkS84+bD4UwfI9nE8fW2REgXqmq72TU/U+w6gkWk1q7V4rRN6ex+QYCpztu0Gqm
eFdLuJDftadHkGBO9Uzlow41fkZw0qzYVRqpYccvUWx9d+MLYKYbKOBj9L0rc7JQ
gbyhD5N6DDVl+O8tIfdZ9hPTwOFuPgO7UFCKJFZTO4hK35AXNZ3vbS3Dfnhj3uGI
qmkto/bxhPS5qZe/eWxOt1qjA9S0mQWIYzim/HevGQyvc90h/59eipQN4T7OdrIx
UR9HTriuSgaAjXU2ZfWHJJZNyUwYKhNcjbr23BoGwuxUoMRy+8aGWSIIXgTeLExU
PB5zgBdxCVIqjRjiuVTo3ZPUGa6Y/fpHkPyumyQk03ebECkAfBoiv6Zz2mr82QlV
VNCpMaAxe7HVArkMVeLiKRwLgu9cpXhL8Xbcwcnc/OcAEtnCBVlLCUgALhkHTtBs
N6Z2a7M8b7u04YalJGDY
=ixav
-----END PGP SIGNATURE-----
Re: Preparing for a new release...
Posted by Marcel Offermans <ma...@luminis.nl>.
I’m sure Jan Willem will address Wilfried’s last questions. In the mean time I started preparations for the release, cleaning up a few old libraries and adding missing license headers to some source files. I think we’re all set now for a release, so consider this the final “heads up” before the vote. :)
Greetings, Marcel
AW: AW: Preparing for a new release...
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
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:janwillem.janssen@luminis.eu]
> Gesendet: Sonntag, 13. April 2014 14:41
> An: users@ace.apache.org
> 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-----
Re: AW: Preparing for a new release...
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----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-----
AW: Preparing for a new release...
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
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:marcel.offermans@luminis.eu]
> 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 <Wi...@bosch-si.com>
> 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:marcel.offermans@luminis.nl]
> >> 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
> >
Re: Preparing for a new release...
Posted by Marcel Offermans <ma...@luminis.eu>.
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 <Wi...@bosch-si.com> 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:marcel.offermans@luminis.nl]
>> 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
>
AW: Preparing for a new release...
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hi Marcel
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:marcel.offermans@luminis.nl]
> 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