On 17 Sep, Marcel Ruff wrote:
> 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?
Yea, I will do that. I ams thinkink of ading methods to Global to, to
make the factories available (there is real overhead in having to
recreate them every time).
//Peter
>
> 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
>>>>
>>>>
>>
>>
>>
>
--
------------------------------------------------------------
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
------------------------------------------------------------