[ 
https://issues.apache.org/jira/browse/LOG4J2-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146176#comment-14146176
 ] 

Remko Popma commented on LOG4J2-824:
------------------------------------

Did you have a chance to take a look at this? Did the code gen tool work for 
you?

> How to delegate logging to a utility class in Log4j2
> ----------------------------------------------------
>
>                 Key: LOG4J2-824
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-824
>             Project: Log4j 2
>          Issue Type: Question
>          Components: API, Core, Documentation
>    Affects Versions: 2.0
>            Reporter: Christopher Knight
>            Priority: Critical
>              Labels: documentation, features, newbie
>             Fix For: 2.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Hi,
> I'm in the process of migrating from log4j1.2 to log4j2 and very excited to 
> test out the great new features that you folks have added (like 
> AsyncLogging).  On the whole the migration has gone well but I have one 
> concern with my approach.
> {panel:title=My 
> Remit|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> To have a single utility class in my application that does all the logging - 
> at no point should any third-party imports appear outside of my utility 
> class.  The utility class must not appear as the logging location in the log 
> output  instead the calling class and method must be listed.  This was very 
> easy in log4j1.2 but I can't find a good solution in Log4j2 and I'm sure its 
> just my understanding of the new API that is at fault, any help is greatly 
> appreciated.  Examples code below to hopefully explain what I do in my 
> current application and what I'd like to continue doing after adopting Log4j2.
> {panel}
> Here's a cut-down version of what I currently do in Log4j1.2
> {code:title=Log4j1.2 Version|borderStyle=solid}
> public final class ApplicationLogger {
>     
>     private static Logger logger = Logger.getLogger(ApplicationLogger.class);
>     private final String LOG_WRAPPER_CLASS_NAME = 
> ApplicationLogger.class.getName();
>       
>     private ApplicationLogger(){}
>       
>     public static void error(String message, Throwable throwable) {
>        logger.log(LOG_WRAPPER_CLASS_NAME, Level.ERROR, message, throwable); 
>     } 
>       .....
> }
> public class TestLogging {
>   public void testlog(){
>       try {
>               throw new Exception("testing123")
>       }catch(Exception ex){
>               ApplicationLogger.error("Log Test", ex);
>       }
>   }
> }
> {code}
> The above code will make sure the "ApplicationLogger" class is never part of 
> the log statements so that we know where the log statement was called from - 
> I'm not sure what this technique is called but its invaluable to me.
> After much stumbling around I managed to get Log4j2 to yield to my will...
> {code:title=Log4j2 version|borderStyle=solid}
> public final class ApplicationLogger {
>     
>       private static ExtendedLoggerWrapper logger = new 
> ExtendedLoggerWrapper((AbstractLogger)LogManager.getLogger(ApplicationLogger.class),"ApplicationLogger",LogManager.getLogger(ApplicationLogger.class).getMessageFactory());
>       
>       private ApplicationLogger(){}
>       
>     public static void error(String message, Throwable throwable) {
>          logger.logMessage(ApplicationLogger.class.getName(), Level.ERROR, 
> null, new SimpleMessage(message), throwable);
>     } 
>       .....
> }
> public class TestLogging {
>   public void testlog(){
>       try {
>               throw new Exception("testing123")
>       }catch(Exception ex){
>               ApplicationLogger.error("Log Test", ex);
>       }
>   }
> }
> {code}
> Although it works it looks terrible and I suspect its not right or will 
> perform badly.  Is there a correct way to do this or a better way, I'm open 
> to any option that keeps to my original remit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to