[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] XML parser

pra at mint.se wrote:

On 16 Sep, Till: xmlblaster at server.xmlBlaster.org wrote:

Looking into my old code again a see that I have had to hardcode the
crimson parser into several classes. I really think this needs a

From my experience I would say this:

1. It does not help to do: System.setProperty("javax.xml.parsers.DocumentBuilderFactory","org.apache.crimson.jaxp.DocumentBuilderFactoryImpl");


The spec (and xerces impl) is done in such a way that it is not possible
to bypass this in other classloader/locally. I cant belive the tricks in
SaxHandlerBase really works. I have tried that before without success.

Or have I missed something? Why then is xerces loaded in my setup?

I believe it works, i think we have tested it.

2. The nonportable code is possible to write portable. I have portable code from other projects to do toString, merge and replace. But I think the portable code will be a lot slower (using XSL for serialization and the DOM api for the other).

It would be nice to have this option - if crimson is active the old code
applies (probably by reflection to allow compiling), otherwise your portable code
is active. This way we never have a nogo, just a slower xmlBlaster.

3. Since at least the string org.apache.crimson.jaxp.SAXParserFactoryImpl is hardcoded in several places (and it is actually today not possible to use XmlBlaster without crimson) I think we could as well hardcode crimson. Like this for example: SAXParserFactory spf = new org.apache.crimson.jaxp.SAXParserFactoryImpl();

  It should probably even be done in a wrapper class: JAXPFactory,
  where we could get the SAXParserFactory, DocumentBuilderFactory and
  TransformerFactory. Here we could hardcode crimson or load


Any thoughts on this? It would be really nice to get a solution that works in JBoss, even when xerces is the parser used.

Definitely yes, this problem arises from time to time again.



may I be a little dogy.

As far as I can see the XML parser loading in XmlBlaster is done in
XmlProcessor where com.jclark.xsl.dom.SunXMLProcessorImpl(). It uses the
com.sun.xml.parser.Parser to get at the parser. If I get it correct this
however uses the JAXP API to get its real parser: i.e if this is set to
xerces, or if xerces had the chance to load before crimson, xerces will
be the parser used through SunXMLProcessorImpl. Since XmlBlaster uses
crimson specific stuff to do important stuff this is not so good. I once
wrote a helper for this:

public class CrimsonProcessorImpl extends com.jclark.xsl.dom.XMLProcessorImpl  {

DocumentBuilderFactory dbf = null;
public CrimsonProcessorImpl() {
dbf = new org.apache.crimson.jaxp.DocumentBuilderFactoryImpl();
public org.w3c.dom.Document load(org.xml.sax.InputSource input)
throws java.io.IOException, org.xml.sax.SAXException {
DocumentBuilder db = null;
try {
db = dbf.newDocumentBuilder ();
}catch(javax.xml.parsers.ParserConfigurationException ex) {
throw new org.xml.sax.SAXException("Could not setup builder", ex);
return db.parse(input);

   public org.w3c.dom.Element getElementById(org.w3c.dom.Document doc, String str) {
	return null;

And used that from XmlProcessor. But I guess mine is not as effective as
yours. Any ideas on how to solve this would be great.