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

Ralph Goers edited comment on LOG4J2-3388 at 2/3/22, 6:42 AM:
--------------------------------------------------------------

Ultimately you will want to migrate fully to log4j2. Using the log4j 1.x bridge 
can be used to help you start the conversion but should not be where you end up.

If you have a lot of applications and log4j configuration files then using the 
bridge is a good choice just to get the log4j 1.x jar out of the picture. 
However, it is quite possible you may not even need your custom extensions in 
Log4j 2. If you can describe what your extensions are for we can probably 
advise you on the best approach. For example, many people extended 
PatternParser to add their own pattern converters. That is not necessary in 
Log4j 2 as all PatternConverters are plugins in Log4j2 and are detected 
automatically. 

There are at least 36 Jira issues related to the 1.2 migration bridge being 
resolved in the upcoming release which should help address many of the issues 
with using the classes you mention, but it may not address them all. 

I should note that if you do implement your own Appender be aware that most 
Log4j 2 Appenders follow a pattern of having the Appender use a Manager. The 
reason for this is that during reconfiguration if the new configuration 
includes the same target destination then Log4j will reuse the Manager from the 
previous configuration. This means certain aspects of the appender cannot be 
reconfigured but it also means events will not be lost during reconfiguration.


was (Author: ralph.go...@dslextreme.com):
Ultimately you will want to migrate fully to log4j2. Using the log4j 1.x bridge 
can be used to help you start the conversion but should not be where you end up.

If you have a lot of applications and log4j configuration files then using the 
bridge is a good choice just to get the log4j 1.x jar out of the picture. 
However, it is quite possible you may not even need your custom extensions in 
Log4j 2. If you can describe what your extensions are for we can probably 
advise you on the best approach. For example, many people extended 
PatternParser to add their own pattern converters. That is not necessary in 
Log4j 2 as all PatternConverters are plugins in Log4j2 and are detected 
automatically. 

There are at least 36 Jira issues related to the 1.2 migration bridge being 
resolved in the upcoming release which should help address many of the issues 
with using the classes you mention, but it may not address them all. 

> Migration from log4j1.x to log4j2.x
> -----------------------------------
>
>                 Key: LOG4J2-3388
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3388
>             Project: Log4j 2
>          Issue Type: Question
>            Reporter: Janardhan Naidu
>            Priority: Major
>
> We are planning to upgrade log4j1.x to log4j2.x.
> So we went through the migration document: 
> [https://logging.apache.org/log4j/2.x/manual/migration.html] 
> in the above document, It says that (They must not access methods and classes 
> internal to the Log4j 1.x implementation such as Appenders, LoggerRepository 
> or Category’s callAppenders method.) 
> and In our product, currently we are using log4j1.x and we are extending some 
> of the log4j1.x classes like PatternParser, FileAppender etc... which were 
> made final in log4j2.x  so can we make use of Log4j 1.x bridge.?  If yes how 
> we can do that.
>  
> what could be the better option to migrate log4j 1.x to log4j 2.x as we are 
> making use of log4j internal classes? 
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to