Created attachment 5697 [details]
MRE stacktrace

well, the code in javacvs is quite simple. 
        private ResourceBundle bundle =
NbBundle.getBundle(NbCvsFsCache.class);

I suppose it's a regression in the openide?

Well, I've tried it repeatedly a few time more and I can't reproduce
it. But as you could see I'm not kiding;-) 'cause of this stacktrace..

Is it possible you had somehow incomplete build?
If you were missing
org/netbeans/modules/cvsclient/caching/Bundle.properties
if would report it exactly as it was reported...

No, I don't think it was possible to have incompleted build.
(Unzipping incompleted zip archive....the only "possible" way
how to get it)

I tried it with the same build repeatedly and it didn't happen to
reproduce it again....

I hava only one stuppid idea.....couldn't be some kinda synchronization?
Or/and just because of my Czech locales? (But again....it's not
reproductable)

I was looking into javacvs.jar
and found desired Bundle.properties file
I'm going to attach it...but it don't say you much I suppose

Created attachment 5709 [details]
problematic file

because this is not reproducible at all and we can't imagine how this
bug can happen I close this bug as worksforme now.  Reopen if it
happens again

OK. agree with you.

I'm reopening this bug.
Changing little bit SUMMARY...
Changing version from 3.4 -> FFJ 4.0 ea
  (don't know on which version I should left it...please correct me)
======================================================================
  Product Version       = Forte for Java, CE v. 4.0 (Build 020514_1)
  IDE Versioning        = IDE/1 spec=1.43.3 impl=020514_1
  Operating System      = Linux version 2.4.18 running on i386
  Java; VM; Vendor      = 1.4.1-beta; Java HotSpot(TM) Client VM
1.4.1-beta-b11; Sun Microsystems Inc.
  Java Home             = /usr/java/j2sdk1.4/sun/jdk1.4.1/jre
  System Locale; Encod. = cs_CZ; ISO-8859-2 (f4j_ce)
  kernel:  2.4.18 #4 SMP
=====================================================================

There must be realy a problem. This bug appeared 4 times now in DEV NB
version (3.4) and also in FFJ4.0 ...with various Bundles....

What they have in common?
using jdk1.4.1 b10 and b11. Czech locales. Newer RedHat 7.2
distribution (then I used 3 weeks ago).
maybe one forgoten and important information: I have dual CPU PC

In FFJ40. I was notified about the MRE. by Exception window....so it's
too visible for user.

There's no testcase how to reproduce it. It happens very spontaniously
in various situation.... 

This one happens when I was editing and viewing(in NS4.78 unix
Browser) HTML files and commiting into a cvs repository...
And it was thrown repeatedly meny times....
I check $FFJ40/lib/core.jar
and the org.netbeans.beaninfo.Bundle was here [8062b size]

I can't be more exact:-(

Created attachment 5752 [details]
another stacktrace of MRE

BUG also appears in version : FFJ40

two CPU system?  Okay it's very probably a case of too little
synchronization.  I am adding THREAD keyword and assign the bug to
Petr N, who is our expert on class loaders.

I hope so. But..... I can't explain it 'cause I have 2 CPU machine
for more then 2 years and never met this kinda problem.

Today happened 2 times again on FFJ40:-(

It happend on: Forte for Java, CE v. 4.0 (Build 020514_1)
Yesturday I was searching on large(netbeans sources)JavaCVS FS files
by statuses.
several times within 1-2 hours. I didn't nothing more (because it's very
resources and time eating task). During last search I went home and
this morning
there was the E.:-(
now it couldn't
"...find bundle for base name
org.netbeans.modules.cvsclient.commands.Bundle, locale cs_CZ"


Today I took a new build: Forte for Java, CE v. 4.0 (Build 020515_2)
and it occured again:
"Can't find bundle for base name
org.openide.explorer.propertysheet.Bundle, locale cs_CZ"
this Bundle.properties is in the size 3893b

I only started the IDE and on a root of realy small JavaCVS FS
I performed cvs->update command via cvstoolbar.
It checkouted 5 files into FS root which I didn't like that they are
here so  I mark them
and performed cvs->remove command (with the option: "delete files
before removing")
Command started to procede. Command output window opened and I wanted
to "Viev Log"
Probably in this moment the E. occured:


Èt V 16 10:49:27 CEST 2002: java.util.MissingResourceException:
Missing resource from class:
org.openide.explorer.propertysheet.Bundle_cs_CZ
Annotation: Missing resource from class:
org.openide.explorer.propertysheet.Bundle_cs_CZ
Annotation: Key which was not found:
java.util.MissingResourceException: Can't find bundle for base name
org.openide.explorer.propertysheet.Bundle, locale cs_CZ
        at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:825)
        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:794)
        at java.util.ResourceBundle.getBundle(ResourceBundle.java:688)
        at org.openide.util.NbBundle.getBundle(NbBundle.java:337)
        at org.openide.util.NbBundle.getBundle(NbBundle.java:285)
        at
org.openide.explorer.propertysheet.EmptyPanel.<init>(EmptyPanel.java:27)
        at
org.openide.explorer.propertysheet.PropertySheetTab.<init>(PropertySheetTab.java:161)
        at
org.openide.explorer.propertysheet.PropertySheet.refreshPropertySheet(PropertySheet.java:463)
        at
org.openide.explorer.propertysheet.PropertySheet.access$1100(PropertySheet.java:52)
        at
org.openide.explorer.propertysheet.PropertySheet$3.run(PropertySheet.java:638)
        at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
[catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)

This is strange. Does it happen under 1.3-class JDK or only
under betas of JDK1.4.1?

I'm using only jdk1.4.1 betas builds.
I can switch for a "while" under jdk1.4.0fcs....
But for how long? Because there is not any surenes that it could
happen again even under the exact HW,SW configuration....

On the other hand, there was no change in NbBundle
for about half a year and it should not be caused by our
ClassLoaders because it happens also for org.netbeans.beaninfo.Bundle
which is loaded by JDK classloader (through SystemCLassLoader /
ProxyClassLoader, but they were not changed for more that 2 months).
CCing Jesse (he was touching ClassLoaders last few times).

I'll also try to write some heavy-load test.

Note: there was a change in caching implementation in
java.util.ResourceBundle between 1.4.1-b10 and 1.4.1-b11

Yes, I had earlier filed some BugTraq bugs about caching problems in
ResourceBundle, and some of them were recently fixed, according to BT.
The new caching scheme is rather different from the old one, and it is
quite possible it is poorly synchronized, misuses weak/soft
references, etc. I would recommend looking for a test case to
reproduce the problem (using multiple classloaders and lots of object
allocation & collection, and multiple threads) in order to file it in
BugTraq, or directly contact the engineer who was working on the
ResourceBundle caching fixes.

http://developer.java.sun.com/developer/bugParade/bugs/4405807.html

is probably related.

Did it happened again under newer betas of 1.4.1?

Bad news.
It happened to me too, on uniprocessor Solaris/SPARC machine on
jdk1.4.1-b11, so the problem is neither SMP specific nor Linux
specific.

It happened to me for bundles org.openide.nodes.Bundle and
org.openide.filesystems.Bundle

The latter case places our ClassLoaders out of question as the
FS bundle is loaded using FileSystem.class.getClassLoader():

return NbBundle.getBundle("org.openide.filesystems.Bundle",
java.util.Locale.getDefault(), FileSystem.class.getClassLoader
()).getString (s);

I tried to write a testcase that will provoke the exception but
didn't suceed yet.

Created attachment 6426 [details]
Part of my log with exceptions

Maybe insert some code into NbBundle that would check for MRE's from
ResourceBundle, and if so, annotate the MRE heavily with extra debug
information: result of lookup of bundle tried again (in case it is a
once-only error); result in default locale (everyone reporting it says
it happens in cs_CZ, maybe the locale search is broken); even
introspected private cache fields in ResourceBundle.

What is the status of #4405807 in JDK 1.4.1b11? Was the bad attempted
fix already backed out for this beta?

It happens to me from time to time under 1.4.1-b11, so I've added
log/hierarchical retry code to my NbBundle and from the results
I infered it is JDK issue. The retry code in case of failure will:
try again 500 ms later
try again in ENGLISH locale
try skipping branding code

I used no branding so all the retry steps are like if they went
directly to ResourceBundle.
When it happened to me with the retry code, the first retry have
repaired it - it was enough to let the other threads do their work
for a while and then try again.

Anyway, in 1.4.1-b12, the ResourceBundle implementation was reverted
to that of 1.4.1-b10 including soft-referencing the ClassLoader.
See also
http://developer.java.sun.com/developer/bugParade/bugs/4681727.html

Closing as WONTFIX as it wasn't our problem and JDK team have already
fixed it.

Resolved for 3.4.x or earlier, no new info since then -> verified

Resolved for 3.4.x or earlier, no new info since then -> closing.