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.

Bug 20907 - JARFILESYSTEM: when two .jars with the same name are mounted, the second one replaces the first
Summary: JARFILESYSTEM: when two .jars with the same name are mounted, the second one ...
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P1 blocker (vote)
Assignee: David Strupl
URL:
Keywords:
Depends on:
Blocks: 20970
  Show dependency tree
 
Reported: 2002-02-26 22:30 UTC by Peter W Carlson
Modified: 2008-12-23 13:47 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
First (naive) patch (703 bytes, patch)
2002-03-01 09:01 UTC, David Strupl 		Details | Diff
Hotfix patch for release33 branch (733 bytes, patch)
2002-03-01 15:36 UTC, David Strupl 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter W Carlson 2002-02-26 22:30:21 UTC 
Steps to reproduce:
create two different .jar files (same name but different contents)
mount the first and then look at the mounted file and see that the contents are 
correct.
mount the second one.  you will see it briefly appear and then disappear.  When 
you check the contents of the one remaining mounted .jar you will see that it 
is the second one that was mounted.
Comment 1 _ ttran 2002-02-27 08:40:30 UTC 
How can you have two .jars with the same name but different contents
at the same time?  Do you mean they have the same filename but live in
different directories?
Comment 2 rmatous 2002-02-27 09:16:27 UTC 
Aware of the implementation I can hardly imagine described behaviour.
Perhaps conflict of system names in Repository. But jars with the same
name must have different path, which is currently part of system name.

Evaluation in Orion ea,NB 3.3.1 and in last trunk version:
Verified that two different jars with the same name can be added in
Repository and all children are corectly presented. I did  not find
any problem. That`s why marked as WORKSFORME.
Comment 3 _ hlu 2002-02-27 23:09:17 UTC 
To reproduce:
Mount a web module with a jar file under its WEB-INF/lib, the jar 
files under WEB-INF/lib will be mounted automatically by ide.
Mount a directory which has a somename jar file.
right click the jar file and click "Mount JAR".
The second jar file will replace the first mounted jar file. It can 
be seen from jar property.
Also see bug 20970.
Comment 4 rmatous 2002-02-28 13:08:06 UTC 
Problem is in automount support. Reproducible also in dev build.
How I reproduced this bug: I had two web modules. Both of them
contained in WEB-INF/lib the same jars. 

1. I mounted first web module => all jars in web1/WEB-INF/lib were
mounted as JarFileSystems. 

2.Then I mounted the second one . Again all jars in web2/WEB-INF/lib
were mounted as JarFileSystems but all jars in web1/WEB-INF/lib were
unmounted as JarFileSystems. See stacktraces here:
added fs.getSystemName: E:\temp\web2\WEB-INF\lib\js.jar
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:993)
        at
org.openide.filesystems.Repository.addFileSystem(Repository.java:160)
        at
org.netbeans.modules.web.context.WebContextObject$3.run(WebContextObject.java:362)
        at org.openide.util.Task.run(Task.java:152)
        at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)

and :

removed fs.getSystemName: E:\temp\web1\WEB-INF\lib\js.jar
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:993)
        at
org.openide.filesystems.Repository.removeFileSystem(Repository.java:209)
        at
org.netbeans.core.AutomountSupport.cycleFileSystems(AutomountSupport.java:586)
        at
org.netbeans.core.AutomountSupport.updateFileSystems(AutomountSupport.java:486)
        at
org.netbeans.core.AutomountSupport.taskFinished(AutomountSupport.java:155)
        at org.openide.util.Task.notifyFinished(Task.java:123)
        at
org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:586)
        at
org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45)
        at
org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456)
        at org.openide.util.Task.run(Task.java:152)
        at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)
Comment 5 David Strupl 2002-03-01 08:04:27 UTC 
The problem is in the fact that automount support uses the same name
for representing the second jar file setting. Working on a solution.
Comment 6 David Strupl 2002-03-01 09:01:17 UTC 
Created attachment 4883 [details]
First (naive) patch
Comment 7 David Strupl 2002-03-01 09:06:11 UTC 
The first patch solving the issue by not using getDisplayName() at
all. Please note that although the name of the file is ugly the user
will not see it anywhere in the NetBeans. The only problem it may
cause is that the setting file cannot be edited by hand (because you
won't know which file to edit).
Comment 8 Jaroslav Tulach 2002-03-01 09:36:06 UTC 
The patch is suitable as hotfix. For 3.4 please work on something
better.
Comment 9 David Strupl 2002-03-01 15:36:25 UTC 
Created attachment 4902 [details]
Hotfix patch for release33 branch
Comment 10 David Strupl 2002-03-01 15:37:30 UTC 
Could anyone (besides me) test my patch against release33 and
specifically when using the web module? Thanks.
Comment 11 David Strupl 2002-03-01 16:01:09 UTC 
Fixed in trunk
AutoMountSupport 1.42.
MountIterator 1.18.
Comment 12 David Strupl 2002-03-01 17:27:18 UTC 
Hotfix applied to branches orion_ea and orion_fcs.
Comment 13 Marian Mirilovic 2002-03-04 16:07:23 UTC 
verified in [FFJ4.0_EA](020301_1EE) && [nb_dev](20020304)
Comment 14 Marian Mirilovic 2002-04-02 09:34:28 UTC 
verified in [orion_CE](20020401) && [jdk1.3.1](03)/[jdk1.4](fcs)
Comment 15 Quality Engineering 2003-07-01 16:27:20 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.