I've been seeing weird square brackets and can't find and info on what there might be,
logs looking like that:
--2022-08-23 08:47:44.882 INFO [,,,] 30446 --- [)-192.168.0.165] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring DispatcherServlet 'dispatcherServlet'
--2022-08-23 08:47:44.882 INFO [,,,] 30446 --- [)-192.168.0.165] o.s.web.servlet.DispatcherServlet : Initializing Servlet 'dispatcherServlet'
--2022-08-23 08:47:44.922 INFO [,,,] 30446 --- [)-192.168.0.165] o.s.web.servlet.DispatcherServlet : Completed initialization in 40 ms
as you can see there are brackets with commas after log level, at some point info in the brackets change like this:
DEBUG [,080578da-b973-450b-9cae-2c5900ab56fe,080578da-b973-450b-9cae-2c5900ab56fe,]
can't really find what that could be, i'am using default spring boot logging pattern,
could it be wrongfully used MDC without redeclaring the logging pattern?
if it is MDC problem then why any value in the brackets look like this: 080578da-b973-450b-9cae-2c5900ab56fe
The logger I'm using is Slf4j
This could happen if you use Spring Cloud Sleuth. Spring Cloud Sleuth is a framework that adds the following to your logs:
The application name (from the spring.application.name property)
A trace ID (a unique ID for each user-initiated request)
A span ID (a unique ID for a unit of work)
These IDs can be used to correlate log messages in a distributed system (eg. microservices), because these IDs will be passed from microservice to microservice. In the documentation you can find an example of what this looks like.
In your case, you're not using these properties, which is why they're empty. The trace ID is automatically generated upon each request, which is why you sometimes see [,,] and [,XXX,].
If you're not interested in these trace/span IDs, you can remove the spring-cloud-sleuth or spring-cloud-starter-sleuth library.
Related
I have a spring boot app which uses spring data and hikaricp for db connection pooling. I noticed the following behaviour that looks strange to me:
I have one method which is not transactional and in that method several db queries are executed using spring data repositories
public void testMethod(final Long firstRepositoryId, final Long secondRepositoryId) {
final DomainObject result = firstRepository.findById(firstRepositoryId);
// here there's some code that is processing the result without db queries
secondRepository.findById(secondRepositoryId);
// some more logic here without additional db queries
}
So as expected when there's no transaction on the method then the spring data methods opens a transaction for executing the query and complete it after the methods returns. I have enabled transaction logging so there's the following log output:
2021-06-03 15:34:30.961 TRACE c681f76a-5d7e-41d5-9e50-fb6f96169681 --- [tp659271212-291] o.s.t.i.TransactionInterceptor : Getting transaction for [com.test.FirstRepository.findById]
2021-06-03 15:34:30.966 TRACE c681f76a-5d7e-41d5-9e50-fb6f96169681 --- [tp659271212-291] o.s.t.i.TransactionInterceptor : Completing transaction for [com.test.FirstRepository.findById]
2021-06-03 15:34:30.967 TRACE c681f76a-5d7e-41d5-9e50-fb6f96169681 --- [tp659271212-291] o.s.t.i.TransactionInterceptor : Getting transaction for [com.test.SecondRepository.findById]
2021-06-03 15:34:30.972 TRACE c681f76a-5d7e-41d5-9e50-fb6f96169681 --- [tp659271212-291] o.s.t.i.TransactionInterceptor : Completing transaction for [com.test.SecondRepository.findById]
Everything seems to be exactly how I expects to be. The thing I can't understand is the hikari behaviour. This method is invoked within a http request. A connection is taken from hikari cp right after the execution of the firstRepository.findById but this connection is returned in the pool only after the http controller returns response. What I expect is that a connection is taken after a transaction is opened and returned back after the transaction is completed. Is there something that I miss or maybe I have some wrong configuration?
P.S. I'm monitoring the active hikari connections through the spring boot actuator prometheus data. And to be able to reproduce the behavior I explained above I'm suspending the connection thread with several debug breakpoints.
I found out what causes this behaviour- it's Spring functionality to maintain the hibernate session in view in order to be able to retrieve lazy loaded data in the view. In order to disable this you need the following property:
spring.jpa.open-in-view=false
Here's another SO post where is explained what it does:
What is this spring.jpa.open-in-view=true property in Spring Boot?
Any help is appreciated. I have Spring Boot MVC application and have noticed some inconsistencies with my view being rendered. I am currently using Spring Boot starter parent with version 2.3.4.RELEASE, Spring Security and an embedded Tomcat Server and Kotlin (in eclipse. yes i agree that was probably a mistake because kotlin support in ecliplse is very lacking)
When mapping a Get Request with just a single /findData my application finds and renders the view correctly. Using a multipart /moreSpecific/findData url the application returns with a 404 not found for the jsp. I am not sure what the difference is but the application cannot find my jsp's based upon the requestMapping?
It is not failing with a 403 so I do not believe that it is a Spring Security issue
Application.properties
spring.mvc.view.prefix=WEB-INF/jsp/
spring.mvc.view.suffix=.jsp
RequestMappings / stack
#RequestMapping( value=["/findData"], method = [RequestMethod.GET])
fun get(): String {
return "findData"
}
2020-10-22 22:08:39.482 DEBUG 16376 --- [io-61558-exec-6] o.s.web.servlet.view.JstlView : Forwarding to [WEB-INF/jsp/findData.jsp]
2020-10-22 22:08:39.485 DEBUG 16376 --- [io-61558-exec-6] o.s.web.servlet.DispatcherServlet : Completed 200 O
#RequestMapping( value=["/moreSpecific/findData"], method = [RequestMethod.GET])
fun get(): String {
return "findData"
}
2020-10-22 22:08:39.482 DEBUG 16376 --- [io-61558-exec-6] o.s.web.servlet.view.JstlView : Forwarding to [WEB-INF/jsp/findData.jsp]
2020-10-22 22:08:39.485 DEBUG 16376 --- [io-61558-exec-6] o.s.web.servlet.DispatcherServlet : Completed 404 NOT_FOUND
I am truly confounded by this. Is this a tomcat behavior?
Context: after a recent springboot/spring migration, I've been scratching my head on why my HAL URLs were now returned as HTTP and not HTTPS anymore.
After investigation, this was related to some deprecated (and removed) property replaced by another one (ok, Intellij was doing a proper job and highlighted this)
server.use-forward-headers=true
#replaced by
server.forward-headers-strategy=native
Whereas I know you can validate your own properties set via your #ConfigurationProperties, its parameters or even your own JSR annotations, is there a way to validate "native" properties (server., spring., ...) at application startup and/or build?
UC1: I want to be sure I'm not using any unknown property (e.g. the property has been totally removed or is misspelt)
UC2: I want to be sure I'm not using any deprecated property
Approaches tried:
Searching for an existing property that would do the job
Overriding ServerProperties (sounds like a bad idea)
Using an existing FailureAnalyzer or defining a custom one
Thanks for your help!
You can rely on your IDE but it can only show you the configuration files that you are managing. Those properties are potentially set as environment variables in an specific environment or using a remote config server you don't have access to.
That's one of the reasons we're providing spring-boot-properties-migrator. It is referenced in the release notes.
Here is a sample demo app that yield the following:
2020-07-18 19:19:54.168 INFO 69898 --- [ main] com.example.demo.DemoApplication : Starting DemoApplication on taurus.lan with PID 69898 (/Users/snicoll/Downloads/demo-properties-migrator/target/classes started by snicoll in /Users/snicoll/Downloads/demo-properties-migrator)
2020-07-18 19:19:54.170 INFO 69898 --- [ main] com.example.demo.DemoApplication : No active profile set, falling back to default profiles: default
2020-07-18 19:19:54.545 INFO 69898 --- [ main] com.example.demo.DemoApplication : Started DemoApplication in 0.571 seconds (JVM running for 0.924)
2020-07-18 19:19:54.551 ERROR 69898 --- [ main] o.s.b.c.p.m.PropertiesMigrationListener :
The use of configuration keys that are no longer supported was found in the environment:
Property source 'systemProperties':
Key: server.connection-timeout
Reason: Each server behaves differently.
Property source 'applicationConfig: [classpath:/application.properties]':
Key: server.use-forward-headers
Line: 1
Reason: Replaced to support additional strategies.
Please refer to the release notes or reference guide for potential alternatives.
This will work for known properties (your use case) but it won't work for properties that are set and we don't know about (i.e. that don't have metadata). An obvious candidate in that set is typos of course but that's no longer an upgrade problem. Relying on your IDE to make sure that the property you introduce is legit sounds reasonable to me.
We'd like also to offer some validation for users that are adding properties without assistance, see this issue for more details.
I'm developing a REST API backend with Spring Boot for a single page application (Angular).
There's a lot of magic happening under the hood of Spring Boot which I don't understand yet. To achieve better security ("hardening"), I don't want Spring to install any superfluous service handlers used by Spring MVC or the like. Only REST endpoints consuming and producing JSON, no error-routes, no favicon.ico, etc. There is no static content (SPA is delivered by nginx and is a separate deployment unit).
During start the logging looks like this:
[19:04:06.146] INFO andler.SimpleUrlHandlerMapping [main]: Mapped URL path [/webjars/**] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
[19:04:06.146] INFO andler.SimpleUrlHandlerMapping [main]: Mapped URL path [/**] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
[19:04:06.190] INFO andler.SimpleUrlHandlerMapping [main]: Mapped URL path [/**/favicon.ico] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
How can I configure my application to exclusively serving the API endpoints and nothing else?
Yeah, spring boot does a lot of auto configuration under the hood. And usually the best place to start your search is documentation Appendix A. At least for me it feels so natural and easy to follow for most of the cases. You can probably solve your problem with application.properties
spring.mvc.favicon.enabled=false # Disable resolution of favicon.ico.
spring.resources.add-mappings=false # Disable default resource handling.
Btw, if it is not enough, most of the time there are also links to the source code of configuration classes. So you can override them if you actually need more complicated tuning.
I am using http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html#_adding_to_the_project for adding Spring Cloud Sleuth without the Zipkin integration
But in one of the microserives out of three, does not show the spanid, and token id in logs after adding dependency for all services (all are http request services, though there are couple of more services which require JMS - on which I need to work)
Service1
2016-06-05 17:12:45.404 INFO [my-service1-id,73b62c0f90d11e06,73b62c0f90d11e06,false] 85184 --- [nio-8080-exec-1] com.example.MyService1MakingARequest
Service2
2016-06-05 17:12:45.404 INFO 85185 --- [nio-8080-exec-1] com.example.MyService2MakingARequest
Service3
2016-06-05 17:12:45.404 INFO [my-service3-id,73b62c0f90d11e06,73b62c0f90d11e06,false] 85185 --- [nio-8080-exec-1] com.example.MyService3MakingARequest
Experts, Please suggest what can be done to see the effect in Service2
The best thing to do would be to show your sample project. Another is to check if you don't have a custom logback.xml or any other type of logging configuration that breaks the current set up (most likely you do cause I can see that the pattern is different).