<editor-preferences> is "potentially dangerous"
Notes from emails:
> > > so there could be multiple preferences, registered by different
> > > plugins, not associated with any particular mime-type. As I was poking
> > > around, it looked like there would only be one invocation to pick up a
> > > custom-action-list, even though there might be multiple of them
> > > registers. I'm wondering if this is a potential problem. Should this
> > > case be handled or detected? Of course I have no idea how/where this
> > > filesystem/editor-preference info is put together for use.
> > >
> > Yes, your are right. This is potentially dangerous as one module could
> > override a factory supplied by someone else. I would recommend to use
> > the Editors/Actions for registration. The use of a settings factory (ie.
> > 'methodvalue' and a static method getter) is generally discouraged,
> > although still necessary in some cases.
> So the Actions are taken care of, they no longer depend on
> editor-preferences. But there is still
> <entry javaType="methodvalue"
> value="org.netbeans.modules.jvi.Module.getKitInstallActionNameList" />
> Is there some place I can register this in layer.xml directly? Then
> jvi will no longer use this "potentially dangerous" technique.
Unfortunately, not. This still needs to be done like this. We have to
introduce some better way for registering these hooks.
Thanks for filing this.
IMHO this is a dup of issue 85442.
*** This issue has been marked as a duplicate of 85442 ***
mmetelka, IIRC this issue was not covered by issue 85442. Issue 85442 is about registering actions, this issue is about
registering hooks under '<editor-preferences>', in this case 'name="kit-install-action-name-list"'. This particular
hook, registers a method that the infrastructure calls to get a list of actions which should be called when the kit is
The problem is that there can only be one kit-install-action-name-list in the system. The last module that registers it
would win I guess.
As Vita said
> This is potentially dangerous as one module could
> override a factory supplied by someone else
Lets find a solution in next..
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.
Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss