Build: NetBeans IDE Dev (Build 080614)
VM: Java HotSpot(TM) Client VM, 1.5.0_15-b04, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_15-b04
OS: Linux, 2.6.25-gentoo-r4, i386
just <enter> in PHP script
Created attachment 62849 [details]
Probably fixed as a part of Editor Settings Upgrade. Try to reproduce in latest clean build.
Installing plugin: Common Scripting Language Development Tools fixed this.
I am running a new build. The problem is e.g.
<!DOCTYPE settings PUBLIC "-//NetBeans//DTD Session settings 1.0//EN"
<instance class="org.netbeans.modules.gsf.GsfOptions" method="create"/>
Now of course this class was removed in #cd7055fc20d9. The reason I think this is a core bug (specifically:
SerialDataConvertor.isModuleEnabled) is that the .settings file claims to be for org.netbeans.modules.gsf/1, yet the
current module is /2. Therefore the .settings file should be quietly suppressed by the settings infrastructure: it
claims to be written by an older and incompatible version of the module.
Víťa would I guess be interested.
We might consider enhancing the settings module a bit so that if Utilities.translate gives e.g. "" as the translation
for a class name (via META-INF/netbeans/translate.names) used in <instance> in a .settings file, the file is ignored.
That would be a simple way to just cancel any old *.settings for a given set of classes. Probably a fast-track API change.
It's the same problem as in issue #137278. This should not happen with properly imported userdir. I'm not sure what
policy/conventions we have for things like this. I know we encourage users to keep their userdirs, but can we ask them
to always import and ignore errors that happen with userdirs that has not gone through the import procedure? And if so,
is there any way to tell the IDE to import an arbitrary userdir?
If we have to deal with any userdir (without being properly imported) I will have to resurrect the options classes and
somehow make sure that the .settings converters load null for these settings files. Btw, this is a result of GSF writing
layer registration files to a userdir when initializing a language.
Importing of an old usedir is offered only when starting with empty userdir. AFAIK, there is no UI allowing to import an
arbitrary userdir. But of course user can use --userdir anytime. Radku, what was the policy in the past about userdirs
that has not gone through the import procedure?
BTW, if you already know what to import or not to import to NB6.5, please update
Simply was not recommended, not supported in any way.
> But of course user can use --userdir anytime
This is exactly the problem. Doing this will NOT import the userdir, it will simply use it. And no filters,
transformations, etc defined in o.n.upgrade will be applied. So basically the IDE will run with an old userdir that may
contain some rubbish, which if imported properly would have been removed.
Maybe we could somehow detect that the folder passed in as --userdir is in fact a userdir from some older version and
offer a user to import it properly. The IDE should then probably refuse to run with a userdir that was already upgraded
by a newer version. Just an idea...
> BTW, if you already know what to import or not to import to NB6.5, please update
> http://wiki.netbeans.org/NB65SettingsMigration accordingly.
The filter for excluding Settings.settings has been in place since 5.5, I updated the wiki page.
> Maybe we could somehow detect that the folder passed in as --userdir is in fact a userdir from some older version and
> offer a user to import it properly. The IDE should then probably refuse to run with a userdir that was already upgraded
> by a newer version. Just an idea...
I don't know if we are able to easily recognize version of userdir. I afraid of complicated logic and not much benefit.
As always, I am against relying on the importer to exclude "bad" settings, or transform old settings formats. Every
module is responsible for gracefully dealing with old settings. In the case of NbPreferences, this is trivial - just
ignore old keys (and choose new key names if you change format). A simple API change to the *.settings handler would I
think make it equally trivially to ignore *.settings from defunct classes.
> As always, I am against relying on the importer to exclude "bad" settings, or transform old settings formats.
> A simple API change to the *.settings handler would I think make it equally trivially to ignore *.settings
> from defunct classes.
Ok, it sounds reasonable. May I leave this with the core team?
Jirko, possible for 6.5?
I will look at it and try to implement Jesse's suggestions.
I implemented Jesse's proposal. If Utilities.translate() returns "", InstanceCookie is not issued. I am asking for
review but I am not sure where to document it and if increase spec versions of openide.util or settings modules. Your
comments are welcome.
Created attachment 63809 [details]
[JG01] instanceCookieChanged might also need to be updated for completeness.
[JG02] It seems you are checking for a null translation of <instance class="..."/> only. Is it supported to have a null
translation of the class name in <instanceof class="..."/> or <serialdata class="...">...</>? For the former, I would
think that this would mean that the instanceOf method would simply not report that class:
String name = Utilities.translate(attribs.getValue(ATR_INSTANCEOF_CLASS));
if (name.length() > 0) instanceOf.add(name);
For the latter, I would expect the same treatment as <instance class="..."/>: produce no InstanceCookie. It looks like
this will already work, but it is not tested.
[JG03] Have you confirmed that the proposed change can actually be used to suppress GsfOptions? E.g.
> [JG01] Done.
> [JG02] Done.
> [JG03] I can't reproduce original exception. I started build 20080613 and created PHP project. Then I saw
config/Editors/text/x-css/Settings.settings in my userdir. I started current build with this userdir but I didn't get
any exception and Settings.settings silently disappeared.
Created attachment 63876 [details]
To JG03 - strange, maybe you can debug a bit?
Otherwise it is looking good. Don't forget apichanges, I guess in settings module. Since no one has a direct dependency
on this module just to load *.settings files (for historical reasons...) I guess changing spec versions is not necessary.
>> [JG03] Tor already put a patch (http://hg.netbeans.org/main/rev/01d41235697e) which removes Settings.settings files.
If I revert his changes and add org.netbeans.modules.gsf.GsfOptions= into gsf/src/META-INF/netbeans/translate.names, it
Created attachment 63954 [details]
Sounds OK to me.
I will integrate proposed patch tomorrow.
Reopening - reproduced in NetBeans IDE Dev (Build 200810181401)
It is strange it can be reproduced in dev builds. This changeset http://hg.netbeans.org/main/rev/01d41235697e should
delete *.settings files with obsolete GsfOptions class, if assersions are enabled which should be true for dev builds.
For sure it would be better to add the following into gsf/src/META-INF/netbeans/translate.names:
Moving from ruby/GSF to editor/CSL. Step one: assign to myself ;-)
Step 2: trying to make the owner not myself but the owner of the subcomponent.
Jirko, Vito is this report still relevant? Can it be closed or should something be done in csl.api module?
Sounds like gsf/src/META-INF/netbeans/translate.names should still be created?
Yes, I think so. And also csl.api/src/META-INF/netbeans/translate.names, because gsf module may not be loaded at all.
I'll do it.
Integrated into 'main-golden', will be available in build *200904160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <email@example.com>
Log: #137240 - preventing CNFE for removed GsfOptions class