[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:


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

Poor an lonesome cowboy ...

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.

Yes, i have discussed that with Konrad (he added the System.set() stuff),
a little synchronize would help.

Your proposal of a central factory class hiding all those things is
certainly a good idea, could you please go this way?

thanks,

Marcel


//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