Make OSGi logging come out on console

1,101 views
Skip to first unread message

t...@quarendon.net

unread,
Jul 19, 2016, 3:30:33 AM7/19/16
to bndtools-users
So as I learn more about using OSGi, I understand the importance of being able to see the messages that are written to the OSGi log.
This isn't as easy as it could be.

When running from within eclipse, there are at least ways in which you can see the log, you can use the gogo shell commands (if you've set that up in your bndrun file), or you can use the web console interface (again, if you've set that up).
When running with the junit gui launcher though, or when running tests from the command line using gradle, there doesn't appear to be any way to see the log messages.

What's double confusing is that SOME log messages DO come out on the console. so, for example:

2016-07-19 08:20:20.239:INFO::main: Logging initialized @915ms
2016-07-19 08:20:20.261:INFO:oejs.Server:main: jetty-9.2.12.v20150709
2016-07-19 08:20:20.289:INFO:oejsh.ContextHandler:main: Started o.e.j.s.ServletContextHandler@6d4e5011{/,null,AVAILABLE}
2016-07-19 08:20:20.289:INFO:oejs.Server:main: Started @966ms
2016-07-19 08:20:20.307:INFO:oejs.ServerConnector:main: Started ServerConnector@1e0b4072{HTTP/1.1}{0.0.0.0:8080}

I've actually got no idea what is producing these messages, whether this is anything to do with OSGi, or whether this is just one of the components doing it's own logging. If the latter, then confusing. However having log messages printed out to the console like this is What You Would Expect, at least for development.
Given the presence of some log messages such as that, you can understand my lack of understanding that there are OTHER logs elsewhere that might contain useful information, although in order to look at them you have to do non-obvious things. Indeed I'm not even sure whether there is a way I can see log messages when I'm running unit tests from a gradle build.

There must be a way to configure the OSGi logging such that it prints to standard output? Like every other logging system in the world?

Would using "pax logging" solve this? As I understand it that's something that implements the OSGi logging service, but has configuration like LOG4J etc? In which case, Why isn't this on by default? Surely it would save everyone a lot of time?

Thanks.

Luke Winkenbach

unread,
Jul 19, 2016, 1:10:27 PM7/19/16
to bndtools-users
Take a look at your logging configuration to make sure it is doing what you intend for it to do.

It is common in OSGi to use PAX logging, Felix fileinstall, and a PAX configuration file in the fileinstall load directory.

Here is a simple configuration file for PAX (saved as org.ops4j.pax.logging.cfg in the fileinstall load directory):
# Root logger option
log4j
.rootLogger = INFO, stdout, file
 
# Redirect log messages to console
log4j
.appender.stdout=org.apache.log4j.ConsoleAppender
log4j
.appender.stdout.Target=System.out
log4j
.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j
.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
 
# Redirect log messages to a log file, support file rolling.
log4j
.appender.file=org.apache.log4j.RollingFileAppender
log4j
.appender.file.File=judi-application.log
log4j
.appender.file.MaxFileSize=5MB
log4j
.appender.file.MaxBackupIndex=10
log4j
.appender.file.layout=org.apache.log4j.PatternLayout
log4j
.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
If you don't want to log to stdout, then remove it from the log4j.rootLogger.

David Daniel

unread,
Jul 19, 2016, 1:13:00 PM7/19/16
to bndtools-users

t...@quarendon.net

unread,
Jul 20, 2016, 4:07:49 AM7/20/16
to bndtools-users


On Tuesday, 19 July 2016 18:10:27 UTC+1, Luke Winkenbach wrote:
Take a look at your logging configuration to make sure it is doing what you intend for it to do.


But this is my point. "Out of the box" so to speak, what IS the logging configuration? If you just naively run something using bndtools, I have absolutely no idea what the logging configuration would be, or even what "configuration" even means. 
I (now) know that most likely what you want to do is set up felix fileinstall to allow you to specify configuration properties, but even then I struggle to know where to find information about what properties to configure.

There needs to be a better "default", "out of the box" set up that ensures that vital logging information is available and easily viewable. 

Achim Nierbeck

unread,
Jul 20, 2016, 4:23:30 AM7/20/16
to bndtool...@googlegroups.com
Hi, 

well if you want to have Out-of-the-Box setups you either need to setup your own "template" structure or look if there's something already available doing that. For the later Apache Karaf might help you, as it's focus is exactly this. Give you a small as possible platform with the most used infrastructure and easy deployment. 

regards, Achim 


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



--

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master 

Christian Schneider

unread,
Jul 20, 2016, 4:42:02 AM7/20/16
to bndtool...@googlegroups.com
Yes. Starting with karaf is a good idea as it has a lot of defaults configured.
Karaf is also my reference when I try to run something in a plain felix to see what I need to configure.

For example karaf has a file config.properties. These are settings you can do as framework properties.
So for a felix fileinstall config you can use this snippet from config.properties:
felix.fileinstall.enableConfigSave = true
felix.fileinstall.dir    = ${karaf.etc}
felix.fileinstall.filter = .*\\.cfg
felix.fileinstall.poll   = 1000
felix.fileinstall.noInitialDelay = true
felix.fileinstall.log.level = 3
felix.fileinstall.log.default = jul


Here is a bndrun from one of my projects that configures fileinstall and pax logging.

https://github.com/cschneider/osgi-chat/blob/master/packaging/service/service.bndrun

Actually it does a little more but it is always easier to remove stuff than to add it from scratch.

Christian
-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

t...@quarendon.net

unread,
Jul 21, 2016, 11:07:09 AM7/21/16
to bndtools-users


On Wednesday, 20 July 2016 09:42:02 UTC+1, Christian Schneider wrote:
Yes. Starting with karaf is a good idea as it has a lot of defaults configured.

Googling around (I admit I haven't tried anything), it doesn't look like karaf and bndtools are that easy to use together?
This is the best description I could see: http://enroute.osgi.org/appnotes/bndtools-and-karaf.html
That talks about "remote karaf instance", implying that I have to run a karaf server on my machine and get bndtools to deploy to it. 
This was the kind of set up I was trying to avoid, and doesn't feel like it would work well for running integration tests on a build machine?

Maybe it's simpler than it appears though?


David Daniel

unread,
Jul 21, 2016, 12:05:25 PM7/21/16
to bndtool...@googlegroups.com

Christian is doing a lot of work here. Check out his osgi-chat application mentioned in another thread


--
You received this message because you are subscribed to a topic in the Google Groups "bndtools-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bndtools-users/IA3UmWw5jGc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bndtools-user...@googlegroups.com.

Christian Schneider

unread,
Jul 21, 2016, 2:57:11 PM7/21/16
to bndtool...@googlegroups.com
I think it depends a bit on what you want to achieve. The karaf distro is taylored to be an application server you deploy your application on.
Typically this is done using a feature. It is also possible and quite common to deploy several applications to one karaf instance.
For this kind of usage it is very difficult to use bndtools. Maybe this will change in the future.
Integration tests for karaf based applications typically use pax exam. There you can define the karaf setup + your bundles that you need and run the tests in that environment.

Bndtools assemblies on the other hand are taylored to package a single application. So what I can imagine is that you take from karaf all the bundles you need to enhance your application but package the whole thing using bndtools. This is what I currently explore in the OSGi chat application. So for example you could use the karaf shell and the karaf commands that make sense for your application. I found that this works quite well but it currently requires a lot of knowledge as you have to replicate a lot of the wiring and setup of karaf. I hope I can provide examples and tutorials to make this easier in the future.

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

David Daniel

unread,
Jul 21, 2016, 3:42:12 PM7/21/16
to bndtools-users
Yes to everything Christian said.  My current process is to look at the features.xml in karaf and create a matching bndrun and bnd.bnd file for features I want.  I debug using the bndrun file and use paxexam for integration testing.  I have two different build modules.  One that packages everything as a karaf custom distribution and I am working on the one that builds everything as a fat jar based off the maven plugins supplied by Christian.  Karaf is generally developed using Maven and bndtools is just getting support for maven but still requires the bnd workspace for much of its functionality.  If you are looking for a distribution centered around bndtools then enroute and amdatu are great choices.  In my opinion they just require a little more knowledge about osgi.  When starting with OSGI the path I took was starting with service mix and moved down to karaf and then moved further down to my very custom way of doing things.  If you are looking for a bunch of easy features to install like AMQP/CXF for REST/PaxWeb for static pages where you just type in a command to add the feature to your application server then Karaf or ServiceMix are the easiest.  If you want to build a very custom system where your mixing and matching dependencies and taking advantage of common standards to pick your favorite library then in my opinion some of the other frameworks provide the best option.
Reply all
Reply to author
Forward
0 new messages