Re: [xmlblaster] XML parser

[Peter Antman <pra at mint.se>]

Hi, I would like to have an OK on the following changes:

1. Adding a JAXPFactory to utils where we can get new JAXP factorories
   by name.

2. Adding methods to global:

getSAXParserFactory
getDocumentBuilderFactory
getTransformerFactory

This will
a) Load either javax.xml.parsers.SAXParserFactory (or equiv) if
available in glob or use the crimson default.
b) Save an instance in glob and return that on future accesses.

3. Fix XmlKey to fo XmlToDom a glob and fix XmlProcessor to take a glob
   and to use an XMLProcessorImpl that uses glob to get the factory. 

Is this OK?

//Peter

On 17 Sep, Till: xmlblaster at server.xmlBlaster.org wrote:
> On 17 Sep, Marcel Ruff wrote:
>> 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
>>>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?
>>>
>> 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.
> 
> I totaly agree, I will start the factory path tough. Testing is so
> timeconsuming...
> 
> //Peter
> 
>  
>>>
>>>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.
>>>
>> Yes!
>> 
>>>
>>>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.
>> 
>> cu
>> Marcel
>> 
>>>
>>>//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	Chief Systems Architect, Business Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se	WWW: http://www.backsource.org
Email: pra at tim.se	 
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 
------------------------------------------------------------