Unresolved dependencies aren't logged

[joeha480]

As far as I know, unresolved dependencies in the OSGi framework are not logged. To find these errors, you must

• start the pipeline with ./pipeline2.sh shell
• type lb at the prompt
• find bundles that aren't started
• try to start them with start [bundle-id]

Errors when starting bundles should really be printed to the log.

[bertfrees]

I remember Javi did something related. Here: https://github.com/daisy/pipeline-issues/issues/437. Maybe this only forwards the DS messages but not the other OSGi messages? @capitancambio What is required to get what Joel wants?

[capitancambio]

Hallo @joeha480 and @bertfrees ! in the latest dev version whatever felix logs is captured by the pipeline and written to file/printed out. It seems that unresolved dependencies are not logged (i.e g! log debug doesn't show them).

I've done a couple of experiments and the results are funny. if you change 'felix.log.level' in config.properties to 4 (debug) and execute with some missing dependencies...

 14:20 javi at disorder  updater-rebased ✗
~/daisy/pipeline-assembly $ pipeline2 1> out 2> err

in out we get tons of log lines (as you might expect), but in err you have the interesting lines: org.osgi.framework.BundleException: Unresolved constraint in bundle org.daisy.pipeline.modules.dtbook-tts [30]: [...]

I get from this that BundleException is not logged through the logging mechanisms, and also because the stack looks like:

at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4002)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2045)
at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1491)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:334)
at java.lang.Thread.run(Thread.java:745)

So I presume these exceptions are handled by the default Thread.UncaughtExceptionHandlerinstead of being caught elsewhere, I don't know if we can change this behaviour in order to log the unresolved dependencies, which it's quite useful.

I'll have a deeper look but I don't know if we can easily fix this

[bertfrees]

When I run test with Pax-Exam (which uses Felix) and there is something wrong with bundle wiring I do see error messages of the form

ERROR: Bundle org.daisy.pipeline.modules.dtbook-validator [30] Error starting file:/var/folders/mr/f6s9zqtn03d8rgzxb96_2bh00000gn/T/1460374309340-0/bundles/org.daisy.pipeline.modules.dtbook-validator_1.0.2.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.daisy.pipeline.modules.dtbook-validator [30]: Unable to resolve 30.0: missing requirement [30.0] osgi.wiring.bundle; (osgi.wiring.bundle=org.daisy.pipeline.modules.validation-utils))
org.osgi.framework.BundleException: Unresolved constraint in bundle org.daisy.pipeline.modules.dtbook-validator [30]: Unable to resolve 30.0: missing requirement [30.0] osgi.wiring.bundle; (osgi.wiring.bundle=org.daisy.pipeline.modules.validation-utils)
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4002)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:2045)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1299)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
    at java.lang.Thread.run(Thread.java:745)

and I can also make them show up in the log file (with logback).

[capitancambio]

Could you point me to the config.properties and launcher script that it uses, please?

[bertfrees]

I'm not sure how exactly Pax-Exam invokes Felix internally, that is hidden from the user. But at least this proves that there is a way to make it work.

[bertfrees]

Not sure where the magic happens. I've looked at pax-exam-container-forked but it doesn't seem to have any Felix-specific code.