Hi Gabriel,
Please see comments inline.Regards,
Alex
----- "Gabriel Petrovay" <gabipetrovay@xxxxxxxxx> wrote:
> 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"
I agree this TODO-style comment should be resolved.I don't think it should be classified as vulnerability, it's just "if multiple selectors are contributed the exact behavior is undefined".> 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?
Generally speaking, we can't prevent anybody from contributing one more
implementation. We can just better define the system behavior is this
case.
E.g. introduce "priority" attribute and order contributions by priority.
> 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)
You are right, it's a different story.I think it would be easier to implement this per-engine predicate as additional optional interface in the same engine class.And please don't forget that DLTKContributionExtensionManager is used not only for debugging engines, but in other places too.> 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?
The project properties are not ignored, the selector class is used to read them, please look at the code of the classes I have mentioned. DLTK uses the single instance of this
DLTKContributionExtensionManager class, and selectors for each nature should be contributed by extension points.Regarding the whole debugging engines property page - it depends on the language and it's runtime.If debugging engine is always built-in in the same executable file, then there is 1:1 relation between interpreter and debugging engine and it can successfully work without configuring debugging engines separately at all.On the other hand, there are languages without built-in debugging engines (e.g. Ruby, Tcl, Python...), so debugging engines are implemented externally (as standalone executable file or in the same programming language), so it makes sense to select which debugging engine should be used. Probably per-project configuration of the debugging engines is useless flexibility and per-environment configuration should do the job, but it doesn't hurt anyway.That's how it works at the moment.
We can discuss how it can be improved, but let's keep compatibility for current use cases where possible.> 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>
> _______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
