Bug 371073

Comment 1 Curtis Windatt 2012-02-09 09:41:32 EST

I think it would be onerous to expect extenders to specify every trace option that is dynamic vs static. There is also no way for Equinox to know that a given trace option is not used anywhere.

I am open to suggestions, but this is not something I would recommend changing.

Comment 2 Dani Megert 2012-02-09 10:16:36 EST

What if I have a bundle with hundreds of options and I can't afford to change them all? But still, I want to make just a few dynamic?

Comment 3 Thomas Watson 2012-02-09 14:46:09 EST

(In reply to comment #2)
> What if I have a bundle with hundreds of options and I can't afford to change
> them all? But still, I want to make just a few dynamic?

This does seem an issue.  Should we define a service property (similar to org.eclipse.osgi.service.debug.DebugOptions.LISTENER_SYMBOLICNAME that allows a listener to specify a list of supported dynamic options.  When not specified it means all options from the .options file are supported, when the list is present then only the listed options are dynamic.

Comment 4 Dani Megert 2012-02-10 03:31:54 EST

(In reply to comment #3)
> (In reply to comment #2)
> > What if I have a bundle with hundreds of options and I can't afford to change
> > them all? But still, I want to make just a few dynamic?
> 
> This does seem an issue.  Should we define a service property (similar to
> org.eclipse.osgi.service.debug.DebugOptions.LISTENER_SYMBOLICNAME that allows a
> listener to specify a list of supported dynamic options.  When not specified it
> means all options from the .options file are supported, when the list is
> present then only the listed options are dynamic.

Sounds good. Of course the preference page should then use that property.

Comment 5 Thomas Watson 2012-02-16 16:07:14 EST

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > What if I have a bundle with hundreds of options and I can't afford to change
> > > them all? But still, I want to make just a few dynamic?
> > 
> > This does seem an issue.  Should we define a service property (similar to
> > org.eclipse.osgi.service.debug.DebugOptions.LISTENER_SYMBOLICNAME that allows a
> > listener to specify a list of supported dynamic options.  When not specified it
> > means all options from the .options file are supported, when the list is
> > present then only the listed options are dynamic.
> 
> Sounds good. Of course the preference page should then use that property.

I was looking into doing this and it turns out to not be a good solution.  The issue is the DebugOptionsListener services typically get registered dynamically as the lazy activated bundles get activated.  So in many cases the the service will not even be available while we are displaying the tracing preference page.

If we want to solve this issue I think the data needs to be expressed in a more static way, either in extension definition or somehow in the .options file.  I don't think this issue is that important to focus in for the Juno release.  I suggest we deffer it.

Comment 6 Dani Megert 2012-02-17 05:53:37 EST

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > What if I have a bundle with hundreds of options and I can't afford to change
> > > > them all? But still, I want to make just a few dynamic?
> > > 
> > > This does seem an issue.  Should we define a service property (similar to
> > > org.eclipse.osgi.service.debug.DebugOptions.LISTENER_SYMBOLICNAME that allows a
> > > listener to specify a list of supported dynamic options.  When not specified it
> > > means all options from the .options file are supported, when the list is
> > > present then only the listed options are dynamic.
> > 
> > Sounds good. Of course the preference page should then use that property.
> 
> I was looking into doing this and it turns out to not be a good solution.  The
> issue is the DebugOptionsListener services typically get registered dynamically
> as the lazy activated bundles get activated.  So in many cases the the service
> will not even be available while we are displaying the tracing preference page.
> 
> If we want to solve this issue I think the data needs to be expressed in a more
> static way, either in extension definition or somehow in the .options file.  I
> don't think this issue is that important to focus in for the Juno release.  I
> suggest we deffer it.

I'm fine with that.

Comment 7 Markus Keller 2014-10-21 12:36:46 EDT

The tracing preference page (an well as the launch configuration tab) is lossy anyway, since it doesn't show the comments that are typically present in .options files and that are often necessary to understand how an option should work and what dependencies it has.

Initially, the tracing options were just meant to be copy-pasted from .options files. If you change the way options are defined, you should also consider a solution for the missing documentation.

Comment 8 Szymon Ptaszkiewicz 2016-02-15 10:50:29 EST

(In reply to Markus Keller from comment #7)
> The tracing preference page (an well as the launch configuration tab) is
> lossy anyway, since it doesn't show the comments that are typically present
> in .options files and that are often necessary to understand how an option
> should work and what dependencies it has.

The launch configuration tab has been fixed in bug 453392. The tracing preference page is tracked in bug 487057.

Comment 9 Eclipse Genie 2019-09-03 12:35:37 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.