ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: NullPointer exception in XSLT transform when JBI assembly is re-started
Date Thu, 05 Jul 2007 16:06:18 GMT
Hi Michael,

I remember something similar has been fixed on the trunk a few weeks ago.
Are you working with ODE 1.0? If so you might need to try the trunk to get a
fix for this. Otherwise let me know and I'll have another look.

Cheers,
Matthieu

On 7/5/07, Michael Horwitz <mike.horwitz@gmail.com> wrote:
>
> Hi,
>
> I have noticed that if I attempt to restart a JBI service assembly that
> contains a BPEL process with an in-process XSLT transform, then the
> process
> starts throwing a NullPointerException whenever an attempt is made to do
> the
> transform:
>
> java.lang.NullPointerException
> at org.apache.ode.utils.xsl.XslTransformHandler.parseXSLSheet(
> XslTransformHandler.java:84)
> at org.apache.ode.utils.xsl.XslTransformHandler.cacheXSLSheet(
> XslTransformHandler.java:106)
> at
>
> org.apache.ode.bpel.elang.xpath10.runtime.JaxenContexts$DoXslTransformFunction.call
> (JaxenContexts.java:346)
> at org.jaxen.expr.DefaultFunctionCallExpr.evaluate(
> DefaultFunctionCallExpr.java:186)
> at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:112)
> at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:688)
> at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:227)
> at
>
> org.apache.ode.bpel.elang.xpath10.runtime.XPath10ExpressionRuntime.evaluate
> (
> XPath10ExpressionRuntime.java:94)
> at org.apache.ode.bpel.runtime.ExpressionLanguageRuntimeRegistry.evaluate(
> ExpressionLanguageRuntimeRegistry.java:80)
> at org.apache.ode.bpel.runtime.ASSIGN.evalRValue(ASSIGN.java:192)
> at org.apache.ode.bpel.runtime.ASSIGN.copy(ASSIGN.java:356)
> at org.apache.ode.bpel.runtime.ASSIGN.run(ASSIGN.java:79)
> at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java
> :451)
> at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
> at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(
> BpelRuntimeContextImpl.java:817)
> at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java
> :310)
>
> at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(
> BpelEngineImpl.java:311)
> at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(
> BpelServerImpl.java:390)
> at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.doExecute(
> QuartzSchedulerImpl.java:351)
> at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.access$000(
> QuartzSchedulerImpl.java:65)
> at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl$1$1.call(
> QuartzSchedulerImpl.java:234)
> at
> org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransaction(
> QuartzSchedulerImpl.java:275)
> at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl$2.call(
> QuartzSchedulerImpl.java:303)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
> ThreadPoolExecutor.java:650)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
>
> The workaround is obviously to undeploy and re-deploy the assembly.
>
> Thanks
>
> Mike Horwitz
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message