Good day,
I have a existing Java web application host by websphere developed by senior, that using org.slf4j.Logger for logging. And I found that I have a logback.xml in my workspace, I do some changes on the logback.xml and its take effect.
However, I am curious which file is reading this logback.xml, I search for whole workspace, didnt found any place that is point to logback.xml.
I try to google on this, some is code to read this file, but didnt see any case like mine.
It it read by the the org.slf4j.Logger jar file?
Kindly advise.
You're already looking to the right direction. The configuration is read by logback (how this is done is described on a high-level here at the logback documentation). So the loading of the configuration happens in logback but not in slf4j (which is "just" a facade for different logging frameworks like log4j or in your case logback) as you suspected. Find some more details about SLF4J and the relation to logback here.
Hope that makes it a little more clear.
Related
I am using a framework which is using logback framework for logging. The logs are generated in format - {TimeStamp}_restTests.log and I am trying to figure out the source where the properties of the logback like file name, logging level are set.
There is a logback.xml in the framework but that is not the source as even if I rename it to logback_old.xml or comment out some code in it the logs are getting generated as it is.
I took reference from - https://logback.qos.ch/manual/configuration.html
and searched for logback-test.xml, logback.groovy etc as well but not luck.
I tried searching for keyword '_restTests' which is the postfix of log files in the framework but found nothing.
Please provide any pointers on this
I'm creating a java open source utility package and I would like to know if it is ok to include logging (like log4j) into that package.
The dilemma is if I include log4j into my package, where will i output the log file, I wouldn't want the log file to be at a wrong place for the user, but i would still want to create logs for debugging.
As well there is the issue of the user wanting to integrate my logs into the project itself.
and how will he be able to do that.
What would you recommend is the best way of doing this?
Thanks.
I think the normal way to do it, is not include the Log4j Jar in the package and let the library user to decide which version of Log4j to use.
Also you don't have to worry about where to output the log file, since the user will have its own log4j.properties or log4j.xml configuration.
The library user can also decide which level of logging to use from your library or whether to suppress it. For instance with Amazon AWS libraries, I can tell that I only want warning messages or the output will be too verbose. In that case I add to my log4j.properties:
log4j.logger.com.amazonaws=WARN
Said that, I'd also remind you that a modern alternative to log4j is SL4J.
Has anyone got SLF4J / logback to work with JBoss 7?
Previously, I was able to get my app to work in JBoss 5.1 by putting my "logback.groovy" in [server]/conf, and the logback core, classic (0.9.28), and Groovy (1.8.0) JARs in [server]/lib.
For JBoss 7.0.1, I've got the Groovy and logback modules set up OK (the .index files have been created), my EAR's MANIFEST.MF declares dependencies on both modules, and my "logback.groovy" is deployed in my WAR module's WEB-INF/classes, within my EAR. The EAR definitely deploys OK - lights are green...
Despite this, the only logging rules that actually get applied are the standard console/server.log ones set up in "standalone.xml". Yes, I can see my log statements (so SLF4J is working), but my logback rules, appenders, etc. are being ignored. There are no references to either logback or Groovy in any of that logging, so I'm assuming that I've not done enough to trigger logback's loading and finding my script.
There are other things I could try, but it would be good to know if other people have tried this. If they haven't, perhaps that's a sign that I should just throw in my lot with JBoss Logging?
Are you sure logback is active? If logback cannot find a configuration file, i.e. logback.groovy or logback.xml, it will print a warning message on the console. The output should be similar to:
12:49:22,078 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Setting up default configuration.
Do you see any such output on the console? If not, assuming that Jboss 7 is bundled with an slf4j-binding, you are probably already using Jboss logging. (Your calls to the slf4j api are being sent to jboss logging instead of logback.)
The Jboss folks should be contacted about using a logging backend other than jboss-logging.
Digging a little further, I noticed that JAS7 ships with a file called slf4j-jboss-logmanager-1.0.0.GA.jar located under the ./modules/org/slf4j/impl/main/ folder. The contents of this file show that it is definitely an slf4j binding. I do not know how Jboss "modules" work but removing/disabling slf4j-jboss-logmanager is the way to go if you wish logback-classic to be picked up by slf4j.
JBoss AS7 uses the jboss-logmanager. I assume that logback appenders would require a log manger that can handle them. I'm not really sure what would happen if you switched out the log manager.
There is support for custom java.util.logging.Handler's so you could write a wrapper for an appender in a handler. I know it's probably not ideal, but it should work.
I would encourage anyone to use JBoss Logging and not just because I work on it :-) It really does have some nice features, like var-arg log methods which is what drew me to it in the first place. There is also support for i18n logging and messages through interfaces.
Also JBoss Logging is more than just an API. It's a full logging framework. In the next release of JBoss Logging we will offer a way to specify which log manager you would like to use. That might make something like this a bit easier, but I must admit I have not tested in in AS7. If I get the time I will though.
I have some jar files that will be distributed to clients that are using log4j for logging. My question is should I include a log4j.xml configuration in the jar file or have the client provide one if they want logging?
My feeling is to leave the log4j.xml configuration file out of the client jars, since the apache jar files all come with log4j logging, but sans log4j.xml.
Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.
The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:
Obtain a logger object for the current class
Call one of the methods on that logger, such as debug("some message");
If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.
Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.
I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.
If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.
Let them decide what they need for their projects and worry about what you need for yours.
I would add the configuration xml and load it up with instruction for the user showing different configuration and options. This will make it easier for either them or support to enable addition logging.
I need a web interface for configure log4j that gives me:
CRUD of loggers, appenders and filters
when I am OK with the configuration I want to click and download an xml version of the configuration
hierarchical view of the configured loggers which expands as needed (nice to have).
I am aware of this old thread but I can't find the log4j-sandbox nor the ConfigurationServlet they were talking about.
The above mentioned files you can find here (ConfigurationServlet) and here (log4j-sandbox). Hope it helps.
Don't know myself of any log4j configuration generator. This blog entry has some kind of web interface you are partly looking for, but it's designed for SLF4J and Logback, the successor of log4j.