The code-base I work with has a working OAuth model that uses OAuth2RestTemplate to manage access-tokens & access-token requests. As OAuth2RestTemplate is deprecated, I want to move to Spring Security OAuth & WebClient.
When I looked at some of the classes involved, I was surprised to see that OAuth2AccessTokenResponseClient does not return a Mono, and the default implementation - DefaultPasswordTokenResponseClient - uses RestTemplate internally.
I thought one of the primary advantages of WebClient was that it was non-blocking? If that is the case, why is blocking I/O one of the default strategies for requesting access-tokens? From the perspective of someone new to reactive/WebClient, I do not understand why the OAuth2AccessTokenResponseClient isn't itself a WebClient instance.
If I try to write a custom filter that uses WebClient to request the token, will I encounter major roadblocks or hard-to-detect bugs? I do not have much knowledge to build off in this area but would still appreciate if someone could try to help out.
You are wrong a little: OAuth2RestTemplate is not deprecated; since Spring version 2.2.0 plenty classes are moved to new and other libraries, Spring left in OAuth module only the Authentication server, all other classes annotated as deprecated. OAuth2RestTemplate is used further, just with another package.
In light of this you can use RestTemplate further, but with changes in a project. Or, of course, to move to WebClient. This approach is not better or worse, it's just can work asynchronous and non-blocking.
We in our projects decided while not to move to new version, waiting for clear and fully understandable documentation about migration (at least last month it was not full and not fully understandable).
Related
Suppose I have some third party library and I want to integrate it with Spring in order to be able to use it as a part of Spring transaction. I didn't find any relevant information on the Internet and looked into the source code of integrations of RabbitMQ and MyBatis libraries. As I understood from their source code I should implement org.springframework.transaction.PlatformTransactionManager and interact with TransactionSynchronizationManager. And there are two questions:
How Spring "know" about and instanciate implementations of PlatformTransactionManager?
Suppose there are two resources been used in transaction through RabbitTemplate and
JdbcTemplate. What will be first committed - changes in database or
messages sent?
Also, I would be really appreciate if somebody point me out to some guide or book about interactions with Spring internals.
You have to instantiate them yourself, like a DataSourceTransactionManager or a HibernateTransactionManager. Spring Boot does that for you under the hood, but with plain Spring you need to do it yourself.
What you want are distributed transactions (XADataSource), which are not possible with RabbitMQ.
For RabbitMQ you should read this here first: https://www.rabbitmq.com/confirms.html . Then make sure you understand transactions on the JDBC side. Then you can reason about how they both work together.
For the Java side, you might enjoy this book entirely about transactions: https://www.marcobehler.com/books/1-java-database-connections-transactions
I am having an architectural issue with the Apache HttpComponents HttpClient.
We have a system where we have several different remote endpoints that we want to contact, and each have some different configurations like ssl, basic auth, et cetera.
I am using Spring Boot and Cloud Sleuth from which I get a HttpClientBuilder that gives me tracing and other things. I want to re-use that HttpClientBuilder but on-top of that add my own specific configurations, for each unique endpoint.
The problem though is that the HttpCientBuilder is not immutable with withXYZ() methods, nor is there a copy or clone method on the builder, so I can't copy the original and change just my specific changes there without altering the base HttpClientBuilder and get into conflicts with others that use the same instance of the builder. Be it racing conditions between threads or conflicting configurations between the different endpoints.
One place in the Spring Boot project where I have seen them seemingly wanting to do something similar is in HttpClientConfiguration of Spring Cloud Commons where it creates an own ApacheHttpClientFactory which takes the original autowired HttpClientBuilder and then sets disableContentCompression(), disableCookieManagement() and useSystemProperties() -- but it seemingly does it to the original instance of the HttpClientBuilder which just seems completely wrong to me. It will alter how all the built HttpClient works, and not just the one they will later be using in their Ribbon code in HttpClientRibbonConfiguration of Spring Cloud Netflix Ribbon. A potential bug in hiding? To me it seems like it, since it highly depends on calling order.
Does anyone have any ideas how something like this should be solved?
The easy alternative that I could do is to just not try and build upon the given HttpClientBuilder from Sleuth, but instead build a completely new one from the ground-up every time I need one, and check if a HttpTracing bean is available and use TracingHttpCientBuilder instead of HttpClientBuilder in that case, but this seems counter-intuitive.
I ran into the exact same problem. However, I had the option of defining my own HttpClientBuilder bean. I am not sure you are in the same position?
But by making the bean scope "prototype" a new bean instance is created every time it is injected somewhere. Then I could safely modify the HttpClientBuilder after injection.
#Bean
#Scope("prototype")
public HttpClientBuilder tracingHttpClientBuilder(..) {
...
}
The idea behind HATEOAS is actually very simple, that is, in response to a link containing other resources that the client can use to interact with the server, the client cannot know that the server workflow, but can know the next steps in the resource link from the root links, but only the link, not Request parameters and examples This is a far cry from the online documentation generated by Swagger2 (personal feeling)
On the other hand, when it comes to code writing, looking at Spring Hateoas or using Spring ApplicationListener is hard-coded, it feels very cumbersome and feels like no swagger2 annotations are easy to use.
This problem bothers me, I don't know if my API should use the Hatepas way
I am using Spring Boot 1.5.8 and spring-web 4.3.12. I have noticed that, when I make a request for data from one of our REST endpoints, more time is spent on data serialization than the rest of the operation. I have been looking into strategies to speed things up, and I learned about the Jackson Afterburner module. The spring documentation claims that I only need to create a #Bean in a #Configuration class and the ObjectMapper that is created will have that module registered. Unfortunately, after adding the Spring bean, the serialization performance remains unchanged. What am I doing wrong?
Also, if anyone has any other ideas about how to increase the json serialization performance in a Spring REST controller, I would be very interested in hearing about them.
Thanks in advance.
I have tried the Afterburner module, and I did not notice much (or really any) improvement in performance. Maybe Spring is already using it, or other, optimizations. After looking around a bit, I learned about Kryo, and that seems to help.
If nobody else posts a suggestion, I will have to accept my own answer, but I will wait for a bit.
We are analyzing different concepts for one of my projects. We decided to use Spring Boot & Microservices architecture.
After further discussions, we came to a query whether we CAN/SHOULD use Spring AOP to resolve cross cutting concerns of various microservices?
If not how can we address common concerns of microservices like logging, transaction mgmt, etc?
I have googled this topic extensively (even went to 5 pages for same search), but no luck. Any help appreciated.
Use Spring interceptors. They have interceptors and factories for just about anything. Lets you add instrumentation and common code to all aspects.
UPDATE: samples interceptors and factories.
ClientHttpRequestInterceptor
FilterRegistrationBean
SimpleClientHttpRequestFactory
ChannelInterceptor
I don't think that there is anything to worry about using AOP. This is how Spring does things usually under the hood.
I'd just be careful with logging method invocations, especially parameters which is the common use (abuse) of AOP.
Ususally the less code you write the better. If you can use standard, proven way of doing things - use it.