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.
Using kit 010803 This problem affects Webmodules and Jar Packager. See issue 14088 and BugTraq bug 4486894. Jar archives containing jar-jarContent files or WAR archives containing jar-jarContent files are affected. Here are the steps to reproduce (same as the second set of steps for issue 14088) Every file/directory must be created fresh using FFJ (directories are created at the root) Also, fresh installation must be used (new ffjuser30 directory) These steps have been verified on Windows 2000. Nearly identical steps were followed on Win NT. First see attached word document for filesystem structure setup in the Explorer. 1) Unmount sampledir filesystem (no filesystems should be mounted to begin) 2) Create new fs1 at root (c:\fs1) 3) Create new pkg1 under fs1 4) Create new class in pkg1 named MyClass 5) Compile pkg1 6) Create new jarContent, myjar1 containing pkg1 7) Compile myjar1 8) Create new fs2 at root (c:\fs2) 9) Create pkg2 under fs2 10) Copy myjar1 to pkg2 11) Create new jarContent myjar2 containing pkg2 12) For myjar2, set File Filter to all files 13) Compile myjar2 14) Create new jarContent myjar11 in fs1 containing pkg1 and compile myjar11 15) Delete myjar1 from pkg2 16) Copy myjar11 to pkg2 17) Compile myjar2 18) Create new jarContent myjar111 in fs1 containing pkg1 and compile myjar111 19) Delete myjar11 from pkg2 20) Copy myjar111 to pkg2 21) Compile myjar2 22) From a command prompt, type: jar tvf myjar2.jar Result: myjar111.jar is missing from myjar2 archive: G:\fs2>jar tvf myjar2.jar 2 Fri Aug 03 18:31:02 PDT 2001 META-INF/MANIFEST.MF 1022 Fri Aug 03 18:31:02 PDT 2001 pkg2/myjar111.jarContent
Created attachment 2079 [details] Shows structure of filesystems in the Explorer
This bug may be difficult to reproduce. I recommend to *reboot* the PC first. Also, after compiling myjar2.jar, check it's contents: jar tvf myjar2.jar Do this after steps 13 and 21 It may be required to repeat steps 18-22 using new names for jar content files.
x
Assigning to data systems. I was able to reproduce it on my Solaris, but it's undeterministic. Please reffer to the depending issue for more details and stacktraces provided by Mike. We need evaluation ASAP. Thanks.
When some operation perfomed on DataObject (e.g. compile) creates secondary file another way than throught FileSystems, this file is recognized lazily by FileSystems (check Refresh Time Interval property) and thus the DataObject can have its entries set out-of-date for a while. There is no general solution possible in DataSystems and it is upon the DataObject to either use FileSystems only or to force their refresh after the external creation of secondary file.
I don't understand the previous comment. The file in question (the .jar file in the target directory) is created by MultiDataObject.handleCopy(), which makes standard use of filesystems. Please re-evaulate this issue.
MultiDataObject recognizes all of its files when created/copied. MDO should always be consistent after the copy operation in sense of having all its entries attached before it is returned from DataObject.copy (). I wasn't able to reproduce steps described in this issue, but wrote test in unit/src/org/openide/loaders/MultiDataObjectTest.java which showed described behavior. Since I applied my fix the test started to pass. Please, let me know in case of any troubles. Mike, I remember you to make workaround in JarDataObject.handleCopy for pilsen, is this workaround in trunk as well? We could probably remove it.
The workaround in handleCopy was actually for a different problem with similar symptoms. It was never put in the trunk.
rev#1.54
Reopening as the fix in org/openide/loaders/MultiFileLoader.java,v1.21 causes severe performance problems to all MultiFileLoaders. The possible solution is to reuse existing checkFiles method and call it from MDO.getSecondary() instead of MDO.files(). Also please remove DoubleCheckedLocking from getSecondary It is very visible e.g. in an initial recognition of a folder with more XML files. Leaving as P1 as it significantly slows down recognition of folders with java files, also causes 16071.
Secondary entries of MultiDataObject are created lazily at the time when they are really needed, sorry for the regression. I also tried to reproduce behavior originally described in this issue and #14088, after the fix of issue #16316 I was unable to reproduce described problems, also tests simulating this porblem were not broken by the fix.
OK, it fixed the problem with recognizing editor's xml files, but there is still a problem with recognizing .java files: .java files call secondaryEntries in constructor, which (I think) had the same complexity before(O(N^2)), so no regression, only a problem ;-( I'm veryfing this and I'll try to find a solution for the second problem, possibly filling a new BUG/RFE/TASK...
Resolved for 3.4.x or earlier, no new info since then -> closing.