On 12 Nov 2010, at 16:02 , Ivo Ladage-van Doorn wrote: > The point is that in some cases the updated() is not invoked at all when the > service is stopped/started. I ran into this issue a couple of times now, > using the debugger I noticed that updated() was never invoked when the > service was stopped/started, causing the config variables to be null. > Unfortunately, I cannot reproduce the issue at will.
Ok. That should not happen, so let's try to focus on reproducing and fixing that. By "starting and stopping the service" do you mean starting and stopping the bundle? > So I agree that checking for these configuration entries are null should not > be necessary, however, it happens. And when it happens, your dashboard is > broken (or actually, the login gadget is, and without a login gadget there is > not much you can do). So until I know what's going on here, this check just > prevents the dashboard to break down. In that case, please clearly mark this as a temporary work-around so we don't forget to revisit it. > I changed the init() into start() based on Angelo's suggestion to resolve the > issue, although I to doubt whether this would fix anything. Briefly discussed this with Angelo. He was not sure about when updated() was invoked, but it is invoked *before* the init() method would ever be called (and once there is a valid configuration, every time a new one becomes available). So I agree that this doesn't fix anything. > Your third point is valid, but is valid for all managed services. But solving > that was outside the scope of this commit. If it is valid for all managed services and none of them currently handle configuration updates, we should indeed add an issue for each of them and fix that as soon as possible. Not being able to update your configuration means we will never be able to succesfully run in a cloud or for longer periods of time. In any case, I will investigate the issue with the updated() method not always being called (AMDATU-174). Greetings, Marcel
