NullPointerException / expression could not be evalutated

[Jostein Austvik Jacobsen]

Any idea what this could be? I get this sometimes and then I have to restart the framework to get it working again...

2012-12-11 19:47:41,100 [ERROR] o.d.c.xproc.calabash.steps.Message - bundle://15.0:1/xml/xproc/zedai-to-epub3.store.xpl:72:45:err:XD0023:Expression could not be evaluated

2012-12-11 19:47:41,114 [ERROR] org.daisy.pipeline.job.Job - job finished with error state

java.lang.NullPointerException: null

    at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432) ~[felix.jar:na]

    at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) ~[felix.jar:na]

    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) ~[felix.jar:na]

    at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ~[na:1.7.0_09]

    at sun.misc.Unsafe.defineClass(Native Method) ~[na:1.7.0_09]

    at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63) ~[na:1.7.0_09]

    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399) ~[na:1.7.0_09]

    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396) ~[na:1.7.0_09]

    at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_09]

    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395) ~[na:1.7.0_09]

    at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77) ~[na:1.7.0_09]

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46) ~[na:1.7.0_09]

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_09]

    at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_09]

    at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:68) ~[na:na]

    at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45) ~[na:na]

    at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313) ~[na:na]

    at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296) ~[na:na]

    at com.google.common.eventbus.EventBus.post(EventBus.java:264) ~[na:na]

    at org.daisy.common.xproc.calabash.EventBusMessageListener.post(EventBusMessageListener.java:44) ~[na:na]

    at org.daisy.common.xproc.calabash.EventBusMessageListener.error(EventBusMessageListener.java:57) ~[na:na]

    at org.daisy.common.xproc.calabash.XProcMessageListenerAggregator.error(XProcMessageListenerAggregator.java:49) ~[na:na]

    at com.xmlcalabash.core.XProcRuntime.error(Unknown Source) ~[na:na]

    at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]

    at com.xmlcalabash.runtime.XPipelineCall.run(Unknown Source) ~[na:na]

    at com.xmlcalabash.runtime.XCompoundStep.run(Unknown Source) ~[na:na]

    at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]

    at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]

    at org.daisy.common.xproc.calabash.CalabashXProcPipeline.run(CalabashXProcPipeline.java:239) ~[na:na]

    at org.daisy.pipeline.job.Job.run(Job.java:149) ~[na:na]

    at org.daisy.pipeline.job.DefaultJobExecutionService$1.run(DefaultJobExecutionService.java:65) ~[na:na]

    at java.lang.Thread.run(Thread.java:722) ~[na:1.7.0_09]

2012-12-11 19:47:41,122 [DEBUG] org.daisy.pipeline.push.Poster - Status changed 92271a41-443e-41e7-ac71-05805cef594b->ERROR

Jostein

[Romain Deltour]

> java.lang.NullPointerException: null
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432) ~[felix.jar:na]

We faced this kind of error earlier, it was caused by a dynamism issue where a bundle referenced a class or service from another bundle which had been previously stopped or updated.

Can you find a repro so that we isolate which bundle doesn't clean its references ?

Romain.

> <daisy-pipeline.log>

[Jostein Austvik Jacobsen]

It seems like it happens randomly. I posted the log file above. If I get the error again, is there any more log dumps I can extract somehow?

Jostein

[Javier Asensio]

Sorry for being out of office yesterday, I had a evaluation meeting for the Phd. Yep, this error is a kind of phantom for felix.

There is some info here:
https://issues.apache.org/jira/browse/FELIX-3477

And I remember that I tried this in the past when creating the job's thread without much luck
http://stackoverflow.com/questions/9911587/loading-resources-with-the-context-loader-fails-with-a-nullpointerexception

cheers,

Javi

[John Brugge]

FWIW, not sure if this is the same cause, but it looks like the same symptom I reported in http://code.google.com/p/daisy-pipeline/issues/detail?id=195. As other say, it's hard to reproduce, but continues to happen for us sporadically. It is usually right after restarting the web service.

John

[Jostein Austvik Jacobsen]

Yeah that looks like the same bug.

When I tested the desktop webui yesterday I inevitably also tested starting and stopping the dp2 engine a lot of times. That exception occurred quite a lot, I would say maybe every 4 or 5 times running the engine. I think I had to run a script first for it to occur. So just starting the engine and running a script is a way to reproduce it, and it shouldn't take too many tries to reproduce it that way.

Maybe it's more common in windows as well? (Or maybe I just used windows a lot yesterday...)

Jostein

[Romain Deltour]

I did find a systematic repro for bug 195, and I think I know how to fix it (if Javier haven't already, I can't remember). But there may be other causes, we need to have a detailed look at all the bundles in the framework to make sure they update or discard cross-bundle references during the OSGi lifecycle.

I'll have a closer look next week.

Romain.

[Javier Asensio]

I said I tried to change the thread class loader for jobs, without any luck I recall...

cheers,

Javi

[Javier Asensio]

I've just pushed a version of the event-bus service which requires a static database, I dont know if it's related or not. Just to let you know.

cheers,

Javi

[mouret...@gmail.com]

Hi everyone,

Any news about this bug?

I'm trying to run the pipeline on a ubuntu 12.04, but the webservice doesn't start, no matter how many times I try, with or without an empty data/felix-cache.

The error is the following:

ERROR [     o.d.p.webservice.PipelineWebService] Shutting down the framework because of:null

The stack-trace is similar to Jostein's: 

java.lang.NullPointerException

at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)

at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)

at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)

at java.lang.ClassLoader.loadClass(ClassLoader.java:268)

at org.restlet.ext.jetty.HttpServerHelper.createConnector(HttpServerHelper.java:93)

at org.restlet.ext.jetty.JettyServerHelper.start(JettyServerHelper.java:393)

at org.restlet.Server.start(Server.java:590)

at org.restlet.Component.startServers(Component.java:611)

at org.restlet.Component.start(Component.java:538)

at org.daisy.pipeline.webservice.PipelineWebService.init(PipelineWebService.java:140)

The 93rd line of HttpServerHelper attempts to create a new SelectChannelConnector, located in the package org.eclipse.jetty.server.nio, which is satisfied by the jetty-server bundle.

Just to be sure, I've checked in my jetty-server-7.6.5.v20120716.jar, SelectChannelConnector.class is in the right package and, according to the dev-launcher, both bundles were active right before the framework shuts down.

19|Active     |   30|Jetty :: Server Core (7.6.5.v20120716)

17|Active     |   30|org.restlet.ext.jetty (2.1.0.rc6-v20130116-1327)

BTW, is that ok that there is no reference to jetty-server in the framework webservice's manifest (e.g. with Import-Package or Require-Bundle), given that the dependency between Restlet and jetty-server is optional in Restlet's manifest?

[Romain Deltour]

Wow, that’s a pretty old thread :)

As far as I remember, this kind of issue is related to incorrect handling of inter-bundle references during the OSGi lifecycle. I still have sample files for a repro on issue #195, I’ll see if I can still reproduce.

Otherwise, maybe upgrading to the latest felix version will provide better error messages.

Romain.

-- 
You received this message because you are subscribed to the Google Groups "DAISY Pipeline Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to daisy-pipeline-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Javier Asensio]

Yep, this is certainly old :). My wild guess is that you have something else running in the pipeline's port ( I have to say that I thought it would return a proper error message), could you please check what netstat returns for port 8181?

cheers,

Javi

[Romain Mouret]

Nothing else on port 8181. I've tried to run the webservice on other
ports, without any luck.

On Wed, Mar 26, 2014 at 6:15 PM, Javier Asensio

Romain Mouret

[Javier Asensio]

Naturally, I read the other email in a hurry. The weird thing is that we never saw that error before, which java version are you using, openjdk-6 ?

cheers,

Javi

[Romain Mouret]

openjdk-6 mostly. I also gave a try with Oracle's jdk and openjdk-7

On Thu, Mar 27, 2014 at 6:24 PM, Javier Asensio

[Javier Asensio]

This is weird, have you tried to install the deb package? just to see if it also fails...

cheers,

Javi

[Bert Frees]

I've seen the error before. It's an obscure one because sometimes it appears from one day to another. In fact I couldn't run the dev-launcher from master this week because of this error. Building the normal distribution worked fine. Joel from MTM also ran into this error when he was trying to set up the Pipeline on his machine. I tried to reproduce but I couldn't. We haven't tried it since so I don't know if it's solved for him now.

Bert

[Javier Asensio]

It seems to be quite dark in fact... I haven't ever find it myself, I think. Romain, if you type "log d" in the gogo shell can you spot any suspicious message?

cheers,

Javi