Log4E replaces System.out.println, System.out.print, System.err.println, System.err.print and e.printStackTrace statements.
In the Preferences you can choose which logger level should be used.

Options:

  • Replace System.out
    If unchecked, the replacement of System.out's will be omitted.
  • Replace System.out with logger level
    Choose the level of logger.
  • Replace System.err
    If unchecked, the replacement of System.err's will be omitted.
  • Replace System.err with logger level
    Choose the level of logger.
  • Replace e.printStackTrace()
    If unchecked, the replacement of e.printStackTrace()'s will be omitted.
  • Replace e.printStackTrace() with logger level
    This setting is the same as Catch Block settings and is not configurable here.

Overview

The actions "Remove logger in this method" and "Remove logger of this class" automatically remove all logger statements in the method or class. On class scope the logger declaration and imports are removed, too. See also the screenshots.

Log4E needs to know which logger framework is used because it removes all statements defined in the logger framwork templates (Preferences:Templates).

See the screenshots for a quick overview.

Example:

Before:

import org.apache.log4j.Logger;
public class MyClass {
/**
* Logger for this class
*/
private static final Logger logger =
Logger.getLogger(MyClass.class);

public String myMethod() {
if (logger.isDebugEnabled()) {
logger.debug("myMethod() - start");
}
		//Your code... 
		try {

} catch (Exception e) {
logger.error("myMethod()", e);

//Your code...

if (logger.isDebugEnabled()) {
logger.
debug("myMethod() - othertext");
}

if (logger.isDebugEnabled()) {
logger.debug("myMethod() - end");
}
return "text";
}

String returnString = toString();
if (logger.isDebugEnabled()) {
logger.debug("myMethod() - end");
}
return returnString;
}
}
 

After:

public class MyClass {
public String myMethod() {
 		//Your code... 		
		try {

} catch (Exception e) {
//Your code...

return "text";
}

String returnString = toString();
return returnString;
}
}

 

A special case is when your code is woven into a is<Level>Enabled() statement. In that case Log4E pops up a warning that not all code can be removed. Only the logger statements without any user code can be removed.

Example:

Before:

import org.apache.log4j.Logger;
public class MyClass {
/**
* Logger for this class
*/
private static final Logger logger =
Logger.getLogger(MyClass.class);

public void myMethod() {
if (logger.isDebugEnabled()) {
logger.debug("myMethod() - start");
			// user code
System.out.println("");
}
}
}

After: 

import org.apache.log4j.Logger;
public class MyClass {
public void myMethod() {
if (logger.isDebugEnabled()) {
// user code
System.out.println("");
}
}
}

 

Overview

The action "Exchange logging framework of this class" automatically changes the actual logging statements of the actual logging framework to the target logging framework. Both logging frameworks has to be defined in the templates (Preferences:Templates).

See the screenshots for a quick overview. 

Example:

Before:

import org.apache.log4j.Logger;
public String myMethod(String theString, int theInt) {
if (logger.isDebugEnabled()) {
logger.debug(
"myMethod(String theString="
+ theString
+ ", int theInt="
+ theInt
+ ") - my message");
}

//Your code....
try {
doSomethingVeryDangerous();
} catch (Exception myexception) {
logger.error("myMethod(String, int)", myexception);
}

return toString();
}
 

After exchanging to JDK1.4 logging (logp):

import java.util.logging.Level;
import java.util.logging.Logger;

public String myMethod(String theString, int theInt) {
	if (logger.isLoggable(Level.CONFIG)) {
logger.logp(
Level.CONFIG,
"MyClass",
"myMethod(String theString="
+ theString
+ ", int theInt="
+ theInt
+ ")",
"my message");
}

//Your code....
try {
doSomethingVeryDangerous();
} catch (Exception myexception) {
logger.logp(Level.SEVERE, "MyClass", "myMethod(String, int)",
"", myexception);
}

return toString();
}

 

To analyse the existing log statement in source code, Log4E uses the accordingly template (defined in Log4E > Templates preference page)

Example 1

Assume the existing log statement is:

      debug("otherMethod() - starttext");

Therefore the accordingly template is:

      debug("${enclosing_method}${delimiter}${message}${delimiter}${return_value}")

Log4E makes a guess to map the tokens to the right variables. In this case, assuming that ${delimiter}=" - ", everything is alright. The mapping would be:

${enclosing_method}="otherMethod()"
${message}="starttext"
${return_value}=""

Only the ${message} is kept. Everything else will be replaced with the computed values. The result would be:

      debug("myMethod() - starttext");

To compute the right tokens Log4E uses the delimiter. If the delimiter, defined in the <a href="/preferences.html#Format">"Log4E > Format"</a> preferences, is different to delimiter used in the source code, Log4E won't be able to extract the user message.

Example 2

Assume the existing log statement is:

    debug("otherMethod() : starttext");

Therefore the accordingly template is:

      debug("${enclosing_method}${delimiter}${message}${delimiter}${return_value}")

In this case, assuming that ${delimiter}=" - ", the mapping would be:

${enclosing_method}="otherMethod() : starttext"
${message}=""
${return_value}=""

When Log4E recognizes that the ${message} is empty it will pop up a warning. The user can choose from there if he or she wants to start the Preview Wizard before confirming the changes.

If confirmed by user the result would be:

      debug("myMethod()");

Note that the logger statement "error("otherMethod()", e)" generated by Log4E doesn't have a message by default. Therefore Log4E will pop up a warning when performing modification even if the message must be empty in this case.

Example 3 (worst case)

Assume the existing log statement is:

    debug("starttext - otherMethod()");

Therefore the accordingly template is:

      debug("${enclosing_method}${delimiter}${message}${delimiter}${return_value}")

In this case, assuming that ${delimiter}=" - ", the mapping would be:

${enclosing_method}="starttext"
${message}="otherMethod()"
${return_value}=""

This is the worst case. Log4E does not recognize that the mapping is wrong because ${message} is not empty. Log4E would delete the exisitng message without a warning:

    debug("myMethod() - otherMethod()");

Abstract

The modification task is best used with Log4E generated log statements!

Joomla templates by a4joomla