On Jun 16, 6:19 pm, Kieran Topping <[EMAIL PROTECTED]> wrote:
> Norris Boyd wrote:
> > On Jun 16, 6:16 am, Kieran Topping <[EMAIL PROTECTED]> wrote:
>
> >> I thought I would document some recent experience I've have, trying to
> >> get E4X to work.
> >> Thankfully my efforts ended in success, but I did encounter a few
> >> jar-dependency & xml-parser issues, which took a while to fix - in
> >> particular because googling the exception messages didn't yield much
> >> information. Hopefully this post might address this and save someone
> >> else a bit of time!
>
> >> The results below were generated by running the attached java class
> >> (E4X.java) from the command line, on a 1.5 JVM. The java class runs a
> >> very simple javascript script which generates a small xml fragment and
> >> outputs it to the screen.
> >> The expected output is:
> >> <y>a & b</y>
>
> >> 1. My first attempt to run this was using Rhino-1.6R7.
> >> [kieran]$ env CLASSPATH=./js-1.6R7.jar:$CLASSPATH java E4X
> >> Exception in thread "main" org.mozilla.javascript.EcmaError: TypeError:
> >> error: Unexpected character encountered (lex state 3): 'b' (<cmd>#3)
> >> ...
>
> >> I haven't actually worked out what is causing this problem, but I think
> >> that it was a bug in the xmlbeans library (which Rhino-1.6R7 uses). In
> >> any case, I moved on as follows:
>
> >> 2. I then tried Rhino-1.7R1
> >> [kieran]$ env CLASSPATH=./js-1.7R1.jar:$CLASSPATH java E4X
> >> Exception in thread "main" java.lang.UnsupportedOperationException:
> >> This DocumentBuilder, "org.apache.xerces.jaxp.DocumentBuilderImpl", does
> >> not support the reset functionality. Specification "null" version "null"
> >> ...
>
> >> This problem seems to be caused by the my Xerces version not being
> >> sufficiently up to date.
> >> I haven't tried all versions, but what I /can/ say is that 2.0.1 & 2.6.2
> >> both generate this exception.
>
> >> 3. So, I installed the most recent xerces library
> >> [kieran]$ env CLASSPATH=./js-1.7R1.jar:./xercesImpl-2.9.0.jar:$CLASSPATH
> >> java E4X
> >> <parent/>
>
> >> This was the weirdest problem that I encountered. Whatever the contents
> >> of my javascript XML object, "<parent/>" was the only output that was
> >> ever generated!
>
> >> 4. As I suspected that some other jar was interfering somehow, I
> >> systematically removed jars from my CLASSPATH, and re-tested. It turned
> >> out that as soon as I removed saxon-6.5.4.jar from my CLASSPATH, the
> >> java worked as expected:
>
> >> [kieran]$ NOSAXONCLASSPATH=$(echo $CLASSPATH | perl -np -e
> >> 's/saxon-6.5.4.jar//')
> >> [kieran]$ env
> >> CLASSPATH=./js-1.7R1.jar:./xercesImpl-2.9.0.jar:$NOSAXONCLASSPATH java E4X
> >> <y>a & b</y>
>
> >> So, I had got Rhino/E4X to work as required by:
> >> 1. Upgrading to Rhino1.7R1.
> >> 2. Upgrading to Xerces 2.9.0.
> >> 3. Uninstalling Saxon 6.5.4.
>
> >> However, Saxon 6.5.4 is an is integral part of our application (hey, it
> >> works fine for us, and upgrading would be very non-trivial), so I had to
> >> find a solution that didn't involve uninstalling Saxon.
>
> >> Saxon uses the "Services API" to inform
> >> javax.xml.transform.TransformerFactory which TransformerFactory
> >> implementation it should return when the static newInstance() method is
> >> called. Saxon tells it to use "com.icl.saxon.TransformerFactoryImpl".
>
> >> For some reason (probably too difficult/time-consuming to investigate)
> >> the Rhino/E4X library doesn't interact correctly with transformers
> >> generated by the Saxon factory: "com.icl.saxon.TransformerFactoryImpl".
>
> >> If you're interested, my "solution" was to amend the Saxon jar such that
> >> it doesn't specify which TransformerFactory to use (by deleting the
> >> files in META-INF/services); the bits of my application that need a
> >> "com.icl.saxon.TransformerFactoryImpl", I've explicitly amended to
> >> request one.
>
> >> I hope this helps someone!
>
> >> Kieran
>
> >> [E4X.java]import org.mozilla.javascript.*;
>
> >> public class E4X {
> >> public static void main(String args[])
> >> throws Exception
> >> {
> >> Context cx = Context.enter();
> >> try {
> >> Scriptable scope = cx.initStandardObjects();
> >> Object result = cx.evaluateString(
> >> scope,
> >> "var x = <example>a & b</example>; \n"+
> >> "var y = <y/>; \n"+
> >> "y.appendChild(x.text()); \n"+
> >> "y.toXMLString(); ",
> >> "<cmd>", 1, null
> >> );
> >> System.out.println(Context.toString(result));
> >> } finally {
> >> Context.exit();
> >> }
> >> }
>
> >> }
>
> > Bizarre-- the E4X implementation in Rhino 1.7R1 just uses the XML
> > parser from javax.xml. Your example program worked just fine for me
> > with only the Rhino jar in the classpath.
>
> Hmm, I'm realizing I should have been a bit more explicit in terms of
> exactly what was in my classpath.
> The example that you're referring to would be better expressed as follows:
>
> [kieran]$ env CLASSPATH=.:./js-1.7R1.jar:./xercesImpl-2.6.2.jar java E4X
> Exception in thread "main" java.lang.UnsupportedOperationException:
> This DocumentBuilder, "org.apache.xerces.jaxp.DocumentBuilderImpl", does
> not support the reset functionality. Specification "null" version "null"
>
> The point being that xerces is in my classpath.
> So, when XmlProcessor.java executes (line 85):
> this.dom = javax.xml.parsers.DocumentBuilderFactory.newInstance();
> the DocumentBuilderFactory implementation that will be returned will be
> an org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.
> This is on account of the contents of
> META-INF/services/org.apache.xerces.jaxp.DocumentBuilderFactoryImpl in
> xercesImpl-2.6.2.jar.
>
> Presumably, in the absence of the xerces jar, some JVM default
> DocumentBuilderFactory will be used. (yep, I've just tested this, and it
> returns a
> "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl";
> presumably a more up-to-date implementation).
>
> One aim of my post (apart from the cathartic process of brain-dumping)
> was to highlight the fact that an older version of Xerces (and - I
> expect - other xml libs) in your classpath can cause unwanted
> side-effects and exceptions.
>
> This might not sound like a common occurrence but it'll include, for
> instance, anyone who is using Tomcat 5.0, 5.5 or 6.0.
>
> Kieran
Ah, thanks for clarifying. I'll bet others will run into this problem
and your post will help them debug it.
--Norris
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
