[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.
//Peter
>
> 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
------------------------------------------------------------