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.
Build: NetBeans IDE Dev (Build 080815) VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc-b28 OS: Windows Vista, 6.0, x86 User Comments: Expanding the contents of a library jar (avalon-framework-4.2.0.jar) inside a free-form web project Stacktrace: java.lang.IllegalArgumentException: Duplicate in children list: LICENSE.txt at org.openide.filesystems.Ordering.getOrder(Ordering.java:97) at org.openide.filesystems.FileUtil.getOrder(FileUtil.java:1802) at org.openide.loaders.FolderChildren$1R.run(FolderChildren.java:161) at org.openide.loaders.FolderChildren.refreshChildren(FolderChildren.java:184) at org.openide.loaders.FolderChildren.addNotify(FolderChildren.java:269) at org.openide.nodes.Children.callAddNotify(Children.java:525)
Created attachment 67625 [details] stacktrace
This issue has already 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=92496
I cannot reproduce it in recent builds.
same problem here. perhaps it's a linux thing.
i think it may have to do with having the same classes in 2 different jar files. for example, i have 'tasks.jar' and 'tasks-with-dependencies.jar'. the i can explore every folder except "com.thompsonlogic.tasks" in the latter file. this folder contains the exact same classes as the same package in 'tasks.jar'. long story short: this is just a wild guess, but i think the items in the tree are being cached by holding them in a map keyed by their path name. the error occurs because multiple items have the same path name. the key should be jar file name + path name.
Product Version: NetBeans IDE Dev (Build 200809290201) Java: 1.6.0_10-rc2; Java HotSpot(TM) Client VM 11.0-b15 System: Linux version 2.6.18-92.1.13.el5 running on i386; UTF-8; en_US (nb) Userdir: /rhome/users/athompson/.netbeans/dev
I changed exception message to print all children. But I am not able to reproduce the problem even with two jars with the same content. If you see the exception again in newer builds, please, attach a new stack trace with list of children. Reassigning to 'nodes' if someone have an idea what could be wrong.
Original report could be caused by error in implementation of Node.setChildren() (which was fixed recently). However, last exception report seems ok from Nodes point of view
I suspect a bug (race condition perhaps?) in FolderChildren, but it is hard to tell without a test case to reproduce.
Integrated into 'main-golden', will be available in build *200809301401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d5ba8c25f5b8 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #144166 - Print children in failure reports.
i don't see any logging in the 9/30 1401 build. i'll try with the next build when it's available.
There should be just more detailed message in IllegalArgumentException.
Created attachment 71018 [details] stack trace
'tables.sql' and 'triggers.sql' are in the root of each jar file.
sorry, false alarm. the problem isn't that there are files with the same name in multiple jars. the problem is that the maven assembly plugin is adding is adding duplicate files to the jar; it has nothing to do with netbeans. on the other hand, if it's technically possible to add duplicate files to a jar you might want to handle it, even if it makes no sense.
Sounds like a bug rather for JarFileSystem. If it is possible for a ZIP to contain duplicate entries, JFS should handle this gracefully, perhaps printing a warning (or throwing IOException somewhere?) but not passing on the problem to higher layers like DataFolder.
I guess Jesse is right, this cannot be a bug in FolderChildren as they do only: final FileObject[] arr = folder.getPrimaryFile().getChildren(); FolderOrder order = FolderOrder.findFor(folder.getPrimaryFile()); Arrays.sort(arr, order); So the filesystem must have returned duplicated entry.
If it is possible for a ZIP to contain duplicate entries and a concrete jar contains duplicate entries, it is correct that filesystem returns all entries including duplicate ones. IMO, it is up to FolderChildren to handle such situation.
It is a bug in JFS. All clients of Filesystems naturally expect that there will be at most one child FileObject with a given name (i.e. nameExt) in a given folder at a given time. Breaking this invariant would cause mayhem. The possibility of such a situation in ZIP files seems to be an oversight (you could not unpack such a ZIP all at once!), arguably a bug in the code that writes the ZIP file; clearly there is a bug in Maven for attempting to write the same file twice.
OK, I will add some warning to JarFileSystem that a jar contains duplicate entries.
Fixed. If duplicate entries found in jar, it is immediately reported to the user. http://hg.netbeans.org/core-main/rev/4ae1db6577e0
Integrated into 'main-golden', will be available in build *200810160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4ae1db6577e0 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #144166 - If duplicate entries found in jar, it is immediately reported to the user.
*** Issue 151450 has been marked as a duplicate of this issue. ***
*** Issue 151452 has been marked as a duplicate of this issue. ***
*** Issue 152682 has been marked as a duplicate of this issue. ***
After reading the source of the fix, I think it is not the correct way to handle this. Completely invalidating the entire JAR file causes a regression bug that prevents users that could work with 6.1 to work with 6.5 and above. I don't think it is necessarily Maven that is causing the problem. I think it is the creator of the JAR file. And hence that is something you cannot fix if you don't deal with it at this level. So, I am reopening the issue since I don't think the fix is helpful at all. I think the fix should remove the 2nd entry and then signal the user it found a duplicate entry with a suggestion to contact the author of the JAR file and then still return the cache.
I don't think your suggestion makes a difference. Once a jar is invalid (contains duplicate entries) it should be fixed. Duplicate entry is printed in error message, so why to show content of malformed jar. I don't see any use case of it.
*** Issue 153398 has been marked as a duplicate of this issue. ***
*** Issue 153776 has been marked as a duplicate of this issue. ***
*** Issue 160761 has been marked as a duplicate of this issue. ***
I agree with vkraemer and mriem that more graceful handling would be in order. Sometimes a JAR with duplicate entries appears in a Maven repo, etc. It is generally perfectly usable if you simply ignore the extra entries and pick the first one you find of a given name. Logging the fact that the JAR has this problem, e.g. a one-line WARNING to log file, would be appropriate, in case the user has some chance to contact the creator of the JAR and get the root problem fixed.
It seems like the fix for this penalizes our users for the mistake someone else made (the person that created the broken jar). Since other tools (like the jar command) do not choke on the invalid jar, maybe we should not either. The behavior of 6.5 is better than the behavior of 6.7, so I would consider the current behavior regressive.
OK, if jar contains duplicate entries, I print warning and ignore them. http://hg.netbeans.org/core-main/rev/d2b8959c277b
Integrated into 'main-golden', will be available in build *200903241535* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d2b8959c277b User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #144166 - If jar contains duplicate entries, log warning and ignore them.
*** Issue 159724 has been marked as a duplicate of this issue. ***
*** Issue 161289 has been marked as a duplicate of this issue. ***