Charlie Reitzel
Charlie Reitzel
Been looking at this exact question recently. We wrote custom encoders for Logback and Log4j2 to provide standard logging contexts for all applications in our division (> 100 apps). It's...
> There is support for context also in reactive/non-blocking approach of processing. At least, project-reactor does have it: https://projectreactor.io/docs/core/release/reference/#context Exactly. What is missing is a logging API that will include...
We're currently evaluating GraalVM to reduce memory requirements and startup times. Our application is a family of a couple dozen REST services built using Spring Boot, plus a bunch of...
This is still happening. Any plans to fix this issue? Using the old configurations - compile, runtime, testCompile, testRuntime, etc. - brings the dependency classes into the fat jar. So...
@scpketer Did you see previous postings? Referring to the new style configuration name, `implementation`, as you suggest gives the error: ```> Resolving configuration 'implementation' directly is not allowed``` Using the...
> Did you see my code snippet? It _clearly_ seen that my snippet _enables_ direct resolving of `implementation` configuration. > > > project.configurations.implementation.canBeResolved = true Doh! :--) Thanks for clarifying...
Note: The nature of the 1st error was that I had a colon in a header description. Deleting the colon cleared the error and allowed `vs-openapi-designer` to correctly display the...
Thanks for getting back. > one of the `future` pointers can be changed to be a pointer to the properties. Got you. Will do.