Created attachment 77314 [details]
stacktrace

Unlikely it is due to autoupdate, reassigning back to platform.

Corrupted installation? Hard to guess. No steps to reproduce.

Build: NetBeans IDE Dev (Build 200904160201)
VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03
OS: Windows XP, 5.1, x86

User Comments: 
restarted IDE after plugins installation

Stacktrace: 
java.io.FileNotFoundException: C:\Documents and Settings\tester\.netbeans\dev\modules\ext\serverfx.jar (The system cannot find the file specified)
        at java.util.zip.ZipFile.open(ZipFile.java:0)
        at java.util.zip.ZipFile.<init>(ZipFile.java:114)
        at java.util.jar.JarFile.<init>(JarFile.java:133)
        at java.util.jar.JarFile.<init>(JarFile.java:112)
        at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:420)
        at org.netbeans.JarClassLoader$JarSource.resource(JarClassLoader.java:451)

Created attachment 80272 [details]
stacktrace

IDE appears to be looking for

  C:\Program Files\NetBeans Dev 20092231401\java2\modules\ext\jdom-1.0.jar 

but really exists in 

  C:\Program Files\NetBeans 6.7 M3\java2\modules\ext\jdom-1.0.jar

147 duplicates and still coming. A lot of them reported against M3 ... couple reports for builds after M3, so looks
still reproducible ;(

Probably caused by reusing old userdir (that is not supported), but has to be verified. 

BTW: all reports on Windows and all for jars on the path with space.

Not all reports for "with spaces" paths:
http://statistics.netbeans.org/exceptions/exception.do?id=188521

Without steps to reproduce I can't do anything about it.

This issue already has 150 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=11804

Could this be an x64 issue.  I'm using x64.

jglick, 
I understand we need steps to reproduce ... but in last 30 days 200 reports came ... so any idea what need to be tested
more on our side (if you have any idea, what to try/test just let me know). Thanks in advance.

Any reporter/on cc, 
are you able to reproduce this issue ? Any idea what you all done before this exception risen? Thanks in advance.

I'm afraid I have no idea where to look for ways to reproduce. Appears to be Windows-specific. Assigning to Yarda in
case he has some clue where this is coming from - most stack traces seem to relate to Stamps infrastructure, e.g.

java.io.FileNotFoundException: <userdir>\modules\ext\<whatever>.jar
  ....
  at java.util.jar.JarFile.<init>(JarFile.java:112)
  at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:420)
  at org.netbeans.JarClassLoader$JarSource.resource(JarClassLoader.java:451)
  at org.netbeans.Archive.flushCaches(Archive.java:242) at org.netbeans.Stamps$Store.store(Stamps.java:525)
  at org.netbeans.Stamps$Worker.run(Stamps.java:687)

Comments from Ron Craig:
I am using a 20090522 nightly. I only install zips. I have never used the installer. I am on Wn32 - XP pro

I am also using a new user directory. I always wipe it before installing a new nightly. The only thing that I can think
of is that a few days ago NB prompted me to update a number of modules. I agreed and they were installed. I am not 100%
certain but I think this error stared after the auto NB updates.

I'd send the update log but it is gone. I installed Jmaki since then and the last update log seems to be deleted on any
new updates. You may want to change this actually. Doesn't hurt keeping a history of all updates in update_tracking.

I attached all my messages.log files in case these help.

Created attachment 83052 [details]
messages.log files from Ron Craig

Comments from Mike Ellis:

Upgrading to the nightly seems to have broken this.

I manually get the jMaki jdom2.0.jar file, put it in the right location,
and things seem to be working again.
--
I think this is just an issue where the nightly comes with some sort of
jMaki module that EXPECTS jdom2.0, whereas only jdom1.0.jar is
installed. (I think in some customer config-directory -- don't remember
for sure)

Imho this is bug in packaging of jmaki module. It contains incorrect Class-Path tag in its manifest that points to 
non-existing JAR file. That needs to be fixed. Meanwhile I have:

changeset:   133986:2c6e786e457d
tag:         tip
parent:      133345:24d72d2643e1
user:        Jaroslav Tulach <jtulach@netbeans.org>
date:        Mon Jun 01 12:51:21 2009 +0200
summary:     #159093: Use just Level.INFO to report missing Class-Path: ext/something.jar

1. jtulach thanks for evaluation ... I created separate issue for "Use just Level.INFO to report missing Class-Path:
ext/something.jar" see issue 166333 just to keep integrations into release67 clear.

2. jmaki is just one of the modules ... what about others ? 
modules\ext\serverfx.jar
enterprise5\modules\ext\rest\jersey-spring.jar
java2\modules\ext\jdom-1.0.jar
java2\modules\ext\jaxws21\http.jar
ide11\modules\ext\commons-logging-1.1.jar
... are we going to report separate issues for those modules ?

Integrated into 'main-golden', will be available in build *200906020201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ab37b16c9113
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #159093: Teasing the test to make sure that already written files are deleted

remove INCOMPLETE - if you need more information, please contact reporters directly (there is ~400 reports so far)
or/and add comment/request for specific information/help into
http://statistics.netbeans.org/analytics/exception.do?id=224808, it will be shown to user once s/he faces this issue.

This issue already has 450 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=11804

This issue already has 454 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=11804

According the statistics the issue has 574 duplicates, but I see not only missing jdom-1.0.jar. The latest reports are
about missing commons-logging-1.1.jar, serverfx.jar, i18n-1.0.jar etc. So it's not javascript specific problem. 

Recent discussion with Petr Pišl revealed a possibility that the JAR file is really not there after an update from 6.5 
to 6.7. That would mean something went wrong in ModuleUpdater, it crashed in middle of upgrade and the cluster was not 
marked as changed. Looking at 
http://hg.netbeans.org/main-golden/diff/c08fed69f3c2/autoupdate.services/libsrc/org/netbeans/updater/ModuleUpdater.java
the code that touches .lastModified is not going to be executed when there is an IOException, that is probably wrong. 
CCing Dmitrij as autoupdate may be an important participant causing these problems.

Looking into this, Yarda is probably right, but I'd like to try several scenarios, as the report rate is quite high to
be related to I/O problems (like full disk).

*** Issue 169525 has been marked as a duplicate of this issue. ***

PLEASE CHECK THIS ISSUE I DO NOT WHAT IS MY PROBLEM OF THIS APPLICATION

*** Issue 171607 has been marked as a duplicate of this issue. ***

*** Issue 171651 has been marked as a duplicate of this issue. ***

Yes, that is unlikely I/O problems.

As for exception with serverfx.jar I can reproduce the problem easily and 100%.
1) Install any latest daily build (any distro)
2) Install dotFX from Available Plugins, restart
(NBM can also be downloaded by hand from http://dlc.sun.com/netbeans/updates/dev/uc/final/main/modules/dotfx.nbm)
3) After startup click on "fx://" icon got the FNFE
java.io.FileNotFoundException: C:\Documents and Settings\dl198388\.netbeans\dev\modules\ext\serverfx.jar (The system 
cannot find the path specified)
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:114)
	at java.util.jar.JarFile.<init>(JarFile.java:133)
	at java.util.jar.JarFile.<init>(JarFile.java:112)
	at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:422)
	at org.netbeans.JarClassLoader$JarSource.resource(JarClassLoader.java:458)
	at org.netbeans.Archive.flushCaches(Archive.java:242)
[catch] at org.netbeans.Stamps$Store.store(Stamps.java:548)
	at org.netbeans.Stamps$Worker.run(Stamps.java:712)

*** Bug 176890 has been marked as a duplicate of this bug. ***

Integrated into 'main-golden', will be available in build *201001271614* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/fa789d416fa6
User: Jesse Glick <jglick@netbeans.org>
Log: #159093 patch to lower log level about bad Class-Path elements was not working correctly (and the test was not catching it).

Integrated into 'main-golden', will be available in build *201002050200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/aebca52f64df
User: Jesse Glick <jglick@netbeans.org>
Log: Improved fix for #159093: over-strict logging of bad Class-Path declarations.
Discovered as part of diagnosis of problems in dotfx module (#180259).