[EMAIL PROTECTED] wrote:
>On 16 Sep, Till: [EMAIL PROTECTED] 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.
>
>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
>>
>>
>
>
>
