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
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
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.
I've been trying to figure out what I'm missing with my RestTemplate setup (particularly OAuth2RestTemplate) so I want to see the logs for debugging. I found one possible solution for it, but nothing about the operation of the RestTemplate gets shown.
What I've done so far is to replace the default Logback logging mechanism in my Spring Boot app by following the configuration shown here. When I run my Spring Boot application after changing the logging dependencies, all I see on the console is the Spring logo (in ASCII) and nothing else. I've already defined a log4j-spring.properties in src/main/resources with the property defined in the previous link.
What else am I missing here? Do I need to run my Spring Boot app in debug mode? If so, how do I do that? Also, how do I set this up using the default Logback mechanism?
I am using Jetty http client in my application. I am also using SLF4J with LogBack.
How to set Jetty's overall logging level to INFO?
I have followed the instructions on Jetty's documentation to provide jetty-logging.properties file with contents like this:
# Configure Jetty for SLf4j Logging
org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.Slf4jLog
# Overall Logging Level is INFO
org.eclipse.jetty.LEVEL=INFO
Jetty is logging fine via SLF4J, but the LEVEL setting doesn't seem to work.
When I set the level from Logback configuration then it works, but I want my code to be logged in DEBUG level and Jetty in INFO level.
Jetty is very noisy in DEBUG level.
Any help is appreciated!
You need to set the Properties....
// change Jetty Logger
Properties p = new Properties();
p.setProperty("org.eclipse.jetty.LEVEL", "OFF");
org.eclipse.jetty.util.log.StdErrLog.setProperties(p);
I wasn't able to make Jetty to log at custom level. Because if Jetty finds SLF4J in my application then it will start using it with the logging level I have specified in logback.xml configuration file.
So I made a little hack. I specified Jetty to use Java Utils Logging and set level to INFO.
// Setting Jetty logger implementation and level (DEBUG | INFO | WARN | IGNORE)
System.setProperty("org.eclipse.jetty.util.log.class",
"org.eclipse.jetty.util.log.JavaUtilLog");
System.setProperty("org.eclipse.jetty.util.log.class.LEVEL", "INFO");
And for redirecting Java Utils Logging messages to SLF4J I used jul-to-slf4j-1.7.12.jar
That's how I got it working. If there is a better way I sure want to know.
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.