This pacth fixes a problem method getValue(Class kitClass, String settingName, boolean evaluateEvaluators) at
Steps how to reproduce the bug:
1. Open a mobility project document.
2. Change such options as tab size, right margin position so they are not equal to defaults.
3. Close NetBeans.
4. Start NetBeans again.
Now we see that when the document is shown after restart, it looks like settings are unchanged and still set to
defaults, though under options menu new values are shown as they should.
The problem appears because J2MEKit, which is responsible for editing mobility projects, doesn't have a MIME type
registered for it and thus when the mentioned method tries to get settings, it is unable to get proper MIME type and
The patch fixes the method and now if it is unable to get MIME for the given kit, it tries to get MIME for the
superclass kit and so on. Though MIME for J2MEKit is not registered, it is registered for its superclass, JavaKit, and
settings are properly loaded. This patch fixes problems in the similar situations with other kits as well.
Created attachment 60697 [details]
Hi, thanks for the patch, but I don't think that this is the right way to go. First, I'm working on issue #90403, which
is about getting rid of BaseOptions, Settings and the whole concept of tying settings to kit classes. Second, why
doesn't J2MEKit have its mime type and/or why are you using at?
I'm marking this as a defect dependent on #90403. When #90403 is fixed this should no longer be a problem I believe.
Although, I don't fully understand how you are using J2MEKit.
OK, let me answer the questions one by one.
1. This issue surely depends on issue #90403, when the need in tying settings to kits is gone, there's no use for this
patch. However that task is intended to be fulfilled in the future. NetBeans 6.1 is going to be released very soon and
it has this bug, which is very annoying if you work with mobility projects and use non-default editor settings. Every
time you open NetBeans with opened mobility projects, you have to walk to options, change settings once, save the
options, open them once more, then set the previous settings. This seems to be the only workaround.
What I'm suggesting is just to include this patch in 6.1 because issue #90403 is scheduled for some distant future and
6.1 is almost here (with this irritating bug).
2. J2ME has it's MIME type, difference is that it's retrieved not by calling the method of the kit class, but by
org.netbeans.modules.editor.impl.KitsTrackerImpl. And this class seems to be unable to register some mime type with
more than one kit class. Sure, whole new concept will fix it, but that doesn't apply to 6.1.
3. Well, it's not a problem just with J2MEKit, this problem could arise for any kit which extends another and uses the
Ad #1 - I see. It's serious and we should address it.
Ad #2 - Yes, the problem is that we usually don't have an instance of the kit, but only its implementation class. That's
why we introduced KitsTracker to provide at least some way of translating kit classes to mime types. From what you say
the fix should happen there. I'll have a closer look.
As for the release dates - 6.1 is out and patch1 nominations are closed, so the next earliest official release will be
patch2. I make the fix in trunk and ask you for verification. If all goes well we will then mark it for inclusion in patch2.
I pushed the fix to the main. hotxrock, could you please verify that it fixes the problem on your end? Thanks
Yes, the problem is now fixed, mobility documents are opened with proper settings at startup. Thanks for such a quick
Integrated into 'main-golden', available in NB_Trunk_Production #166 build
User: Vita Stejskal <firstname.lastname@example.org>
Log: #133942 (fixed): better support for pure 'implementation' subclasses of some other editor kit, which is properly registered and has its mimetype
Great! Jirko, I think we should add this to patch2? Agree? Objections? Thanks
I agree, this is good candidate
The fix has been ported into the release61_fixes branch: