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.
It should not require the Xerces XML parser, though it may continue to use the serializers package. See AntProjectSupport. Coding should be trivial; mostly testing and sanity-checking that there are no problems with Xerces 2.0.0. Basically DOMParser is in use only to turn off the deferred node expansion feature in an older version of Xerces, which was badly buggy. I think the bug is now gone, so using JAXP to get the parser and not setting any features will probably work. Pay close attention to the DOM mutation events. In my experience, Xerces 1 was rather buggy about which events it would send, and the listeners needed to be tuned to work around these bugs. Use -J-Dorg.apache.tools.ant.module=0 to find out exactly what is going on. Try modifications text -> Explorer and Explorer -> text and sanity-check.
OK, I think I have a working patch here. It makes ant & apisupport modules depend on a new autoload, org.apache.xerces.v13 (stored in core/xerces13/ in CVS), which just wraps Xerces 1.3.0. I tried it with JDK 1.3 and 1.4, and tried (1) leaving 1.3.0 on classpath as it is now, (2) removing Xerces from the classpath, (3) including Xerces 2.0.0 beta 2 on the classpath; no troubles in any case. Anyone see any problems with this approach? Note that the patch assumes nbextra/core/release/lib/ext/xerces.jar is 1.3.0, so as not to have to move around extra binaries. If and when you (pkuzel) commit the patch to upgrade XML parsers, this should be moved to nbextra/core/xerces13/release/modules/autoload/ext/xerces-1.3.0.jar and core/xerces13/build.xml updated accordingly.
Created attachment 4889 [details] Proposed patch (modified files)
Created attachment 4890 [details] Proposed patch (ZIP of added files)
This bug has survived 13904 fix without uncovering it, but it is still timed bomb.
HA! I admit I forgot about this issue. I'm going to look at it.
Just discussed with David and suggested to use R/P dependencies. Ant would require org.apache.xerces.2.0.1 token that would be provided by core and the Xerces library provided by Ant. Once core discontinues providing the token then Ant module will seamlessly switch to its own library/provider. Does it make sence?
Still needs org.apache.xml.serialize.* package directly accessed. I think use of JAXP otherwise would be OK; there is no need to specifically ask for Xerces 2.x *features*, it is a matter of ensuring that the supplied parser does not have the critical bugs that I saw in some 1.x releases (which may have been fixed in some 1.x release).
Then require token org.apache.xml.serialize.2.0.1?
Jesse, if understand this issue correctly what I should do is: 1.) add into nbextra core/xerces13/release/modules/autoload/ext/xerces-1.3.0.jar 2.) create new autoload module org.apache.xerces.v13 3.) change ant module to depend on this new module and not directly on xerces What is not clear to me is where this module should be put? As submodule of core? Or top level module? Or XML sub module? From your patch it looks that is should be core submodule. I talked with Hrebejk and he disagree that it should be under core.
Petr - requiring some token for the serializer package makes no sense; you need to depend on it at compile time. That means use of Class-Path or a regular module dependency. David - I think we should try to use Xerces 2.x first, and only fall back to using 1.3.x if 2.x will not work. If we do need to make a 1.3.x autoload module, I guess it could go as a submodule of the xml project? Don't know. It really doesn't make any difference except psychologically to the module owners.
OK, I tried it with new xerces 2.0 and it seems to work. But only time and nbusers will show whether it really works or not. If everything is OK with xerces 2.0, then we don't need to provide autoload 1.3 xerces module, right? That is good. But with each update of xerces we potentially can have some problems, rigth? I agree that location of the module is just psychological problem. :-) So, what now? Should I close this issue with LATER resolution, what literally means that till some problem appears we don't need to create autoload module? Or do you think I should do create autoload module?
May be I have not understood P/R properly. I originaly thought that it would add provider resources to requestor classloader search path. Regarding library hosting we think about establishing xml/lib subproject for this purpose. Even better we would introduce top level "libraries" project holding all third party libraries and its wrapper modules. It would improve library sharing among modules.
To David: OK, if everything is working as things are, I guess I would close as REMIND. I don't know of anything wrong with Xerces 2.0 that would require us to use 1.3. But please read the comments in issue #20270 first - when I tried it for apisupport, there were big problems because I got Crimson as the DOM parser, which is not featureful enough to be used. Has this changed? Is it now sure that an adequate DOM parser will be served from JAXP? To Petr: no, part of the *purpose* of P/R dependencies is that they do not add to the effective classpath. So you can depend directly on an API/SPI, and require that some unknown provider be present, without needing to know the provider's identity, nor have that provider contaminate your classpath (since you should have no compile-time dependencies on the provider, only the API/SPI).
OK. I talked with Petr K. and we agreed that if some problem appears we will create autoload module xerces_version_X_X under XML module and ant will depend on this concrete version of the xerces.
*** Issue 19682 has been marked as a duplicate of this issue. ***
I think that this issue should be fixed since ant module shouldn't depend on particular XML parser to avoid future problems when IDE will use next version of XML parser. It already happened when using ant from nb 3.3.2 in nb3.4 where ant script cannot be parsed.
Target milestone was changed from '3.4' to TBD.
I'm changing target milestone to 4.0, because I don't dare to do this change for NB3.4. I filed issue 25868 for XML module to provide NB autoload modules wrapping different versions of xerces. Once the issue is implemented the Ant will depend on this module. This seems to me as the best solution.
I would like to ask which version of Xerces do you want to depend on? 1) Any Xerces2 (org.netbeans.libs.xerces) (Always last stable release -> just one xerces module will be created.) 2) Xerces 2.0.x (org.netbeans.libs.xerces20x) (Any minor changes/fixes 2.0 release -> module for each major xerces release -- next one will be ...xerces21x.) 3) Xerces 2.0.2 (org.netbeans.libs.xerces202) (Concrete release -> module for every xerces release -- xerces203, xerces204, ...) Probably, it does not make sense to request 3) -- a lot of modules should be provided if requested. If you just depend on any xerces implementation then 1) is the best way. Let me know, what you need. Thanks.
In near future I will need just one for the version of Xercer currently used in NB3.4. The Ant module will depend on it and so if IDE's parser will change in next version it will not affect the Ant.
I understand Ant's request very well, but I asked about it because once I create xerces module I should not remove it because some other module could depend on it. I think that for each new xerces release there will be request for upgrade and in the case 3) it means new module and I am worry about tens of xerces modules. Probably the case 2) is the best because "you depend on concrete xerces implementation (e.g. 2.0) and you tolerate minor release updates (e.g. from 2.0.2 to 2.0.99)". If you do not depend on xerces API then the case 1) is the best but it is not your case I think.
yes, 2) looks like what I need
Two alternate suggestions: 1. Do as apisupport currently does, successfully I think: depend only on the Xerces serializer package, which is entirely independent of the parser. When getting a parser, ask JAXP, and if it gives you a parser supporting DOM Events, great. If not, and using post-3.4 (IDE/1 > 3.3 I think - apisupport does not yet do this) ask Lookup for all DocumentBuilderFactory's available, and select one which supports DOM Events. If you need to work with APIs pre-3.3 (META-INF/services/*), then if JAXP fails to give you one, do as apisupport does now and try to load the Xerces impl of DBF using Class.forName. Thus no dependency on particular Xerces version other than that (1) Xerces ser library is available, which IMHO could be made into a separate autoload module anyway, (2) DOM Events is supported by *somebody*. 2. Do as you are talking about, but using dep style #1, i.e. no particular dep on specific Xerces features. I think this is the case, so long as the autoload module makes it possible to get a DBF reliably from the module (for example, using Lookup). BTW Petr/Libor: now that Lookup should be supplying all DBFs, SAXParserFactory's, and TransformerFactory's available in the system, I suggest that XMLUtil be given a few new methods to search through factories looking for impls that supply given abstract capabilities: support for DOM Events would be one example. Furthermore, autoload modules providing such XML-related factories could be marked with OpenIDE-Module-Provides, so that client modules could just declare e.g.: OpenIDE-Module-Requires: javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.DocumentBuilderFactory.WITH_DOM_EVENTS, javax.xml.parsers.DocumentBuilderFactory.WITH_DOM_RANGES .... DocumentBuilderFactory f = XMLUtil.findDocumentBuilderFactory(XMLUtil.WITH_DOM_EVENTS | XMLUtil.WITH_DOM_RANGES); // f should be non-null because we depended on these features Look attractive?
I looked as this task and would prefer to leave it on Dusan.
In trunk, still looks up Xerces' DocumentBuilderFactoryImpl by Class.forName (so as to guarantee DOM Event support), and uses serializers package.