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?
Related
I am working in spring boot project and I stuck in an issue. Following is the problem.
I have two log4j2 configuration file. Log4j2-1.yml and Log4j2-2.yml. Log4j2-1.yml consist the common configuration to avoid repetition duplicate configuration while Log4j2-2.yml consists application specific log config. I need to use these two log4j2 configuration in my application at same time. Please help me to configure these files in my application.\
I tried log4j2.configurationFile also but could not succeed.
Spring Boot has a custom logging configuration process that occurs just after the Log4j2 automatic configuration (its exact logic is in Log4j2LoggingSystem and is documented in Core Features). You can analyze the process by setting -Dlog4j2.debug=true.
To create a composite configuration you need to use two Spring Boot properties (cf. core properties):
logging.config=classpath:Log4j2-1.yml
logging.log4j2.config.override=classpath:Log4j2-2.yml
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
How can I put into spring boot app properties logback-file.xml and logback-access.xml at the same time? And if I can, logs will write in one file, or in different?
See the available Spring Boot properties.
You will find generic logging.* ones as well as server.tomcat.accesslog.* OR server.jetty.accesslog.* depending on your embedded servlet container.
Core logs will be printed based on logback-spring.xml, and access-logs (logs written whenever someone accesses any of your API's) will be printed based on logback-access.xml.
In application.properties, use logging.* for core/server logs and server.(yourserver).accesslog.* for access logs.
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 have been prototyping with Spring boot where I added dependency on spring-boot-starter-actuator and spring-boot-starter-data-rest and named my testing REST endpoint to /info. Application ran without any errors however my endpoint couldn't be called and app returned 404 all the time.
After some time I found out that actuator project contains SAME endpoint /info and basically overrides my custom RESTful endpoint since I didn't name it.
My question is: Is there any way how I can prevent such behavior in general (meaning bean clashing by mistake)? Or at least get WARN message when this is happening.
Thanks in advance for your answers
You can disable /info actuator endpoint by using the following property;
management.endpoint.info.enabled=false
Actually all can be disabled, or you can enable only certain ones, if you check the source link I've provided below;
By default, all endpoints except for shutdown are enabled. If you prefer to specifically “opt-in” endpoint enablement you can use the endpoints.enabled property.
source
For logging of this behaviour, while deploying you can see the endpoints and corresponding beans, you can deduce from this log I guess. But better not to use same endpoint with actuator while they are enabled.
Yes, there is a chance to disable particular classes by #EnableAutoconfiguration with a parameter exclude= where you can specify classname or whole package by using {} brackets
Example:
#EnableAutoConfiguration(exclude = {MyClassName.class}
#EnableAutoConfiguration(exclude = {MyClassName.class, MyClassName2.class})