Bug 84053 - Sometimes the i18n option in any String editor fire a exception
Sometimes the i18n option in any String editor fire a exception
Status: RESOLVED WORKSFORME
Product: java
Classification: Unclassified
Component: I18N
5.x
All All
: P3 (vote)
: 6.x
Assigned To: Alexey Butenko
issues@java
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-01 19:16 UTC by Michel Graciano
Modified: 2009-04-01 12:25 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
log file. (29.29 KB, text/plain)
2006-09-01 19:18 UTC, Michel Graciano
Details
Bundle name after conflicted update. (114.35 KB, image/jpeg)
2006-09-11 16:57 UTC, Michel Graciano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Graciano 2006-09-01 19:16:24 UTC
Sometimes, when I trying open any String propeties that can be
internationalized, fire a exception, as in attachment.
I can't define how can I simulate this, but, I feel that when I update, from
CVS, my properties file is in conflict. After this moment, are impossible open
any String editor. To solve this for now, I remove i18n settings file in my user
NetBeans folder.
Comment 1 Michel Graciano 2006-09-01 19:18:47 UTC
Created attachment 33511 [details]
log file.
Comment 2 Marian Petras 2006-09-11 14:13:32 UTC
Excerpt from the log file:

  Product Version         = NetBeans 5.5 Beta 2 (Build 200607190830)
  Operating System        = Linux version 2.4.25-klg running on i386
  Java; VM; Vendor; Home  = 1.5.0_01; Java HotSpot(TM) Client VM 1.5.0_01-b08;
                            Sun Microsystems Inc.; /opt/jdk1.5.0_01/jre
Comment 3 Marian Petras 2006-09-11 15:00:36 UTC
This is a really strange exception. I found three possible 
scenarios that could lead to it:

Scenario A:
The .properties file from which a property value should be read is deleted,
renamed or otherwise made unavailable at the moment the property editor is being
opened.
This corresponds to the situation that statement
    I18nUtil.getOptions().getLastResource2()
returns non-null object at line FormI18nIntegerEditor:201 but the next call of
the same statament (on line 202) returns null.

Scenario B:
The DataObject corresponding to a .properties file from which a property value
should be read is remembered and just a very short moment later the same
.properties file is handled by a different DataLoader, producing a different
type of DataObject for the same .properties file.
This corresponds to the situation that statement
    I18nUtil.getOptions().getLastResource2()
returns an instance of PropertiesDataObject at line FormI18nIntegerEditor:201
but the next call of the same statament (on line 202) returns a different
DataObject of a different type. This looks absurd to me.

Scenario C:
The .properties file was detected as a PropertiesDataObject. The next time the
property is going to be used, the .properties file is handled by a different
DataLoader (from a different module) and the corresponding DataObject is not a
PropertiesDataObject.
This corresponds to the situation that method I18nOptions.getLastResource2()
returns an instance of DataObject that is not a (subtype of) PropertiesDataObject.
This might occur after an additional module handling .properties files was
installed. Deleting the I18n settings file should help permanently in this case.

hmichel, have you encountered the exception since you had deleted the i18n
settings file?
Comment 4 Marian Petras 2006-09-11 15:09:57 UTC
I do not know how to prevent any of the scenarios but I know how to prevent the
exception from being thrown.

Change #1:
----------
replace
     if(I18nUtil.getOptions().getLastResource2() != null)
         formI18nInteger.getSupport().getResourceHolder()
                    .setResource(I18nUtil.getOptions().getLastResource2());
with
     DataObject lastRes = I18nUtil.getOptions().getLastResource2();
     if(lastRes != null)
         formI18nInteger.getSupport().getResourceHolder().setResource(lastRes);

Change #2:
----------
Check that the DataObject 'lastRes' is accepted by the resource holder
(getResourceClasses()) before calling 'setResource(...)' or catch the
IllegalArgumentException if it is thrown. Either of these solutions would have
the same effect - the illegal DataObject would not be used but it would not
interrupt the rest of the process.
Comment 5 Marian Petras 2006-09-11 15:13:26 UTC
This exception can happen only under really strange conditions and there are no
step-by-step instructions for provocation of the exception - lowering priority
to P3.

It may be raised back to P2 if the user provides the instructions and if it is
hard to prevent the exception.
Comment 6 Michel Graciano 2006-09-11 16:54:36 UTC
Hi,
I can't simulate the problem again, but now occur something that is more common.
I update my .properties file (I have just one for the project), and the conflict
are generated.
1-The opened .properties file are not updated (the file content are not updated,
and if I try Ctrl + Shift + 1 shortcut, this don't locate the file, so, I
obligated to close the file and open (again) it from folder view.
2-The bundle name are "broken", as in attachment.

Maybe, as the bundle name are incorrect, if the "conflict" file are deleted, by
IDE or another process, maybe the exception attached at beginning can be fired?
I don't have sure, just suggestion. I will try simulate this again today and
during this week, and if I have more details, post here as soon as possible.

Regards and thanks for your attention!
Comment 7 Michel Graciano 2006-09-11 16:57:58 UTC
Created attachment 33772 [details]
Bundle name after conflicted update.
Comment 8 Michel Graciano 2006-09-18 15:47:49 UTC
Today this problem occur again, after a cvs update. I can't reproduce this
manually, but in several times I run cvs update with conflicts in my .properties
file (last property used file), I have this problem. I think that the 'Bundle
Name' for i18n dialogs are been updated when I running the cvs update action. I
hope can helpful.
PS: I need delete my seetings file again to all works fine again.
Comment 9 Alexey Butenko 2008-12-03 13:22:34 UTC
Not reproducible
Comment 10 Alexey Butenko 2009-04-01 12:25:31 UTC
WORKSFORME


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo