Re: [Dltk-dev] // XXX: what if multiple extensions define a selector

[Gabriel Petrovay <gabipetrovay@xxxxxxxxx>]

Hi Alex,

My point was that the code of the mentioned method looks like "under construction" because of this bug/task/comment:

    protected final void addSelector(String natureId, IConfigurationElement element) {

        try {
            Object object = element.createExecutableExtension(CLASS_TAG);
            if (object instanceof IDLTKContributionSelector) {
                // XXX: what if multiple extensions define a selector

                natureToSelectorMap.put(natureId, object);
            }
        } catch (CoreException e) {
            e.printStackTrace();
        }
    }

And exactly this is my question: "what if multiple extensions define a selector"? This looks like a "selector high-jacking vulnerability"

Let me give an example as well: in XQDT (which is based on DLTK) contributors/vendors can provide some more debugging engines. Based on what logic is this debugger engine selected? The default implementation of DLTK 1.0 is the priority selector. Of course that I can define my own selector. But what is somebody comes and define theirs, do they overwrite the whole logic of selecting the engines?

The story would be different if a selector would be associated with a particular engine and not nature. More precise, the <selector> tag as a child of the <engine> tag in the org.eclipse.dltk.launching.debuggingEngine extension point. Such functionality would be very usefull because it would allow vendors to say that their debugging engine can be used only in particular cases (e.a. when a particular interpreterTypeId matches, or when a license file for using that debugger exists, or when an engine a particular language flavor/extensions accepts)

Another more general question is what is the reason for having a selector after all? Each project already has the properties where the user can specify what debugging engine to use. This propery is simply ignored because the "selector" logic. For me it looks as easy as selecting a particular interpreter for a project. Moreover, people would also expect that using a particular interpreter would automatically bring the corresponding Debugging Engine. Of course, this functionality can be achieved using selectors (unless somebody overrrides my selector with their own as described above). But in this case, why having the Debug -> Engines property page?


To sum it up:
1. the project properties do not work because they are overwritten by the selector functionality.
2. the selector can be "high-jacked".


Thanks!


Gabriel

On Mon, Sep 28, 2009 at 10:48 AM, Alex Panchenko <alex@xxxxxxxxx> wrote:

Hi Gabriel,

"selector" is an implementation to read what is selected by the user.
There is an abstract class to create selector implementations reading workspace/project preference: org.eclipse.dltk.core.DLTKIdContributionSelector.

For example:
public class RubyDebuggingEngineSelector extends DLTKIdContributionSelector {
       protected String getSavedContributionId(PreferencesLookupDelegate delegate) {
               return delegate.getString(RubyDebugPlugin.PLUGIN_ID,
                               RubyDebugConstants.DEBUGGING_ENGINE_ID_KEY);
       }
}

Regards,
Alex

----- Original Message -----
From: "Gabriel Petrovay" <gabipetrovay@xxxxxxxxx>
To: "dltk-dev" <dltk-dev@xxxxxxxxxxx>
Sent: Thursday, September 17, 2009 9:01:58 PM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] // XXX: what if multiple extensions define a selector

Hi all,

There is still this unsolved problem in the
DLTKContributionExtensionManager.addSelector(...). What are the plans
for this since, this architecture is now very limiting.

Moreover, projects have their debugging engine set (either through the
default workspace debugging engine or through the project specific
properties). Why using a selector when DLTK provides the means to be
selected by the user?

Thanks!

Gabriel


--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
www.xqdt.org
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

-- 
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com