You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Robby Pelssers <Ro...@nxp.com> on 2012/12/08 18:59:15 UTC

FW: [saxon] Cocoon3 build breaks if you add Saxon-HE

I guess using the JAXP mechanism is indeed a bad idea.  Well.. at least using [xxx]Factory.newInstance().

Anyone valuable input on this matter?

Robby

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Saturday, December 08, 2012 6:51 PM
To: saxon-help@lists.sourceforge.net
Subject: Re: [saxon] Cocoon3 build breaks if you add Saxon-HE


Unfortunately the JAXP mechanism for obtaining an XSLT engine (or XPath
parser) can easily lead to this effect. People use the JAXP factory mechanism to get whatever XSLT transformation engine happens to be on the classpath, and then they write code that actually only works (and is only tested) with one particular XSLT engine.

What seems to be happening here is that Cocoon is calling Saxon's implementation of the SAX ContentHandler and has passed a null value for the "attributes" parameter of startElement(). Some implementations may accept that but there's nothing in the spec that encourages this assumption; it explicitly says that when an element has no attributes, an empty Attributes object should be passed. So I would definitely class this as a Cocoon bug.

Michael Kay
Saxonica


On 08/12/2012 17:08, Robby Pelssers wrote:
> Hi all,
>
> I was refactoring XSLTTransformer a bit (effort to get support for 
> choosing XSLT processor) and added Saxon-HE 9.4 to the classpath in 
> cocoon-sax
>
>        <dependency>
>          <groupId>net.sf.saxon</groupId>
>          <artifactId>Saxon-HE</artifactId>
>          <version>9.4</version>
>        </dependency>
>
> So after a while I decided to run all unit tests again just to see if 
> my refactoring already broke some unit tests. But at that point I was 
> pretty sure I only restructured code and enabled options. So I was 
> really surprised to find out I broke
>
> ProfilingIntegrationTest.testSimpleGenerator()
>
> So I wasted quite some time understanding what I broke and the asserts should pass so I did not understand what was going on until I inspected the surefire reports. It seems by just adding Saxon-HE to the classpath I already broke the build. And to be 100% sure I removed Saxon as dependency and ran the tests again.  The tests just passed find.
>
> The main question is: How come a Saxon class is used although nowhere we explicitly configured to use saxon?
>
> Robby
>
> Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.425 sec <<< FAILURE!
> testSimpleGenerator(org.apache.cocoon.profiling.ProfilingIntegrationTest)  Time elapsed: 1.35 sec  <<< ERROR!
> java.lang.NullPointerException
> 	at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:291)
> 	at org.apache.cocoon.xml.sax.AbstractSAXPipe.startElement(AbstractSAXPipe.java:97)
> 	at org.apache.cocoon.profiling.component.ProfilingGenerator.startElement(ProfilingGenerator.java:305)
> 	at org.apache.cocoon.profiling.component.ProfilingGenerator.startElement(ProfilingGenerator.java:301)
> 	at org.apache.cocoon.profiling.component.ProfilingGenerator.handleTreeElement(ProfilingGenerator.java:168)
> 	at org.apache.cocoon.profiling.component.ProfilingGenerator.execute(ProfilingGenerator.java:125)
> 	at org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:154)
> 	at org.apache.cocoon.pipeline.AbstractPipeline.execute(AbstractPipeline.java:83)
> 	at org.apache.cocoon.profiling.ProfilingIntegrationTest.testSimpleGenerator(ProfilingIntegrationTest.java:153)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:113)
> 	at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:7
> 5)
> ----------------------------------------------------------------------
> -------- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free 
> Trial Remotely access PCs and mobile devices and provide instant 
> support Improve your efficiency, and focus on delivering more 
> value-add services Discover what IT Professionals Know. Rescue 
> delivers http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/ 
> saxon-help@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/ saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help