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.
Summary: | java.io.FileNotFoundException: C:\Program Files\NetBeans Dev 200902231401\java2\modules\ext\jdom-1.0.jar (The system cannot find the file specified) | ||
---|---|---|---|
Product: | platform | Reporter: | spungey <spungey> |
Component: | Module System | Assignee: | Petr Nejedly <pnejedly> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | 3aho3a, 3st, acecz, alessandronip, aljhon9292, aljsteiner, amasino, amienel, ashtavi, bclemens, bonji3, boucherb, budgie67, clclcarvalho, compucoder, danielsimonjr, darthanakel, davti, dlipin, dnorton17, ellgrupo, emiddio, fmcorp, fortmill, haifeng, highjo, hoornet, imadb, issues, javaean, jblume, jglick, joecsc, jomello_br, jpleed3, jskrivanek, krishnadasants, limlom, markk, mastorgano, mhuebner, michaelnazarov, mikee11, mmirilovic, naughtybunnie, ncruz1959, ovk, smsmithee, sonicwallz, spungey, tboudreau, tjclancy, tk_fhd_aui, valeriaricch, vikasing, viorel, wrafacho, yeradis, yguzzi, zn_cn_2 |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | Windows Vista | ||
URL: | http://statistics.netbeans.org/exceptions/detail.do?id=11804 | ||
Issue Type: | DEFECT | Exception Reporter: | 11804 |
Bug Depends on: | 180259 | ||
Bug Blocks: | |||
Attachments: |
stacktrace
stacktrace messages.log files from Ron Craig |
Description
spungey
2009-02-24 18:20:15 UTC
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). |