Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Debug option listeners
Debug option listeners [message #75088] Thu, 19 October 2006 18:08 Go to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Hi,

Would it be possible to add methods for (de)registering 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.

Cheers
/Eike
Re: Debug option listeners [message #75393 is a reply to message #75088] Tue, 24 October 2006 19:30 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
The problem is most plugins just get their debug options once and cache
them somewhere and never call getOptions again. So even if you call
setOption with a different value almost nobody would see it.

Tom

Eike Stepper wrote:
> Hi,
>
> Would it be possible to add methods for (de)registering 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.
>
> Cheers
> /Eike
>
Re: Debug option listeners [message #75442 is a reply to message #75393] Tue, 24 October 2006 20:13 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Tom,

I see. But I can also imagine that with server-side Eclipse becoming
more popular people might want to change tracing without restarting.
Like me ;-)
Do you think it's worth a try?

Cheers
/Eike


Tom Watson schrieb:
> The problem is most plugins just get their debug options once and
> cache them somewhere and never call getOptions again. So even if you
> call setOption with a different value almost nobody would see it.
>
> Tom
>
> Eike Stepper wrote:
>> Hi,
>>
>> Would it be possible to add methods for (de)registering 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.
>>
>> Cheers
>> /Eike
>>
Re: Debug option listeners [message #75624 is a reply to message #75442] Wed, 25 October 2006 18:36 Go to previous messageGo to next message
Eclipse User
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com

sure! What is needed here is for the people reading the flags to read
them more than once. It is not something that, with the current
mechanism, can be changed in one place. All the various bundles
involved would have to change how they treat the options. So you could
argue that Equinox ought to do it everywhere we can and that would have
some merit. Please open bug reports for the components you thing would
be particularly relevant for this kind of change.

Jeff

Eike Stepper wrote:
> Tom,
>
> I see. But I can also imagine that with server-side Eclipse becoming
> more popular people might want to change tracing without restarting.
> Like me ;-)
> Do you think it's worth a try?
>
> Cheers
> /Eike
>
>
> Tom Watson schrieb:
>> The problem is most plugins just get their debug options once and
>> cache them somewhere and never call getOptions again. So even if you
>> call setOption with a different value almost nobody would see it.
>>
>> Tom
>>
>> Eike Stepper wrote:
>>> Hi,
>>>
>>> Would it be possible to add methods for (de)registering 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.
>>>
>>> Cheers
>>> /Eike
>>>
Re: Debug option listeners [message #75677 is a reply to message #75624] Thu, 26 October 2006 03:40 Go to previous message
Eclipse User
Originally posted by: stepper.sympedia.de

Jeff,

I'm not sure if I got you right. As far as I understood the DebugOptions
service, there is already a setOption() ethod that can be used by anyone
at anytime to change any option value of any plugin. So I'd argue that
everybody who reads the flags only once does not comply with the API
contract anyway and since there are only a handful of methods in this
particular service they will most probably be aware of that and accept
it. I just ask for the addition of change listeners and I don't see why
any other component than the DebugOptions service should be affectd or
even changed. I assume you don't want me to analyze all Equinox or
Eclipse classes with respect to missing change event notification?

Starting with the DebigOptions service I've filed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=162347 ;-)

Cheers
/Eike



Jeff McAffer schrieb:
> sure! What is needed here is for the people reading the flags to read
> them more than once. It is not something that, with the current
> mechanism, can be changed in one place. All the various bundles
> involved would have to change how they treat the options. So you
> could argue that Equinox ought to do it everywhere we can and that
> would have some merit. Please open bug reports for the components you
> thing would be particularly relevant for this kind of change.
>
> Jeff
>
> Eike Stepper wrote:
>> Tom,
>>
>> I see. But I can also imagine that with server-side Eclipse becoming
>> more popular people might want to change tracing without restarting.
>> Like me ;-)
>> Do you think it's worth a try?
>>
>> Cheers
>> /Eike
>>
>>
>> Tom Watson schrieb:
>>> The problem is most plugins just get their debug options once and
>>> cache them somewhere and never call getOptions again. So even if
>>> you call setOption with a different value almost nobody would see it.
>>>
>>> Tom
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to add methods for (de)registering 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.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
Previous Topic:javax.servlet.Filter in web.xml
Next Topic:Help with Database
Goto Forum:
  


Current Time: Fri Oct 31 08:32:29 GMT 2014

Powered by FUDForum. Page generated in 0.01964 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software