Re: [xmlblaster] XML parser

[pra at mint.se]

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
solution.

>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");

System.setProperty("javax.xml.parsers.SAXParserFactory","org.apache.crimson.jaxp.SAXParserFactoryImpl");

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?

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).

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
   dynamically.

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

//Peter

> Hi,
> 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.
> 
> //Peter

-- 
------------------------------------------------------------
Peter Antman             Technology in Media, Box 34105 100 26 Stockholm
Systems Architect        WWW: http://www.tim.se
Email: pra at tim.se        WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 
------------------------------------------------------------