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

Re: [xmlblaster] XML parser

On 16 Sep, Till: xmlblaster at server.xmlBlaster.org 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
> 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?

Seems to becomming an endless discussion with myself ;-). Looking into
the xerces 2.x line it looks like it could work: but what happend if
another thread - that should not be affected by XmlBlaster using crimson
- loads a parser during the time the factory is creating the factory?
Could that not lead to all sorts of funny stuff.

> 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