Bug 65894 - [50cat] Error in NB's Ant logging support prevents build from completing
[50cat] Error in NB's Ant logging support prevents build from completing
Product: platform
Classification: Unclassified
Component: Filesystems
PC Windows XP
: P3 (vote)
: 6.x
Assigned To: Jiri Skrivanek
Depends on:
  Show dependency treegraph
Reported: 2005-10-04 18:36 UTC by misterm
Modified: 2008-12-22 10:13 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

tried to reproduce - snip of log (2.71 KB, text/plain)
2005-10-14 17:39 UTC, rmatous

Note You need to log in before you can comment on or make changes to this bug.
Description misterm 2005-10-04 18:36:27 UTC
[ BUILD # : 5.0 beta ]
[ JDK VERSION : 1.4.2_xx ]

The following exception is thrown if a path in a:


is used:

java.lang.IllegalArgumentException: URI has an authority component [file://]
	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.
Comment 1 Jan Chalupa 2005-10-04 20:15:36 UTC

*** This issue has been marked as a duplicate of 46813 ***
Comment 2 misterm 2005-10-04 20:35:13 UTC
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.
Comment 3 Jan Chalupa 2005-10-04 20:49:21 UTC
Ok, re-opening. Radek, please evaluate.
Comment 4 rmatous 2005-10-05 11:08:17 UTC
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 ***
Comment 5 misterm 2005-10-05 11:34:46 UTC
> ------- 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 

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.
Comment 6 rmatous 2005-10-05 15:22:14 UTC
/cvs/openide/fs/src/org/openide/filesystems/FileUtil.java,v  <--  FileUtil.java
new revision: 1.9; previous revision: 1.8
Comment 7 Jesse Glick 2005-10-05 23:28:51 UTC
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.)
Comment 8 rmatous 2005-10-07 14:51:16 UTC
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.
Comment 9 Jesse Glick 2005-10-07 21:47:40 UTC
This should be P2 if it actually halts the Ant build (rather than just printing
a stack trace).
Comment 10 rmatous 2005-10-14 17:39:03 UTC
Created attachment 25960 [details]
tried to reproduce - snip of log
Comment 11 rmatous 2005-10-14 18:05:11 UTC
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.
Comment 12 Jesse Glick 2005-10-14 19:12:14 UTC
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.
Comment 13 misterm 2005-12-07 15:20:09 UTC
Any chance this could be fixed before HR?
Comment 14 Marian Mirilovic 2006-01-03 10:51:47 UTC
Too late for NB5.0, please reevaluate.
Comment 15 Antonin Nebuzelsky 2008-04-15 17:20:11 UTC
Reassigning to new module owner jskrivanek.
Comment 16 Jiri Skrivanek 2008-09-03 13:43:27 UTC
JDK 1.5 bug has been workarounded in NB6.5 together with implementation of issue 46813.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo