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