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 # : 5.0 beta ] [ JDK VERSION : 1.4.2_xx ] The following exception is thrown if a path in a: //server/directory is used: java.lang.IllegalArgumentException: URI has an authority component [file://10.2.6.13/jboss/server/some_configuration/lib/javax.servlet.jar] at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:48) at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:218) at org.openide.filesystems.FileUtil.isArchiveFile(FileUtil.java:1360) at org.netbeans.modules.java.project.JavaAntLogger.getCurrentSourceRootsForClasspath(JavaAntLogger.java:275) at org.netbeans.modules.java.project.JavaAntLogger.messageLogged(JavaAntLogger.java:183) at org.apache.tools.ant.module.bridge.impl.NbBuildLogger.messageLogged(NbBuildLogger.java:509) at org.apache.tools.ant.Project.fireMessageLoggedEvent(Project.java:2009) at org.apache.tools.ant.Project.fireMessageLogged(Project.java:2058) at org.apache.tools.ant.Project.log(Project.java:367) at org.apache.tools.ant.Task.log(Task.java:346) at org.apache.tools.ant.taskdefs.LogOutputStream.processLine(LogOutputStream.java:129) at org.apache.tools.ant.taskdefs.LogOutputStream.processLine(LogOutputStream.java:120) at org.apache.tools.ant.taskdefs.LogOutputStream.processBuffer(LogOutputStream.java:110) at org.apache.tools.ant.taskdefs.LogOutputStream.write(LogOutputStream.java:88) at org.apache.tools.ant.taskdefs.LogOutputStream.write(LogOutputStream.java:172) at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:91) [catch] at java.lang.Thread.run(Thread.java:534) This _works_ outside NB and this error causes the build to fail inside it. A workaround would be to map all network units involved, but it is not practical if there are many of them (that is the case for me). NB shouldn't cause the build to fail just because it doesn't understand a file reference.
*** This issue has been marked as a duplicate of 46813 ***
I am not sure this is a duplicate of issue 46813 since this error does not happen in NB 4.1 with the same build.xml and same properties file.
Ok, re-opening. Radek, please evaluate.
Its strange that it worked for you on 4.1 but //server/directory as UNC path is not supported since ant projects were introduced and filesystems mounting concept was relinquished. *** This issue has been marked as a duplicate of 46813 ***
> ------- Additional comments from rmatous Wed Oct 5 10:08:17 +0000 2005 ------- > Its strange that it worked for you on 4.1 but //server/directory as UNC path > is not supported since ant projects were introduced and filesystems mounting > concept was relinquished. It has nothing to do with my project source directory or anything similar to this. I am using a free-form project with a hand-written Ant script. In one of the tasks, there is a classpath entry such as this one. The target is logging a stack trace (non-fatal) and then NB Ant Logging Support makes the build abort because of _that_. So, that is the problem: if NB can't understand a stack trace element just because it cannot resolve a file reference it shouldn't prevent the build process from working.
/cvs/openide/fs/src/org/openide/filesystems/FileUtil.java,v <-- FileUtil.java new revision: 1.9; previous revision: 1.8
This fix looks wrong to me for two reasons. 1. URLMapper.findFileObject is not declared to throw IAE, nor is the abstract method getFileObjects permitted to throw IAE. Therefore FileUtil should not have to catch IAE here (nor should any other client). 2. From what I see of MasterURLMapper.getFileObjects, it *doesn't* throw IAE to its caller. It catches any IAE (ultimately caused by a bug in the JDK's handling of file: URIs) and notifies it in ErrorManager. If I am correct, #2 means that the fix that was applied didn't actually change the behavior at all. Rather, MURLM.gFO should be changed to either quietly ignore IAE's from new File(URI) - since we know that the JDK's handling is buggy anyway - or print them as a simple warning to console (i.e. log w/ WARNING level). Certainly it is not reasonable to use notify(Throwable) with default EXCEPTION level, which can open a GUI dialog. (I don't know why such a call would halt an Ant build but it would be ugly even if it didn't.)
Oops, Jesse is right => rollbacked fix /cvs/openide/fs/src/org/openide/filesystems/FileUtil.java,v <-- FileUtil.java new revision: 1.10; previous revision: 1.9 P3 for me.
This should be P2 if it actually halts the Ant build (rather than just printing a stack trace).
Created attachment 25960 [details] tried to reproduce - snip of log
I strived to find out how is it possible that ErrMan.notify() in MasterUrlMapper can halt the Ant build. Seems to me that dumpstack reported in this issue (pointing to code in MasterURLMapper) doesn;t need to be unavoidebly the real cause. MasterUrlMapper seems not to be the only code that doesn't workaround this JDK bug. E.g.(see attachment) from UpdateTrackingFileOwnerQuery is thrown IAE that is catched in RequestProcessor.doNotify and notified with severity ErrorManager.EXCEPTIN this or similar problem stops probably ant task and not code in MasterURLMapper which is probably only loged. There is obvious that fixing NB code to accept UNC path on Windows doesn't mean just fix MasterFS but JDK workarounds will spread all over the code.
Well clearly if new File(URI) is broken for UNC paths then we need to make o.o.util.Utilities.toURI(File) and .toFile(URI), planning to deprecate the methods when our minimum required JDK is fixed to handle UNC correctly.
Any chance this could be fixed before HR?
Too late for NB5.0, please reevaluate.
Reassigning to new module owner jskrivanek.
JDK 1.5 bug has been workarounded in NB6.5 together with implementation of issue 46813.