XLogback Project 0.91 Released for Preview

Serdar Basegmez | 8 hours ago | Comments
This week has been great for 'logging' fans :)

After XPages OpenLog Logger M6 release by Paul S. Withers, I have released the first preview for the XLogback project.

XLogback is the OSGi plugin implementation of Logback Project for Domino environments.

Logback has been started by Ceki Gulcu as an unofficial successor of Log4J. It offers a native implementation for SLF4J (Simple Logging Facade for Java) API. We actually use SLF4J and SLF4J delegates the logging to Logback. That's an important advantage for Java developers because as long as your code uses standard logging implementation provided by SLF4J (Logger classes, Markers, MDC, etc.) your own code is independent from Logback. In the future, you may start using another logging library (e.g. Log4J2) just by changing SLF4J libraries.

XLogback started as a side project for myself a year ago. I have been developing a Java library and OSGi plugins for my customer projects (as I blogged) and I started customizing Paul's OpenLogItem class for my needs. Since I have been using DOTS extensively on my customer projects, I have tried lots of iterations to adapt OpenLog logging into my projects.

At one point I found out that every time I change the logging implementation, I had to change the way I was logging in the projects. The solution was separating the logger interface and the logging engine, which is the official definition of Java logging framework. After short research, I liked the Logback Project because of its simple implementation and configuration. The source code is pretty straightforward and well-written. It wasn't so difficult to implement.

I have been using Logback on production environment for more than six months now. As many people asked about it, I have decided to refactor the logback part out of my framework.

On my framework, I was using an automated configuration based on my central configuration management plugin. So I can change the logging on-the-fly for specific projects, users or platforms and it also supports tell commands such as putting everything into debug mode. However, that part needs to implement a couple of large plugins which are quite mixed with the customer code. Therefore I simplified the process and added an automated configuration module which is fed by Notes.ini parameters. I have chosen this way not just because of simplicity, but also for the ease of administration. In my customer case, I have more than 6 application servers running Java code and working with file configuration is not practical for administration. On the other hand, notes.ini files can be managed by configuration documents on Domino servers.

If you are familiar with the concept of logging framework in Java, you would probably know, using Loggers is quite easy. You start your class with defining a Logger and simply use it.

A picture named M2

Using parameters in logging is also possible.

A picture named M3

Using the second one is a great performance gain, because it will perform the string operation only if logging is needed. This notation also less prone to errors and better for readability.

Make sure you look at Logback Manual about all details.

One question you may ask would be about XPages OpenLog logger vs. XLogback. This decision completely depends on what you need and how you write your code. Let me quote from readme documentation of XLogback.

"XPages OpenLog Logger has a great advantage of simplicity for XPages developers. If you are using OpenNTF Domino API, you can already use it by now. Even you don't want to install any plugins for your environment, you can easily import necessary libraries into your NSF and it will work.

On the other hand, XLogback provides more JAVA-ish way for logging. So XLogback provides more universal logging mechanism for any Java library you have developed, with the ability to move your code into totally different Java environment. Also appender support is significant. Different types of appenders can be defined in parallel to OpenLog. Check Logback web site for very interesting scenarios."

I have also created a small comparison table at the documentation.

What is next?

Right now the project is for preview. It has been tested with XPages, Servlets and DOTS tasklets on Domino 9.0.1 environment but there are still things to do for production quality.

Considering the XPages developer population in the community, I'm planning to prioritize the XPages improvements first. I will import some functionality from Paul's OpenLog logger project for better usability for XPages developers.

The second phase will be focused on configuration. Right now, automatic configuration uses console/file/openlog logging at the same time but we need more customization.

Your contribution at this point is quite important. How do you use the logging? How do you want to use it? What are your priorities? Please let me know.

Go to the code repository of XLogback to see the code or Jira page for contributions and start today...

IBM Champions appreciation on Collaboration Today

Oliver Busse | 4 days ago | Comments
Now as the IBM Champions for ESS (fka ICS) in 2016 were annouced, I took the chance to implement some improvements to OpenNTF's other website "Collaboration Today" to give those people the credit they deserve. IBM Champions are people who deliver most valuable content and share their knowlegde. This is collected by people who are doing also very much appreciated work and apperently are also IBM Champions!

You now can see IBM Champion generated content directly by the new star indicator on every blog post's link on the homepage. I also realized a great idea of our OpenNTF chairman Christian Guedemann he proposed during our call today: show the most frequent bloggers and also the curators who collect the stuff just for you.

You can access the new statistics area right here: https://collaborationtoday.info/ct.nsf/stats.xsp

XPages OpenLog Logger - Request for Additional Chefs

Paul Withers | 5 days ago | Comments
This week a new release of XPages OpenLog Logger was released. In the blog post about it today, I made a request for other developers to get involved. As I mentioned, it's not because of any imminent or planned intention to step aside from the project. Instead it's part of an ongoing plan for improved governance of projects on OpenNTF - giving less risk of a project being left without a chef to take it forward, providing more breadth for supporting bugs and feature requests, and providing more people to test new releases of the project or test the project on new releases of Domino. It will also provide a project board who are able to help drive the project forward in a way that supports all users (although I hope I've done a pretty good job of that, helped by the tight scope of the project).

More importantly, I'm not just looking for people able to "hit the ground running" with the project. Getting involved in OpenNTF Domino API from the start has taught me a huge amount about Domino and Java. Co-authoring XPages Extension Library taught me a massive amount about the components involved and, with the skills from both, I've been able to contribute back. So I'm particularly keen to reach out to developers who may not be Java or XPages experts but who want to get involved in open source projects and want to expand their skills. Many of the feature requests I've had are small, self-contained enhancements. And the scope of the project - as Java code in an NSF, as a plugin, picking up xsp.property values, with a JavaDoc and (I would like to think) good documentation and a demo database - means there's a lot for those who want to learn. And I am particularly keen to ensure a good "on-boarding" process for the new team.

There's nothing immediately on the horizon, but a new release is a good time to reach out. So get in touch with me on my blog, on Twitter (paulswithers) or on the XPages Slack chat (see Dave Leedy's recent blog post).