This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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 User Comments: just <enter> in PHP script
Created attachment 62849 [details] stacktrace
Probably fixed as a part of Editor Settings Upgrade. Try to reproduce in latest clean build. http://wiki.netbeans.org/EditorSettingsUpgrade http://hg.netbeans.org/core-main/rev/cd7055fc20d9
Installing plugin: Common Scripting Language Development Tools fixed this.
I am running a new build. The problem is e.g. ---%<--- $userdir/config/Editors/text/x-css/Settings.settings <?xml version="1.0"?> <!DOCTYPE settings PUBLIC "-//NetBeans//DTD Session settings 1.0//EN" "http://www.netbeans.org/dtds/sessionsettings-1_0.dtd"> <settings version="1.0"> <module name="org.netbeans.modules.gsf/1"/> <instanceof class="java.io.Externalizable"/> <instanceof class="org.openide.util.SharedClassObject"/> <instanceof class="java.beans.beancontext.BeanContextProxy"/> <instanceof class="java.io.Serializable"/> <instanceof class="org.openide.options.SystemOption"/> <instanceof class="org.netbeans.modules.editor.options.OptionSupport"/> <instanceof class="org.netbeans.modules.editor.options.BaseOptions"/> <instance class="org.netbeans.modules.gsf.GsfOptions" method="create"/> </settings> ---%<--- 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 http://wiki.netbeans.org/NB65SettingsMigration accordingly.
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. Ok > 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] Suggested patch.
[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. ---%<--- gsf/src/META-INF/netbeans/translate.names org.netbeans.modules.gsf.GsfOptions= ---%<---
> [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] Updated patch.
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 fixes ClassNotFoundException.
Created attachment 63954 [details] Updated patch.
Sounds OK to me.
I will integrate proposed patch tomorrow.
Fixed. http://hg.netbeans.org/core-main/rev/9c57ccdf890a
Reopening - reproduced in NetBeans IDE Dev (Build 200810181401) http://statistics.netbeans.org/exceptions/detail.do?id=130221
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: org.netbeans.modules.gsf.GsfOptions=
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.
http://hg.netbeans.org/jet-main/rev/0014bb8f24a2
Integrated into 'main-golden', will be available in build *200904160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/0014bb8f24a2 User: Vita Stejskal <vstejskal@netbeans.org> Log: #137240 - preventing CNFE for removed GsfOptions class