I am developing a rest web service using reactive programming through spring-webflux(Spring Boot 2.1 and Spring Framework 5.1). I need to create components having request level scope. #Scope annotation is suggested for spring MVC applications. But I found that the same doesn't work with webflux application.
Is there an equivalent feature available in webflux, as of latest release?
If not, what shall be the workaround here to create a new instance of a component on every incoming request?
I am trying to avoid use of new operator.
Thank you for the suggestions.
Unfortunately you cannot use request scopes in spring-webflux like in spring MVC applications. The main reason being, they use ThreadLocals which cannot be used by spring-webflux as work can be done on any thread at any time.
Spring webflux uses project-reactor at its core. So you can use Reactor Context which allows you to share data in your reactive pipeline.
Related
I've really enjoyed using Flurl the last year but have encountered a problem that Im hoping I can solve using Flurl if possible and not resort ripping it out and using IHttpClientFactory and HttpClient from System.Net.Http
I've got a DotNetCore 3.1 API and our client is calling these APIs with custom headers. "x-activityid" as an example. My API calls out to an external API and so I've created a separate Client class where im calling the endpoints on the external API using Flurl.
I need to propagate some of the headers from the requests incomming to my API to the requests I make to the external API that Im calling using Flurl.
Some related links:
Header propagation using ASP.NET Core
Make HTTP requests using IHttpClientFactory in ASP.NET Core
The whole idea of header propagation depends on awareness of some HTTP server context from which to grab the incoming headers, which is why ASP.NET Core can support such a feature directly while Flurl, a stand-alone library that often gets embedded in things like Xamarin apps, cannot.
But all is not lost, because Flurl is really just a wrapper around HttpClient. To get this feature to work without giving up Flurl, just wire up header propagation in ASP.NET Core exactly as prescribed, allow it to inject HttpClient instances into your service classes, then wrap those instances with Flurl inside those classes. Note that you'll need to adapt the pattern of using FlurlClient directly, as opposed to building calls off URL strings, if you're not doing that already.
Can I use the existing spring-boot-starter-web coding scheme with only spring-boot-starter-webflux added?? without spring-boot-starter-web.
spring-boot-starter-webflux provides the relevant dependencies for a Spring WebFlux application, from Jackson to the spring-webflux module for annotation and functional programming models.
spring-boot-starter-web does the same for Spring MVC.
Having both on the classpath means that you want a Spring MVC app and still use the new WebClient provided by Spring WebFlux in that application.
As mentioned in the Spring Boot reference documentation, you should add spring-boot-starter-webflux if you want to create a Spring WebFlux app and avoid adding spring-boot-starter-web.
We have an option of using RestAssuredMockMVC or RestAssured while writing cloud contracts for Spring MVC. By RestAssuredMockMVC we can mock the controller and no need of starting the context. And via RestAssured we can use the direct call the controller via physical API using the testmode =EXPLICIT.
But, while using Reactive Webflux, we have been limited to RestAssured only and we have to make context up and running.
Why can't we have an option of mocking the controller here as well?
We will, there's an open issue for that to start using WebTestClient - https://github.com/spring-cloud/spring-cloud-contract/issues/422 . If you're interested in the feature go ahead add +1 and / or file a PR :)
I created a Spring boot 2.0.0.M7 project with the webflux starter because I want to use all the asynchronous and the non-blocking capabilities.
I added the server.servlet.context-path but it does not work if I don't add the web starter as well.
If I add both starters can I have issues with the non-blocking functionality?
I executed some stress tests with Gatling and I have received the same scores removing the web starter or adding it.
Any help with this?
If you add both spring-boot-starter-web and spring-boot-starter-webflux to your application, Spring Boot will configure it as a Spring MVC app.
This is intentional as many Spring MVC will get the webflux dependency to leverage the new WebClient in their MVC apps. Also, as of Spring Framework 5, Spring MVC knows how to handle a few cases with Flux at the controller level.
You can always force your choice like this:
SpringApplication app = new SpringApplication(MyApplication.class);
app.setWebApplicationType(WebApplicationType.REACTIVE);
app.run(...);
In your case, this is not about forcing a choice but rather using something that's not supported in WebFlux.
The server.servlet.context-path configuration property is Servlet-specific, so it won't work with WebFlux. Currently Spring Boot does not support war deployment nor multiple web contexts for WebFlux applications. So there's no point in offering such a property.
The runtime model difference between "Servlet-based" and Reactive runtime with Spring can be quite subtle, and I encourage you to watch a talk that describes those choices. The short answer is: if you're using Spring MVC with async types (DeferredResult, Flux or SseEmitter) things will be async but reading and writing will still be blocking.
Properly benchmarking that is quite hard, but the results you're seeing are somehow expected. Running locally server+client, no latency involved, looking at raw throughput - all of those constraints should not be in favour of the reactive model which has a concurrency cost. If anything, this benchmark shows that the reactive stack is quite optimized already, even for non-ideal use cases!
Hi I am working with Mule Studio and I want to use Spring Rest Service with REST component in the Mule. So how can I access Spring REST features with REST Component I don't want to use Jersey way of creating REST service with Mule.
I just want to declare one REST controller with spring annotation that will automatically invoke.
Mules Rest Component is a Jersey implementation of JAX-RS which loads the resource classes so that they can be accesses as Rest URLs.
Spring Rest Controller is the Spring way of creating a Rest service which runs ona web-container.
If you want to run the SpringRestController based rest service on Mule you can package and deploy it directly on Mule standalone. Mule can run a web applicaiton as it contains an embedded Jetty container.
Unfortunately you cannot include a Spring RestController into the Mules's REST component(which is a Jersey implementation). Controller's purpose is not to serve as a component.
By the way in Mule also you just need to specify the annotations and provide the resource class to the REST component. Mule takes care of the rest.
Hope this helps.