is there any difference between debug=true and logging.level.root=debug , both are specified in application.properties file of spring boot application.
Below are references for both from spring boot documentation, unfortunately there they don't show any link between them but it looks like they serve same purpose.
https://docs.spring.io/spring-boot/docs/2.6.6/reference/htmlsingle/#features.logging.console-output
https://docs.spring.io/spring-boot/docs/2.6.6/reference/htmlsingle/#features.logging.log-levels
When you set debug=true a bunch of "core" loggers used under the hood by spring boot will be set to debug: web container (like a tomcat), spring boot itself, hibernate.
It won't affect the loggers of your application though - they'll still be at INFO severity level.
However, if you set something like logging.level.root=debug probably all the loggers will be set to DEBUG, so yes, technically there is a difference.
From the spring boot documentation:
When the debug mode is enabled, a selection of core loggers (embedded container, Hibernate, and Spring Boot) are configured to output more information. Enabling the debug mode does not configure your application to log all messages with DEBUG level.
Related
I am using Couchbase SDK along with Spring boot 2.6.x version. I am using the spring spring-data-couchbase:jar:4.4.0 which in turn has com.couchbase.client:java-client:jar:3.3.0 dependency. The issue, is when trying to execute cluster.query() methods, I need to see what query is getting executed. I need to enable debug logs. However, I have tried configuring it under properties for logging.level for the package com.couchbase.client to DEBUG level, nothing is showing up. I tried the similar config in log4j.xml as well and no luck either. Does couchbase uses any wierd property or is it not reading the properties specified from either log4j or spring's properties?
You may ask if raw query is passed then why log specifically, but this is required if using parameterised queries and to debug it.
How does one enable logging for couchbase if using plain sdk methods under spring's context ?
Can you enable couchbase specific properties of spring-data and not package within the application?
logging:
level:
org.springframework.data.couchbase.repository.query: DEBUG
This should help ! It won't require any external dependency or logging solutions
For the cluster, add ServiceType.QUERY to captureTraffic...
env.ioConfig(it -> it.captureTraffic(ServiceType.QUERY))
and also set the log level for the com.couchbase category to TRACE
I created a Spring Boot application utilizing Camel. In a route I am using the Log component as follows:
from("direct:start")
.log(LoggingLevel.DEBUG, "com.somepackage","Request: ${body}")
.process(myProcessor)
.log(LoggingLevel.DEBUG, "com.somepackage","Response: ${body}");
In my application.yml I have set up logging as follows:
logging:
level:
com.somepackage: INFO
When I start the application the logging doesn't happen due to it being a lower level. Using the Spring Boot Actuator to change the level:
(POST) /actuator/loggers/com.somepackage
Request:
{
"configuredLevel": "DEBUG"
}
and then verify the change:
(GET) /actuator/loggers/com.somepackage
Response:
{
"configuredLevel": "DEBUG",
"effectiveLevel": "DEBUG"
}
But the logging still does not happen. It does not happen even when level set to TRACE.
However if I set the logging level in the application file to DEBUG and then compile/run the application the logging for that Log component happens and it is responsive. I can set the level higher to exclude or lower to include using Actuator.
The standard logging of Spring Boot is responsive to the log level changes from the Actuator no matter what the level is set to in the application file but the Camel Log component is responsive only if the level set in the Log component is equal to or higher at startup. Anyone have a thought or solution on this?
I got the same error and tried a few other camel versions. camel 3.5.0 and below worked for me.
Edit:
I opened a bugticket https://issues.apache.org/jira/browse/CAMEL-16705
It will be fixed in Version 3.11.0
I have a Spring boot (v1.5.9) based application with Jolokia provided by Spring boot actuator.
Jolokia works fine. I can read values, for example:
http://localhost:8080/jolokia/read/java.lang:type=ClassLoading/Verbose
gives me:
{"request":{"mbean":"java.lang:type=ClassLoading","attribute":"Verbose","type":"read"},"value":false,"timestamp":1527859447,"status":200}
What I want is to disable writing operations, for example:
http://localhost:8080/jolokia/write/java.lang:type=ClassLoading/Verbose/true
The spring boot configuration looks like this:
management.security.enabled=false
management.endpoints.jmx.exposure.exclude=*
management.endpoints.web.exposure.include=jolokia,metrics
management.endpoint.jolokia.config.policyLocation=classpath:/jolokia.xml
And the Jolokia's policy in WEB-INF\classes\jolokia.xml (in resulting war, according to https://jolokia.org/reference/html/security.html) contains:
<restrict>
<commands>
<command>read</command>
<command>list</command>
<command>version</command>
<command>search</command>
</commands>
</restrict>
Despite this I see the following note in application's log:
jolokia: No access restrictor found, access to any MBean is allowed
And the write operation from the example above is working fine.
What I'm doing wrong? Should I put the policy file somewhere else? Is it possible to configure Jolokia's policy directly from the Spring boot configuration?
It looks like you've inadvertently used Spring Boot 2.0 configuration properties with Spring Boot 1.5.x. In 1.5 you should use jolokia.config.policyLocation. There's a little more information in the reference documentation.
I am building a Spring Boot web application deployed to Tomcat which builds a DataSource bean using JNDI.
I have the following entry in application.properties to prevent a duplicate DataSource MBean from being created in JMX
# Prevent Spring from automatically exposing beans to JMX. Tomcat automatically creates an MBean when setting the
# JNDI data source, and an error gets thrown if spring then tries to add the data source MBean itself.
spring.jmx.enabled=false
But my question is this: there is a property called spring.datasource.jmx-enabled that is set to false by default. This seems like a fine grained setting that should disable only DataSource MBeans from being exposed by Spring, right? But that is not the case. Unless I disable all JMX, the DataSource MBean will be duplicated.
in a Spring Boot application, I am worried about AutoConfigurations also being triggered by transitive dependencies.
Specific autoconfigurations can be switched off as described here Disable Spring Boot AutoConfiguration for transitive dependencies
But how can I know which AutoConfigurations have been activated? There does not seem to be a consistent logging of activations on startup. I just noticed VelocityAutoConfiguration has been activated in my application, I can disable that, but it makes me worried about other autoconfigurations being activated without my knowledge and intent.
Definitely pay attention to those transitive dependencies.
There's about 5 or more different ways you can enable or view the #EnableAutoConfiguration report. The report will show you:
what's enabled
what's disabled
what's excluded
configurations that are unconditional
As an application argument
--debug
As a VM argument
-Ddebug
As an environment variable
export DEBUG=true // UNIX based
set DEBUG=true // Windows based
By adding a property to your application.properties
debug=true
Adjusting the log level in your application.properties
logging.level.=debug
Adjusting the log level of the report generator class in your application.properties
Spring Boot 1.x
logging.level.org.springframework.boot.autoconfigure.logging.AutoConfigurationReportLoggingInitializer=debug
Spring Boot 2.x
logging.level.org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener=debug
Starting your application with --debug will log an auto-configuration report that shows every auto-configuration class that was considered during startup and whether or not it was activated. Every class listed as a positive match has been activated and every class listed as a negative match has not been activated.
If your application's using Spring Boot's Actuator (it has a dependency on org.springframework.boot:spring-boot-starter-actuator), then, as mentioned in the question comments, you can also access the report over HTTP using the /autoconfig endpoint.