As you know, there is one way to achieve this easily by writing Java code, catch the logger and update the logging level. This is what I called: Programmatically!
But there is another way, when you already have Log4J in your WebApp, just like this:
Just add one additional param to your web.xml, besides log4jConfigLocation
By doing this, the Listener will refresh the Log4J configuration each 2 seconds.
Showing posts with label Log4J. Show all posts
Showing posts with label Log4J. Show all posts
Friday, July 15, 2011
Wednesday, June 1, 2011
Log4J: Properties and XML
Personally I prefer the XML instead of the properties file, but...
On this case I was having some trouble with my App server (WebLogic) - it wasn't loading my log4.xml, so I had to come up with a workaround: by using a propeties file.
This is more a look and learn than look and follow this steps. Because by looking to my XML file you'll see the equivalent in properties file, maybe this will help you when you have to write one or another.
On this case I was having some trouble with my App server (WebLogic) - it wasn't loading my log4.xml, so I had to come up with a workaround: by using a propeties file.
This is more a look and learn than look and follow this steps. Because by looking to my XML file you'll see the equivalent in properties file, maybe this will help you when you have to write one or another.
Wednesday, May 18, 2011
Log4jConfigListener Deployment Issue on WebLogic
It looks like Spring framework's Log4jConfigListener is having an issue when webapp is deployed as WAR.
Log4jConfigListener is defined in web.xml. I got the below error while deploying the application in weblogic 10.3:
The solution is deploy the WAR as exploded or don't use Log4jConfigListener. The spring framework documentation also says the WAR should be exploded.
But... there is a solution available to this without any code change. We just need to set "Archived Real Path Enabled" option checked, just like this:
1. Go to server admin console->Domain-> Web applications. Click the checkbox of Archived Real Path Enabled. This should make an entry into domain config.xml as below. 2. Second option is at webapp level by updating weblogic.xml as below:
true
The value of set in the web app has precedence over the value set at the domain level. The default value of this property is false.
This is my example:
Log4jConfigListener is defined in web.xml. I got the below error while deploying the application in weblogic 10.3:
weblogic.management.DeploymentException: Cannot set web app root system property when WAR file is not expanded - with nested exception: [java.lang.IllegalStateException: Cannot set web app root system property when WAR file is not expanded].
The solution is deploy the WAR as exploded or don't use Log4jConfigListener. The spring framework documentation also says the WAR should be exploded.
But... there is a solution available to this without any code change. We just need to set "Archived Real Path Enabled" option checked, just like this:
1. Go to server admin console->Domain-> Web applications. Click the checkbox of Archived Real Path Enabled. This should make an entry into domain config.xml as below. 2. Second option is at webapp level by updating weblogic.xml as below:
This is my example:
Wednesday, September 8, 2010
Log SQL Statements on Hibernate
Hibernate, in the end, is all about dispatching SQL statements. SQL is at the heart of communication with an RDBMS system, and it is extremely important when struggling through performance problems or other bugs, that you know what is going on. After all, knowing the executed SQL allows you to determine the number of queries to complete an O/R mapping task, not to mention that seeing SQL queries is critical to understanding how to optimize the queries via indices and other database settings.
There are two ways (due to the legacy of Hibernate) to enable SQL logging. The first is to simply enable SQL logging in the Hibernate configuration By setting the hibernate.show_sql to TRUE
This is a nice quick and dirty solution, but it is relatively inflexible. SQL statements are always logged to System.out when that property is enabled, and on some servers, System.out isn't accessible by the average developer; or is cluttered with a million other log statements.
Alternatively, Hibernate uses the Apache-Jakarta Commons Logging package, which means that it will utilize log4j , java.util.logging , or potentially another logging framework. Typically, log messages are sent to commons logging, and then they are dispatched to one of these logging frameworks. Then, those logging frameworks determine where the message should be sent (log files, sockets, emails, database records, system out, system err, etc). It is easy to see how using these log frameworks will increase the flexibility of log statements. With Hibernate, simply setting the org.hibernate.SQL logger to 'DEBUG' or 'ALL' will ensure that all SQL statements are logged to the console.
If you set up a log4j category for org.hibernate.type
Get it to write out to the same log file as the org.hibernate.SQL
The type one will list the parameters for you after the SQL e.g.
There are two ways (due to the legacy of Hibernate) to enable SQL logging. The first is to simply enable SQL logging in the Hibernate configuration By setting the hibernate.show_sql to TRUE
This is a nice quick and dirty solution, but it is relatively inflexible. SQL statements are always logged to System.out when that property is enabled, and on some servers, System.out isn't accessible by the average developer; or is cluttered with a million other log statements.
Alternatively, Hibernate uses the Apache-Jakarta Commons Logging package, which means that it will utilize log4j , java.util.logging , or potentially another logging framework. Typically, log messages are sent to commons logging, and then they are dispatched to one of these logging frameworks. Then, those logging frameworks determine where the message should be sent (log files, sockets, emails, database records, system out, system err, etc). It is easy to see how using these log frameworks will increase the flexibility of log statements. With Hibernate, simply setting the org.hibernate.SQL logger to 'DEBUG' or 'ALL' will ensure that all SQL statements are logged to the console.
If you set up a log4j category for org.hibernate.type
Get it to write out to the same log file as the org.hibernate.SQL
The type one will list the parameters for you after the SQL e.g.
2006-07-28 09:57:12,061 DEBUG org.hibernate.SQL - insert into BASKET_LINE_ALLOC (LAST_UPDATED, QUANTITY, CUSTOMER_REF, NOTES, BRANCH_ID, FUND_ID, TEMPLATE_ID, BASKET_LINE_ALLOC_ID) values (?, ?, ?, ?, ?, ?, ?, ?) 2006-07-28 09:57:12,081 DEBUG org.hibernate.type.TimestampType - binding '2006-07-28 09:57:12' to parameter: 1 2006-07-28 09:57:12,081 DEBUG org.hibernate.type.IntegerType - binding '3' to parameter: 2 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding '' to parameter: 3 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding '' to parameter: 4 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '511' to parameter: 5 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '512' to parameter: 6 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding null to parameter: 7 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '180030' to parameter: 8
Tuesday, August 17, 2010
Log4J tips
Add thread name to my log file; sometimes we want to know which thread is being executed, well, try this:
ConversionPattern=%d [%5p] [%t] %c{1}.%m%n
That's right just by adding "%t", you can see which thread is doing what.
ConversionPattern=%d [%5p] [%t] %c{1}.%m%n
That's right just by adding "%t", you can see which thread is doing what.
Subscribe to:
Posts (Atom)