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.

Bug 137240 - ClassNotFoundException: org.netbeans.modules.gsf.GsfOptions
Summary: ClassNotFoundException: org.netbeans.modules.gsf.GsfOptions
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: CSL (API & infrastructure) (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vitezslav Stejskal
URL: http://statistics.netbeans.org/except...
Keywords: API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2008-06-15 10:57 UTC by Tomas Mysik
Modified: 2009-04-16 08:02 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 65551


Attachments
stacktrace (4.94 KB, text/plain)
2008-06-15 10:57 UTC, Tomas Mysik
Details
Suggested patch. (4.22 KB, text/plain)
2008-07-02 12:43 UTC, Jiri Skrivanek
Details
Updated patch. (8.26 KB, text/plain)
2008-07-03 10:57 UTC, Jiri Skrivanek
Details
Updated patch. (12.29 KB, text/plain)
2008-07-04 17:44 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Mysik 2008-06-15 10:57:20 UTC
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
Comment 1 Tomas Mysik 2008-06-15 10:57:27 UTC
Created attachment 62849 [details]
stacktrace
Comment 2 Jiri Skrivanek 2008-06-16 16:25:55 UTC
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
Comment 3 prb 2008-06-16 16:51:37 UTC
Installing plugin: Common Scripting Language Development Tools fixed this.
Comment 4 Jesse Glick 2008-06-18 15:47:25 UTC
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.
Comment 5 Jesse Glick 2008-06-18 15:48:34 UTC
Víťa would I guess be interested.
Comment 6 Jesse Glick 2008-06-18 15:58:58 UTC
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.
Comment 7 Vitezslav Stejskal 2008-06-18 16:10:30 UTC
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.
Comment 8 Jiri Skrivanek 2008-06-19 08:17:45 UTC
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.
Comment 9 rmatous 2008-06-19 08:34:55 UTC
Simply was not recommended, not supported in any way.
Comment 10 Vitezslav Stejskal 2008-06-19 10:34:02 UTC
> 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.
Comment 11 Jiri Skrivanek 2008-06-19 15:48:21 UTC
> 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.
Comment 12 Jesse Glick 2008-06-19 20:13:02 UTC
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.
Comment 13 Vitezslav Stejskal 2008-06-23 12:40:16 UTC
> 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?
Comment 14 Antonin Nebuzelsky 2008-06-29 23:44:01 UTC
Jirko, possible for 6.5?
Comment 15 Jiri Skrivanek 2008-06-30 07:15:36 UTC
I will look at it and try to implement Jesse's suggestions.
Comment 16 Jiri Skrivanek 2008-07-02 12:40:52 UTC
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.
Comment 17 Jiri Skrivanek 2008-07-02 12:43:24 UTC
Created attachment 63809 [details]
Suggested patch.
Comment 18 Jesse Glick 2008-07-02 15:59:26 UTC
[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=
---%<---
Comment 19 Jiri Skrivanek 2008-07-03 10:56:20 UTC
> [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.
Comment 20 Jiri Skrivanek 2008-07-03 10:57:35 UTC
Created attachment 63876 [details]
Updated patch.
Comment 21 Jesse Glick 2008-07-03 13:48:28 UTC
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.
Comment 22 Jiri Skrivanek 2008-07-04 17:44:14 UTC
>> [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.

Comment 23 Jiri Skrivanek 2008-07-04 17:44:52 UTC
Created attachment 63954 [details]
Updated patch.
Comment 24 Jesse Glick 2008-07-08 23:50:40 UTC
Sounds OK to me.
Comment 25 Jiri Skrivanek 2008-07-21 11:21:15 UTC
I will integrate proposed patch tomorrow.
Comment 26 Jiri Skrivanek 2008-07-22 09:18:06 UTC
Fixed.
http://hg.netbeans.org/core-main/rev/9c57ccdf890a
Comment 27 Exceptions Reporter 2008-10-18 21:59:08 UTC
Reopening - reproduced in NetBeans IDE Dev (Build 200810181401)
http://statistics.netbeans.org/exceptions/detail.do?id=130221
Comment 28 Jiri Skrivanek 2008-10-22 09:04:28 UTC
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=
Comment 29 David Strupl 2009-01-14 14:35:44 UTC
Moving from ruby/GSF to editor/CSL. Step one: assign to myself ;-)
Comment 30 David Strupl 2009-01-14 14:43:39 UTC
Step 2: trying to make the owner not myself but the owner of the subcomponent.
Comment 31 David Strupl 2009-04-14 15:10:21 UTC
Jirko, Vito is this report still relevant? Can it be closed or should something be done in csl.api module?
Comment 32 Jesse Glick 2009-04-14 16:46:19 UTC
Sounds like gsf/src/META-INF/netbeans/translate.names should still be created?
Comment 33 Vitezslav Stejskal 2009-04-14 17:19:54 UTC
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.
Comment 34 Vitezslav Stejskal 2009-04-15 09:53:17 UTC
http://hg.netbeans.org/jet-main/rev/0014bb8f24a2
Comment 35 Quality Engineering 2009-04-16 08:02:25 UTC
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