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.
Summary: | Unable to execute ant tasks | ||
---|---|---|---|
Product: | platform | Reporter: | Chris Webster <cwebster> |
Component: | -- Other -- | Assignee: | _ pkuzel <pkuzel> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | issues, rmatous, ttran |
Priority: | P1 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Please review attached patch (we need to get rid of RememberingReader). |
Description
Chris Webster
2001-10-11 21:20:29 UTC
Yes, I just noticed this myself [dev oct 11], it seems to have started very recently. I think it is a core problem; agree with P1 assessment. Most of the time Ant scripts are not being recognized for me, only as XML. E.g. run a build with a clean userdir and just the Ant module, and mount ..../nb_all/jarpackager/. The build.xml is not recognized. Sometimes it still works. Some investigation showed that Lookup has the MIMEResolver from the Ant module's XML present; but the MIME type of the file is given as text/xml. So I assume something is wrong in the MIME resolution system (not sure which part). A note for Chris: while cumbersome, you are not prevented from reloading modules because of this. If you have your test target split into one half that builds the module, and one that depends on the first and just runs <nbinstaller> (see apisupport or ant build scripts for examples), then you can from the command line run the first half; then under Tools | Options turn the module off and back on (assuming it is already installed in test mode from that location, else Modules | New | Module for Testing... to begin). A bit more of a pain, but still far faster than restarting the IDE or similar things. And testing using the JAR Packager should be unaffected. You probably made your custom build, because it's not reproducible in "oficial" 200110110100 build. But of course I can reproduce it in todays build dev-200110120100. Ant module is therefore completly unusable. this has something to do with Crimson. If you delete crimson.jar from lib/ext, the IDE will fall back to Xerces, then everything works fine. Yesterday we discovered a defect in our XMLFileSystem exposed by Crimson. Not sure if this is a similar case or a bug in Crimson. Going to investigate it. I can confirm that this is an XML parser issue. If you insert the following line into the beginning of org.netbeans.core.filesystems.MIMEResolverImplTest.setup(): org.netbeans.core.xml.NbSAXParserFactoryImpl.install(); then the tests fail: testDeclarativeMIME(org.netbeans.core.filesystems.MIMEResolverImplTest)junit.framework.AssertionFailedError: ns rule failureroot/ns.xml => null testParseFailures(org.netbeans.core.filesystems.MIMEResolverImplTest)junit.framework.AssertionFailedError: build1.xml recognized as Ant script expected:<text/x-ant+xml> but was:<null> MIME resolution process use a parser instance per process. Just hope that there can be more Crimson intances alive at same time. Problem lies somewhere in file sniffing as templates (smells) are parsed correctly. So the bug is in startElement() callback handling: <cite from="SAX 2.0 specs"> the Namespace URI and local name are required when the namespaces property is true (the default), and are optional when the namespaces property is false (if one is specified, both must be); the qualified name is required when the namespace-prefixes property is true, and is optional when the namespace-prefixes property is false (the default). </cite> If parser does not support optionals it must pass "" as parameter. Xerces passes null. The code was written against Xerces. I have updated code so it is written right along the specs but is also relax Xerces bug. I have also introduced RememberingReader because otherwise I got very often shallowed (I expect that reason is that file starts with some WS or so that is why leading <?xml is interpresed as illegal PI) exception: org.xml.sax.SAXParseException: Illegal processing instruction name, or missing whitespace. at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3170) at org.apache.crimson.parser.Parser2.maybePI(Parser2.java:987) at org.apache.crimson.parser.Parser2.maybeMisc(Parser2.java:1092) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:487) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442) at org.netbeans.core.filesystems.DefaultParser.parse(DefaultParser.java:108) at org.netbeans.core.filesystems.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:234) at org.netbeans.core.filesystems.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:55) at org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.resolve(MIMEResolverImpl.java:392) at org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.access$000(MIMEResolverImpl.java:375) at org.netbeans.core.filesystems.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:107) at org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:138) at org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:127) at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:51) at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:543) at org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:147) at org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:430) at org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:430) at org.openide.loaders.ExtensionList.isRegistered(ExtensionList.java:130) at org.openide.loaders.UniFileLoader.findPrimaryFile(UniFileLoader.java:62) at org.apache.tools.ant.module.loader.AntProjectDataLoader.findPrimaryFile(AntProjectDataLoader.java:111) at org.openide.loaders.MultiFileLoader.findPrimaryFileImpl(MultiFileLoader.java:232) at org.openide.loaders.MultiFileLoader.handleFindDataObject(MultiFileLoader.java:65) at org.openide.loaders.DataLoader.findDataObject(DataLoader.java:221) at org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:362) at org.openide.loaders.FolderList.createBoth(FolderList.java:569) at org.openide.loaders.FolderList.getObjects(FolderList.java:390) at org.openide.loaders.FolderList.access$200(FolderList.java:42) at org.openide.loaders.FolderList$ListTask.run(FolderList.java:735) at org.openide.util.Task.run(Task.java:152) at org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:611) Not RESOLVED yet as there is a problem with above exception if not using Remembering reader. Created attachment 2986 [details]
Please review attached patch (we need to get rid of RememberingReader).
Please use ErrorManager thruout when you have the time... What does the exception here really mean? Note that it is illegal for an XML file to have the <?xml?> not at the very beginning of the file (if there is one), so the parser *should* fail and reject the file if this is not true. Is there a reason to comment out the setting of the feature external-parameter-entities=false? Further investigation of thrown exception using modified Crimson parser showed that input stream sometimes contains multiple copies of original file content. It means that in the middle of file is present XML prolog... Anyway this particular bug is FIXED. DefaultParser.java new revision: 1.7 XMLMIMEComponent.java new revision: 1.6 I'll provide a copy of modified Crimson to Radek so he can investigate why the input stream returns such content. Setting unsupported feature may break parser internal state. In some cases I intentionaly do not use ErrorManager. I think you mean the code under: //this should be commented out. But at this case there should be really no error reporting because the error can be reported for any broken (even user's) XML documents. If I use ErrorManager there then I would get tons of bugs reports. So I rather decided to shallow the exception. But, OK I am going to try to do not shallow the exception using ErrorManager.INFORMATIONAL level. "Setting unsupported feature may break parser internal state." - really? Wouldn't that be a bug in the parser (should just throw SAXException)? Have you reported it if so? Re. ErrorManager--mainly I meant not to use System.err.println when ErrorManager will do. Whether or not to use anything--I'm not sure. I agree that it is odd to log exceptions for user problems. It could be useful to help users figure out why their file is not recognized correctly. On the other hand, running an XML validator is not very difficult and ought to catch problems in normal cases (unless someone's parser is too strict or too forgiving). Thanks for the quick fix... *** Issue 16565 has been marked as a duplicate of this issue. *** verified Resolved for 3.4.x or earlier, no new info since then -> closing. |