Unable to find the source which is setting logback properties - java

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

Related

who is reading logback.xml

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.

logging frameworks and logback.xml

While creating an example using Java and the com.alvazan.orm.api library, the use of "System.out.println" is prohibited.
One of the first and most simple Java exercises learned is "Hello World", also using the
"System.out.println" (...also known as logging, or returned requested data found in the console?)
When using Eclipse, logging is turned off by modifying the logback.xml file (ctrl-shift-R and typing in logback.xml)
From there;
<logger name="com.alvazan.orm" level="WARN"/>
is the line to add to the logback.xml file so that only startup logs appear.
In addition, two more logs such as....
2012-09-14 22:05:08,067 com.alvazan.test.FactorySingleton createFactory
INFO: CREATING FACTORY FOR TESTS
2012-09-14 22:05:08,809 com.impetus.annovention.ClasspathDiscoverer processFile
INFO: adding folder to scan=file:/C:/AAROOT/workareas/area1/playorm/eclipsegen/
are used.
Just clarifying that all information is typed into the logback.xml file?
Is there a diffrent file to use(other than logback.xml)?
Or is the end-user to use, for instance, "com.alvazan.test.FactorySingleton createFactory"; and "com.impetus.annovention.ClasspathDiscoverer processFile"?
Finalizing this question, is the file path for the preceeding necessary?
Thanks for your time,
Ryan
In response to Brett, and additional information/questions,
How is your root logger configured? You are only setting WARN for com.alvazan.orm, so if your root logger is INFO, then com.alvazan.test INFO's will be logged.
Hey Brett, thanks for the reply...
As for the root logger configuration, I believe the value is set at "INFO".
That being said, I would want to set "INFO" to "WARN", to prevent the use of
"System.out.println"
Also in the previous question, I mentioned:
2012-09-14 22:05:08,067 com.alvazan.test.FactorySingleton createFactory
INFO: CREATING FACTORY FOR TESTS
2012-09-14 22:05:08,809 com.impetus.annovention.ClasspathDiscoverer processFile
INFO: adding folder to scan=file:/C:/AAROOT/workareas/area1/playorm/eclipsegen/
com.alvazan.test.FactorySingleton
and
com.impetus.annovention.ClasspathDiscoverer (diffrent package within same library)
Different locations found within the same library...
Do i need to do the logback process for the other files, or *package, or doing it one time within the same library, should suffice for all? Or do I adjust additional values?
Your first statement....
"While creating an example using Java and the com.alvazan.orm.api
library, the use of "System.out.println" is prohibited."
In general, no one uses in System.out.println. Hibernate does not, JBoss does not, tomcat does not. They all use a logging framework so you can configure each and every log in production and each company using tomcat or jboss or hibernate can configure it differently. If these programs use System.out.println, customers would have no control and your server would ALWAYS run slow as you NEVER want "all" logging and there is no way to turn System.out.println's off!!!!! they are always on. log.info can be turned off and on.
The most complete answer on configuring logback can be found in their documentation
http://logback.qos.ch/manual/configuration.html
Just clarifying that all information is typed into the logback.xml
file?
I am not sure what you mean by this question. logback.xml is the configuration for a logging library called logback which you can find at the link above.
Is there a diffrent file to use(other than logback.xml)?
logback has other options like a groovy file to configure it, but playOrm is using only logback.xml though any client can decide what configuration file they use since playOrm discards the logback.xml file that is checked in when delivering to other projects.
Or is the end-user to use, for instance, "com.alvazan.test.FactorySingleton createFactory";
and "com.impetus.annovention.ClasspathDiscoverer processFile"?
I am very confused by this question. The end user should not be using FactorySingleton(neither directly nor indirectly AND that class is not even in the jar because it's in the test package). The end-user will be using ClasspathDiscoverer only indirectly...in fact, end-user won't even know about these classes.
Finalizing this question, is the file path for the preceeding necessary?
Are you trying to ask is the file path in logback.xml necessary? If you want to know more about how logback works, you need to read alot of the documentation. Basically, you can do stuff like com.alvazan level=WARN to turn any classes in com.alvazan.** to warn level(This is recursive and applies to children, grandchildren, etc. etc.). The ROOT logger is always defined as well in logback.xml and is the level for ALL classes in a all packages unless overridden.
yes, the root logger in playorm is set to warn.
At the bottom of the picture you show(your picture is cut off so not in that picture), there is a "source" tab and you may want to click that to view the xml better and it would match up with logback's documentation better as well. Here is a link to the file I bet you are looking at..
https://github.com/deanhiller/playorm/blob/486079cfefbd2b4b79e99652b24c146572663dda/input/javasrc/logback.xml
root logger is clearly set to info and could be set to warn if you want.
So, what do you want. Do you want those two log statements to go away and be turned off? Do you want ALL log statements to be turned off except WARN?
If you want all to be turned off in ALL software libraries, just change the root logger to "WARN". If you want to turn just FactorySingleton off you can add this line
<logger name="com.alvazan.test.FactorySingleton" level=""WARN"/>
If you want all of com.alvazan logging turned off instead of just everything in com.alvazan.orm as you also want com.alvazan.test off as well, BUT you want all other libraries to still be on(BUT always want WARN on which you generally should want), then you could change this
<logger name="com.alvazan.orm" level=""WARN"/>
to the following instead
<logger name="com.alvazan" level=""WARN"/>
Your best bet to understand logback though is to read logback documentation.
How is your root logger configured? You are only setting WARN for com.alvazan.orm, so if your root logger is INFO, then com.alvazan.test INFO's will be logged.

Change log4j settings in Camel TestSupport

I am debugging some jUnit tests that use the Camel TestSupport interface. This gives me access to a log4j log but I can't seem to figure out how to get a reconfigured version of that. I want to be able to change the log level since a lot of my logs are written in a trace level instead of just info or debug.
What is the best way to reconfigure this log's console output?
Thanks
You need to include a log4j.xml or log4j.properties on your classpath that you're using the test.
If you're using maven, this is easy, just put it in src/test/resources.

add logging to a utility package

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.

How do I view java log files in Eclipse

I am running some JUnit tests in Eclipse, and my code is generating an XML log file using the java logging APIs. (java.util.logging). Is there an easy way to view this XML log output in Eclipse, other than reading the raw XML? Specifically I want to be able to easily see what threads different log messages have come from.
I've been using the SLF4J logging API coupled with the Logback logging implementation. SLF4J can be configured to map log messages in the java.util.logging, log4j, jakarta commons logging, and SLF4j APIs into a common intermediate form. On the other side, the messages can be generated via java.util.logging, log4j, or Logback. It's a flexible approach that works well, especially when you have components that use different logging APIs.
One nice thing about Logback is that you can configure it to send a copy of the log messages to a an Eclipse plug-in. The plug-in and lets you view and filter the log file in a variety of ways. Messages contain the thread that generated them, so it sounds like something you should check out.
I think you were looking for the same thing I was looking for. I found UtilLogger4E, but I started my own project (EDevTools LogViewer), because it has some missing features and is not opensource.
It has the abilities to read Java Util Logging XML logs from a file or a configurable socket, display them colored by level in a table and it can show more than one log at a time (through multiple view instances).
Java Util Logging has a built-in feature to send logs to a socket (SocketHandler), it must only be set by the configuration file.
You can take a look at LogViewer at: http://sourceforge.net/projects/edevtools/
If you want to use log viewer which is not based on eclipse, I recommend you OtrosLogViewer. I can import java.util.logging XML format and SimpleFormat.
Disclaimer: I am the author of OtrosLogViewer
I was always hoping to find something like Apache Chainsaw for the java.util.logging/Eclipse combination, i.e. a log viewer in Eclipse that listens to a port and a java.util.logging.Handler implementation writing directly to that. But I haven't found such thing yet and didn't get around writing one either. So far I just use a suitable plain-text format to log to the console. Not elegant and no handy filtering options, but it does the job. Writing your own custom formatter is not hard at all.
There is some support for analyzing log files in Eclipse's Test and Performance Tools Platform Project (the name being even worse than the acronym). I never tried that, but it might be useful for you.
Just on the side, an excellent tool for viewing log files in real-time is baretail (essentially a tail -f on Windows), but can be set up to highlight certain patterns in colour which can really help. You can find a free version here.
Depending on exactly what you're trying to do you might just need a good logging setup for your logging sub sys?
A framework I've been using recently uses slf4j to log, by providing the following log4j config I get to see which threads output what:
log4j.rootLogger = trace, default
log4j.appender.default = org.apache.log4j.ConsoleAppender
log4j.appender.default.layout = org.apache.log4j.PatternLayout
log4j.appender.default.layout.ConversionPattern = %-4r [%t] %-5p %c %x - %m%n
In my case I get output similar to the following in the Console tab in eclipse when I run my junit tests.
0 [pool-1-thread-1] INFO com.example.BaseTest - Server listening on port 9090
35 [NioProcessor-6] INFO org.apache.mina.filter.logging.LoggingFilter - CREATED
35 [NioProcessor-1] INFO org.apache.mina.filter.logging.LoggingFilter - CREATED
I don't see how Eclipse can know about your threads. If it's XML, you need to write a parser that can find your thread messages using XPath and print them out. But that's up to you - Eclipse can't read your mind.
You'll have to find an XSL-T stylesheet that can take the XML stream produced by log4j and pull out the threads that you want.

Categories

Resources