cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robby Pelssers <Robby.Pelss...@nxp.com>
Subject FW: [saxon] Cocoon3 build breaks if you add Saxon-HE
Date Sat, 08 Dec 2012 17:59:15 GMT
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 



Mime
View raw message