[OF-53] Replace custom logging implementation with a third party library Created: 22/Aug/09  Updated: 22/Aug/10  Resolved: 22/Aug/10

Status: Resolved
Project: Openfire
Components: Connection Manager, Core
Affects versions: 3.6.4
Fix versions: 3.7.0 beta

Type: Improvement Priority: Major
Reporter: Guus der Kinderen Assignee: Guus der Kinderen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Related to
is related to WHACK-12 Replace custom logging implementation... Resolved

 Description   

Openfire has a proprietary implementation for its logging framework. We can improve and expand logging functionality by replacing that logging implementation with one of the many available libraries. Such implementations should be more flexible and more feature richt. An added benefit is that by doing so, we reduce the code in Openfire that we need to maintain, which will allow Openfire developers to focus better on what they're supposed to produce: code that relates to XMPP.



 Comments   
Comment by Guus der Kinderen [ 22/Aug/09 ]

In the proposed implementation that I've created, I used SLF4J. This library provides a facade, or delegate, for logging, which allows for easy customization. The SLF4J provided logging interface is practically a duplicate of the existing Openfire logging interface. Most developers will have no trouble using it.

I've configured SLF4J to use Log4j as the logging implementation. Log4j is a well known, mature implementation. I've set up the log4j configuration to be backwards compatible with the existing logging configuration.

The existing org.jivesoftware.util.Log class has been modified. The existing methods that are used to record logging statements have been deprecated. Instead, developers should use the SLF4J interface directly.

An example of SLF4J usage is shown below:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  Logger logger = LoggerFactory.getLogger(HelloWorld.class);
  
  public void hello() {
    logger.info("Hello World");
  }
}
Comment by Guus der Kinderen [ 22/Aug/09 ]

Gato, as discussed, I've committed the code. Could you review it please?

Comment by Guenther Niess [ 22/Aug/09 ]

After a first test I would integrate the log4j configuration into the openfire.jar (move it from build/lib/dist/log4j.xml to src/resources/jar/log4j.xml) and change the File parameter to the absolut patch {{$

{openfireHome}

/logs/...}} (The first time after updating I have to search for my logs, because I used a different startup script).

Comment by Guus der Kinderen [ 22/Aug/09 ]

Although the current location isn't ideal, putting it in the jar prevents people from modifying it. That's be a shame. The nicest thing would be to put it in /conf/, and have that on the classpath somehow.

Comment by Guenther Niess [ 22/Aug/09 ]

Yes, the conf directory would be better. Maybe something like:

private static final org.slf4j.Logger Logger;

static {
  String log4jConfigName = "conf" + File.separator + "log4j.xml";
  File log4jConfig = new File(JiveGlobals.getHomeDirectory(), log4jConfigName);
  if (log4jConfig.exists()) {
    org.apache.log4j.xml.DOMConfigurator.configure(log4jConfig.getAbsolutePath());
  }
  Logger = org.slf4j.LoggerFactory.getLogger(Log.class);
}

in the org.jivesoftware.util.Log class could do the job. And when it sould be backward compatible maybe we should provide the fatal methods and map them to the error methods.

Comment by Guus der Kinderen [ 02/Dec/09 ]

I've now updated all plugins too, except for the clustering plugin.

Comment by Guenther Niess [ 02/Dec/09 ]

Updated to the upcoming 3.6.5 version to use the updated plugins (see http://www.igniterealtime.org/community/message/198549).

Comment by Guus der Kinderen [ 03/Jan/10 ]

Work that still needs to be done.

  • Make the log4j.xml file accessible (it should not be in openfire.jar)
  • Location of the logfiles should be relative to Openfire's installation directory.
Comment by Guus der Kinderen [ 07/Jan/10 ]

Fixed the problem with the location of the logfiles. It was occurring on Windows only. Fixed it by adding the openfireHome system property.

Comment by Guus der Kinderen [ 10/Jan/10 ]

Log4j.xml is in the /lib/ dir (already was).

Comment by Guenther Niess [ 02/Feb/10 ]

I've updated one server with the new beta and some old plugins can't be started because the org.xmpp.component.log class is missing. Should we add this interface to be more backward compatible?

Comment by Guus der Kinderen [ 02/Feb/10 ]

What plugins exactly? If we're going to put it back now, when are we going to take it out again? Are up-to-date versions for the affected plugins available?

Comment by Guenther Niess [ 02/Feb/10 ]

Ohh, there were only a few self written plugins, so don't care about it. All used third party plugins work as expected.

Comment by Daniel Haigh [ 03/Feb/10 ]

We have just implemented the trunk build on our staging servers.

Logging is no longer working on Ubuntu - nothing is being logged at all in error,warn,info or debug.

It is working on Windows.

Any ideas? Thanks.

Comment by Daniel Haigh [ 03/Feb/10 ]

I also tried to add the property "log.directory" with the value of "/opt/openfire/logs/ "

Unfortunately it didn't help.

Comment by Guenther Niess [ 03/Feb/10 ]

Yesterday I fixed an issue with the deb package, if you rebuild it again it should work. Please check if you have a log4j.xml file within Openfires lib folder.

Comment by Daniel Haigh [ 04/Feb/10 ]

No luck unfortunately. The log4j.xml is there but I do get this message when I compile openfire:

[java] log4j:WARN No appenders could be found for logger (org.apache.jasper.JspC).
[java] log4j:WARN Please initialize the log4j system properly.

Is that an issue?

We aren't installing from the debian package, as I don't know much about this - we haven't had to use this previously. We just copied the compiled code to the Ubuntu server and it works.
Does it now have to be installed from the package?

Anyhow I just tried executing installer.debian in ANT but get this error: Cannot run program "javadoc.exe": CreateProcess error=2, The system cannot find the file specified

Sorry I don't have much experience with all this.

Comment by Guus der Kinderen [ 04/Feb/10 ]

Could you verify that the openfireHome argument is set properly, when Openfire is started? You should find something like -DopenfireHome=<a absolute or relative path> in the output of px ax | grep java

Comment by Guus der Kinderen [ 04/Feb/10 ]

And no, this is not an issue:

[java] log4j:WARN No appenders could be found for logger (org.apache.jasper.JspC).
[java] log4j:WARN Please initialize the log4j system properly.

It's relevant to the build itself, not to the end result of said build. You can safely disregard those messages.

Comment by Daniel Haigh [ 08/Feb/10 ]

That setting is there and is correct. I am not sure what else to try - just not seeing any logging. Unfortunately there is probably an error but without the logging we can't see it.
It did work fine on Windows - just not Ubuntu.

We may have to roll back but that is a shame because we needed a lot of the other changes that are in the recent builds.

Anyway I'll keep looking into it if I get some time - hopefully I can find the issue.

Comment by Guenther Niess [ 08/Feb/10 ]

I think we should also replace the logging implementation for the connection manager.

Comment by Daniel Haigh [ 15/Feb/10 ]

We managed to get the logger working by building the Debian installer and installing from that.

It was a pain because I work on Windows and it wasn't possible to create the debian installer on Windows - but we managed to do it on a Mac.

(We haven't needed to do that normally to get Openfire working on Ubuntu - usually we just copy the target folder across)

Thanks

Comment by LG [ 14/Apr/10 ]

HttpBindManager and AdminConsolePlugin contain: ``System.setProperty("org.apache.commons.logging.LogFactory", "org.jivesoftware.util.log.util.CommonsLogFactory");´´ - is this good?

Is there a good reason why ServerStarter and ClearspaceX509TrustManager still ``import org.jivesoftware.util.Log;´´?

Comment by Daryl Herzmann [ 27/Apr/10 ]

LG, your most recent commit causes trouble for the RPM based installer:
{{
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.jivesoftware.openfire.starter.ServerStarter.<clinit>(ServerStarter.java:53)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 1 more
Could not find the main class: org.jivesoftware.openfire.starter.ServerStarter. Program will exit.
}}

will look into it more shortly.

Comment by LG [ 27/Apr/10 ]

"see svn log for this file" - I did need a few seconds to translate this to "see CR-53 for details"
Oops. Anyhow it looks like an RPM installer issue so one could create another issue for this instead of rolling back.

Comment by Daryl Herzmann [ 28/Apr/10 ]

Hi LG,

Sorry about the poorly worded commit, I meant to reflect Niess's commit log message previously. Looks like we have to include sl4j in the startup.jar ?

Comment by wroot [ 19/May/10 ]

I've noticed that 3.7.0 Beta is creating logs in C:\logs instead of keeping them in C:\Program Files\Openfire\logs as it is said on Logs page. The only error being written there is about Fastpath, but i'm not sure this could be the reason. Probably it is because of the new logging system.

Comment by Guus der Kinderen [ 28/Jul/10 ]

Wroot - what installer / distributable did you use when you got those results? Could you try again with the latest build?

Comment by wroot [ 28/Jul/10 ]

Ok. It's not happening with openfire_2010-07-28 build. So, probably it is not an issue anymore.

Comment by Guus der Kinderen [ 28/Jul/10 ]

Ok. Let's reopen if it does pop up.

Comment by wroot [ 29/Jul/10 ]

Sorry, Guus. It's back. I have tried 3.7.0 beta.exe from here http://bamboo.igniterealtime.org/browse/OPENFIRE-NIGHTLYWINDOWS-3/artifact/Project-Windows-distribution-files and when i run launcher it creates logs dir in C:\

Comment by Guus der Kinderen [ 29/Jul/10 ]

grmbl. Reopening

Comment by Guus der Kinderen [ 21/Aug/10 ]

I believe I have fixed this now. The install4j packager creates the Windows Launcher, which did not set the openfireHome variable. Wroot, could you verify the fix? You can download the new binary from http://bamboo.igniterealtime.org/browse/OPENFIRE-NIGHTLYWINDOWS/latest/artifact (any build including or later than 30 will contain the fix).

Comment by wroot [ 21/Aug/10 ]

I have tested a few builds from Bamboo. Indeed 30 build has logs path fixed, but Kraken stopped working (Kraken is ok in Admin Console, but Spark doesnt see gateways). Builds 25, 26 are ok with Kraken. Build 27 throws a bunch of errors in launcher and doesn't work at all. 28 and 29 shows Wrong Parameter Usage error in launcher and server doesn't work.

Comment by Guus der Kinderen [ 22/Aug/10 ]

There is indeed some kind of problem in Kraken that relates to our new logging implementation (Kraken is already being translating several types of logging interfaces into each-other - this last translation appears to fail). I'll work with Daniel Henninger to resolve these. We'll do that outside the scope of OF-53 Resolved though.

Generated at Fri Mar 29 09:22:56 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100248-rev:6a03a54452e975225e04dfda06fdac6fd9e95b00.