I am trying to create DB logging appender, ch.qos.logback.classic.db.DBAppender this one to be exact. But from what I read, the DB Appender functionality was dropped from Logback some time ago, with no guarantee when it will be back.
https://jira.qos.ch/browse/LOGBACK-1609
Now from what I read, there was a vulnerability in there. But not sure what, because I wasn't able to find any info on it?
Now from what I understand, the newer Spring Boot versions come with Logback 1.2.11, and DBAppender was supported till 1.2.8 i believe.
So my question is:
Is it safe to exclude the logback that comes with Spring Boot and use the older Logback without causing a risk?
Is switching to log4j the best option? That has had its own issues with security this year!
Related
I read somewhere that Spring Sleuth has performance impact. Whatever I read over internet are old posts.
Does anyone know whether with new version of Spring Boot this issue is resolved or it is still there.
In custom Spring Boot Autoconfiguration projects I usually have some dependencies which are marked as optional. As I need them for compilation, but expect users of my autoconfig to include them manually in their own POM, or they will be provided by the Spring Boot dependencies.
How do I ensure that users of different Spring Boot versions can use my autoconfig without dependecy/version problems?
I see two non-optimal solutions; are there more?
Hoping that the API stays the same
Just hope that the API of my dependencies stays stable over minor version changes, so that if I developed and compiled my Autoconfig e.g. with Spring Boot 1.4.x, the API which I used is still the same with 1.5.x, etc.
I then wouldn't necessarily expect it to work e.g. for Spring Boot 2.x, and would put a corresponding note into the readme.
Explicitly tracking each Spring Boot version
Explicitly build a version for at least each minor Spring Boot version, but possibly even for each Patch version? Who knows when a breaking API change could happen. I would then need to document for which exact Spring Boot version my autoconfig is intended. But this is a lot of work.
Of course Spring Boot's own autoconfig project is developed in lockstep with Spring Boot, so that any problems will be fixed in the same release.
But my own autoconfig might have been developed once and not expect many changes afterwards. How do I ensure that my autoconfig keeps working as long as possible even as the "users" of my autoconfig are updating their Spring Boot version dependencies?
Spring boot ships with several default logging framework configurations including Log4j2. While there is detailed documentation about logging in the Spring boot reference manual it does not mention how and where exactly the default log pattern is configured, which makes it difficult to override this.
The question is where does Spring Boot configure the default log pattern of for Log4j2?
So far I have looked in the following places of Spring Boot:
AutoConfigurationReportLoggingInitializer
LoggingApplicationListener
SimpleFormatter
LoggingSystem
Log4J2LoggingSystem
It seems the Log4J2 configuration is not done in any Java class so I was looking at the wrong place. Spring Boot ships with two files log4j2.xml and log4j2-file.xml which contain the default configuration and can be found in org.springframework.boot.logging.log4j2.
How to set the logging level of embedded tomcat in Spring Boot?
Especially I need to see the tomcat clustering-related logs.
I added the following line to the application.properties, but tomcat seems to log only INFO level logs.
logging.level.org.apache.catalina=TRACE
Is there a simple method to accomplish this?
It would be best to know the Spring Boot and embedded tomcat-specific, simple solution, preferably only editing application.properties.
In short, use Spring Boot version 1.3.0 with Logback. (I was using Spring Boot 1.2.4)
Spring Boot 1.3.0 adds LevelChangePropagator to LogbackLoggingSystem.java (see this commit), thus the logging level that is set in application.properties is propagated to the jul(java.util.logging) which tomcat uses.
Otherwise, one must set the logging level for the logger in the logging.properties for the jul if the level is below the INFO level which is the default, AND also set the logging level for the logger in the application.properties. This is for the limitation of jul-to-slf4j module which cannot completely override jul implementation since jul is in the java.* package.
Also see the following Spring Boot issues: Optimize JUL logging #2585, Slf4JLoggingSystem should also configure JUL levels #2923.
And this is the related StackOverflow question: Spring Boot - set logging level of external jar which is using Java Util Logging (jul). Actually this is the problem I was facing.
(I will accept this answer if no better answer is posted for a few days from now.)
I have recently upgraded spring boot from 1.1.10 to 1.2.0. I did not specify version information for spring boot dependencies like spring mvc. So they also got upgraded.
After upgrade, I am not able to see any log information from spring.
I am able to see the sysout and syserr information of my code though.
Did any thing change in the latest relese ?
As per the changelog Spring Boot 1.2.0 changelog Spring Boot's default behavior is to not write any log files.
Sorry folks, I have a log4j.properties in my class path. That configuration file prevented entries from springframework packages. Not sure how it ended up there though. Probably 1.1.10 is not picking it up. Things might have changed with 1.2.0. Hence the problem. Once I deleted that file, every thing is working fine
Thank you for your time