Community
Participate
Working Groups
Please add methods for (de)registering change listeners with the DebugOptions. Polling calls to getOptions() are comparingly expensive and calls to setOption() should be be seldom enough to justify the runtime overhead. This seems especially important/interesting in server-side environments, where tracing should be modifiable without a server restart.
This seems like a fine requirement. However I don't think we need to roll out an event mechanism, and should use the service events (registered, unregistered, modified) instead. To me the biggest challenge is not in making this service dynamic, but rather in making all the users of this service react accordingly to the changes. So, would you would you be able to contribute some code? Thx.
I'm willing to spend some time to make this happen but I'm not sure how service events can be used for notifying about debug option changes. If you explain that to me I could be able to provide an initial patch. I find it interesting that everybody starts to worry about how to make users react on changes now ;-) As I said in the newsgroup, change was always possible and it was silently accepted that clients don't react to it, possibly due to the lack of efficient API to do so (pollong was the only means). With my proposal efficient reaction becomes feasible, it should be even easier to convince users to react on changes. On the other hand I believe that not all users of the DebugOptions service really need to react on changes.
Duplicating this to bug 258705 because we did add a DebugOptions listener support in that bug for 3.5. Sorry we missed this bug during that release cycle. *** This bug has been marked as a duplicate of bug 258705 ***
