SpringBoot 2.7 Overwhelming Logback 1.3 → not sweet but thirst quenching

Happy Moment

First thing in the morning, she sent me a message questioning me.
Her: Tell me the truth, where did you go last night to fool around?
Me: No, just a couple of guys having a drink.
Her: So why didn't you answer all the videos I called you?
Me: It's not convenient
Her: I don't believe it, what's so inconvenient about drinking with your buddies that you can't pick up a video?
Her: You must have another woman!
Me: Your husband is sitting right next to me, I dare you to answer it?

review of previous events

SpringBoot2.7 or capricious, just does not support Logback1.3, you can do anything about it! There's a lot to talk about, and it's summed up in two points

1. SpringBoot 2. depends on Logback 1. by default, does not support Logback 1.

   If you force Logback to upgrade to 1.0, an exception is thrown at startup.

   Exception in thread "main" : org/slf4j/impl/StaticLoggerBinder
   	at (:304)
   	at (:118)
   	at (:238)
   	at (:220)
   	at (:178)
   	at (:171)
   	at (:145)
   	at (:133)
   	at (:79)
   	at $starting$0(:56)
   	at (:1249)
   	at (:120)
   	at (:56)
   	at (:299)
   	at (:1300)
   	at (:1289)
   	at (:15)
   Caused by: : org.
   	at (:381)
   	at (:424)
   	at $(:331)
   	at (:357)
   	... 17 more
   

   The reasons have been analyzed.

   spring-boot-2.7.18 depends on org. and logback 1. does not have this class

2. SpringBoot 2. Support for Logback 1. is not out of the question, but there are some limitations and some unknown risks.

   Regarding the risk of the unknown, I'm sure we can all understand why, it's like starting with theJDK8 upgrade toJDK 11Why don't you dare to upgrade, a reason, because the big version of the upgrade, the change point is often more, and will even remove some of the contents of the low version, the compilation period is quite intuitive (we can adjust the code according to the reported error), if it is the runtime error that will be a headache, on the production of an accident, you dare to take the blame for this pot?
   So a big version upgrade means that we not only have to fix compile-time errors, but also have to conduct full-scale testing to cover all scenarios as much as possible to rule out any anomalies that may exist during runtime. It's fine if the business is simple, but if the business is very large, this full range of testing is going to take a lot of time, and not only will the developers be spitting in their mouths, but the tests will be too!mmp
   Upgrade to SLF4J 2.0 and Logback 1.4 Having had some discussion.wilkinsona(Spring Boot's current Contributor's List I) mentions some of the risks.

   

   There's a lot of discussion in there thatLogback Contributor to the list of the first big brotherceki It also has a lot of explanations and Q&A in it, so if you're interested, you can take a look at it in detail.
   In short: SpringBoot 2. can support Logback 1. by tweaking the configuration, but at our own risk!

Thinking about it in a different way, we should be able to understandSpring Boot formal

1. treat (sb a certain way)Logback Not that familiar, only throughLogback The official statement knows the points of change (can it be guaranteed that everything is listed?). If there are too many changes, it's impossible to check every single one of them.
2. Spring Boot It's so huge and integrated with so many features that even Pyoichi can't memorize all the details (we can't guarantee that we know all the details of the projects we're responsible for), so there's no way to evaluate the upgrade to theLogback 1. What points will be affected

So seek stability.Spring Boot Not intended to be integratedLogback 1.
However, if we are also capricious and have to twist this melon.Spring Boot Is there nothing we can do about it?

lit. the king is hard-wired for bowing (idiom); fig. to dominate and force others to do the same

Referring to this, let's configure

1. clotureSpring Boot (used form a nominal expression)LoggingSystem

   @SpringBootApplication
   public class Application {
   
       public static void main(String[] args) {
           ("", "none");
           (, args);
       }
   }
   

2. Configuration files are created with the

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
       <property name="LOG_FILE" value="/logs/spring-boot-2_7_18.log"/>
       <property name="FILE_LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:}|%level|%t|%line|%-40.40logger{39}:%msg%n"/>
   
       <!-- Generate log files on a daily basis-->
       <appender name="FILE" class="">
           <encoder class="">
               <pattern>${FILE_LOG_PATTERN}</pattern>
           </encoder>
           <file>${LOG_FILE}</file>
           <rollingPolicy class="">
               <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.zip</fileNamePattern>
               <maxHistory>30</maxHistory>
           </rollingPolicy>
       </appender>
   
       <!-- Console Output -->
       <appender name="STDOUT" class="">
           <encoder>
               <pattern>${FILE_LOG_PATTERN}}</pattern>
           </encoder>
       </appender>
   
       <root level="${loglevel:-INFO}">
           <appender-ref ref="STDOUT" />
           <appender-ref ref="FILE" />
       </root>
   </configuration>
   

The startup did work, we added some simple business logs and found that the logs were also outputting normally

2024-07-26 16:46:48.609|INFO|http-nio-8080-exec-1|525| :Initializing Servlet 'dispatcherServlet'
2024-07-26 16:46:48.610|INFO|http-nio-8080-exec-1|547| :Completed initialization in 0 ms
2024-07-26 16:46:48.632|INFO|http-nio-8080-exec-1|23| :hello interface entry: lapis lazuli road
2024-07-26 16:46:50.033|INFO|http-nio-8080-exec-3|23| :hello interface inbound: lapis lazuli road
2024-07-26 16:46:50.612|INFO|http-nio-8080-exec-4|23| :hello interface inbound: lapis lazuli road
2024-07-26 16:46:51.150|INFO|http-nio-8080-exec-5|23| :hello interface inbound: lapis lazuli road
2024-07-26 16:46:51.698|INFO|http-nio-8080-exec-6|23| :hello Interface inbound: Lime Rock Road
2024-07-26 16:46:52.203|INFO|http-nio-8080-exec-7|23| :hello Interface: Castle Rock Road

The log file writes fine.

It's not only thirst-quenching, it's sweet.

But don't be too sweet, this is just ademo：spring-boot-2_7_18No business code, simple can not be more simple, if you use this to judge the sweet or not sweet, that would be a big mistake; applied to the project, not only to ensure that the normal startup, but also to ensure that all the existing business can run normally, as for the business in the plan, it will be in the future to talk about who knows which one of the tomorrow and the accident came first, seriously live the present moment!
Initial attempts, it works, so go ahead and give it a shot, but do a good job of testing the full range of business

wilkinsona Mentioned. Closed.Spring Boot (used form a nominal expression)LoggingSystem After using theLogback The configuration file must be the default configuration of the And it can't be.Although the words of the first big brother of the list are very authoritative, but we main a capricious, just want to come to try to, what would be the result of directing the renameIt will start up, but there are a bunch ofdebug Logs, with a focus on

Logs not written to file

wilkinsona I'm not kidding!

principle analysis

It's closed.Spring Boot (used form a nominal expression)LoggingSystem After that, logging is left to the sole discretion of theLogbackAnd as for theLogback I did write a post detailing the configuration file loading of theUnderstanding slf4j bindings from the source code, and logback's loading of configuration files, jumping straight to the summary section, there's this paragraph

During compilation, complete the binding of slf4j and the loading of the logback configuration file. slf4j will look for org/slf4j/impl/ (which will exist in specific logging frameworks such as log4j, logback, etc.) in the classpath, find and complete the binding; at the same time, logback will also look for the configuration file, first look for, no then look for, if there is no, then look for, if there is still no, then look for, if not even there, then there is no configuration logback configuration file, then logback will enable the default configuration (log messages will only be printed on the console)

althoughLogback be1.1.17Instead of1.3.14, but the loading of the configuration file should be unchanged

Notice how I worded it: should, so that even if it changes, you can't say anything about me, because I said should

To be on the safe side, you guys should check out the 1.3.14 source code!

This is why the configuration file is The logs are written to the file normally when the The reason why the log cannot be written to the log file when theLogback don't recognize，Spring Boot Just recognized!
go so far as toSpring Boot LoggingSystem Well, I'll talk to you when I've mastered it, so be sure to wait for me.

summarize

Spring Boot default dependencyLogback 1.Not supportedLogback 1.But by setting the

("", "none");

that does not report errors at startup, combined with the, the logs are able to be written to the log file normally; however, to be on the safe side, it is still not recommended to upgrade to theLogback 1.

Don't move if you can't move, change good no performance, change the problem to take the blame, it's hard work, and it's not like you can't run.

If you must upgrade, then do full testing to cover all business scenarios