Introduction
I recently used netflix feign along with ribbon which was quite useful.
An Example of this is:
#FeignClient(name = "ldap-proxy")
public interface LdapProxyClient {
#RequestMapping(path = "/ldap-proxy/v1/users/{userNameOrEMail}", produces = MediaType.APPLICATION_JSON_VALUE, method = RequestMethod.GET)
LdapUser search(#PathVariable("userNameOrEMail") String userNameOrEMail);
}
However, at some point I thought that instead of having to code all these definitions by hand (for an existing webservice), that I should see if a tool existed.
I stumbled across https://github.com/swagger-api/swagger-codegenand saw that there are examples in which clients are generated, e.g. https://github.com/swagger-api/swagger-codegen/tree/master/samples/client/petstore/java/feign .
However, once I looked closely at the imports I noticed the following:
import feign.Feign;
Netflix's opensource solution on the other hand has package names:
org.springframework.cloud.netflix.feign.
Additionally, I noticed that both use ribbon if available, but Netflix's notation is much cleaner with a lot happenning in the background. E.g. the #FeignClient annotation class javadoc states:
Annotation for interfaces declaring that a REST client with that interface should be * created (e.g. for autowiring into another
component). If ribbon is available it will be * used to load balance
the backend requests, and the load balancer can be configured * using
a #RibbonClient with the same name (i.e. value) as the
feign client.
However in the Feign.feign documentation (at https://github.com/OpenFeign/feign ) I see:
RibbonClient overrides URL resolution of Feign's client, adding smart routing and resiliency capabilities provided by Ribbon.
Integration requires you to pass your ribbon client name as the host
part of the url, for example myAppProd.
> MyService api =
> Feign.builder().client(RibbonClient.create()).target(MyService.class,
> "https://myAppProd");
So my questions are:
what is the history/relationship and differences between the two?
what are the pros and cons of each?
Are they completely different projects with no relation, or did netflix just fork/utilize OpenFeign and modify it to be within their integrated cloud solution? Essentially, did netflix just acquire and integrate different technologies like Discovery, ribbon, and feign from open-source projects?
"Netflix feign" is the old project designation. The last version (dependency below) is dated July 2016.
compile group: 'com.netflix.feign', name: 'feign-core', version:'8.18.0' // OLD
"Open feign" is the new project designation. It's the same project, but was moved to a different git repo and got a new group-id. Its versions start at 9.0.0.
compile group: 'io.github.openfeign', name: 'feign-core', version: '10.0.1' // NEW
See this github issue for a brief history of what happened. Most remarkably, you'll find out that Feign isn't used internally at Netflix anymore. :^o
org.springframework.cloud.netflix.feign is a part of Spring Cloud Netflix project which is a part of Spring Cloud.
Spring Cloud uses OpenFeign under the hood. It extends it to support Spring MVC annotations and makes it a first-class citizen in the Spring Environment by providing integrations for Spring Boot apps through autoconfiguration.
From the documentation:
Feign is a declarative web service client. Spring Cloud adds support
for Spring MVC annotations and for using the same
HttpMessageConverters used by default in Spring Web. Spring Cloud
integrates Ribbon and Eureka to provide a load balanced http client
when using Feign.
Note that in the documentation there is a link to OpenFeign project.
So if you use Spring Boot - it is better and easier to use Spring Cloud OpenFeign integrations.
See also the source code.
Related
For a multi-tenant system, I decided that using a proxy in bean definitions would be a logical way to go.
At this point I developed a custom scope. I want to use a proxy. I saw that Spring Boot uses a third party library called CGLIB in ScopedProxyMode.TARGET_CLASS method. It is written in the Github repo of this library that there are problems for java 17 and above.
However, as far as I can see, Spring Boot does not directly use this library, it has wrapped it. Is it safe to choose TARGET_CLASS as proxy mode at this point? Is this issue guaranteed by Spring Boot?
I have been using spring-clound-openfeign with Consul as the service registry and Ribbon as Load Balancer. I am currently working with spring-boot 2.3.10.RELEASE.
I really like spring-cloud-feign-inheritance support which, in my understanding, allows me to write a single interface used by the server side and the client side.
https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-feign.html#spring-cloud-feign-inheritance
From spring-boot 2.4.x onward, the spring team recommended replacing Ribbon by spring-clould-loadbanced as a replacement since Ribbon is no longer being maintained.
If I have an interface let say:
interface Greeting {
#GetMapping
String hello(String name);
}
By using Spring Openfeign + Ribbon + Consul I could just extend it with:
#FeignClient(name="my-service-id")
interface GreetingClient extends Greeting { }
And with that I would have a client implementation with load balanced capabilities.
Can I still accomplish the same result as spring-cloud-openfeign with spring-clould-loadbalancer or I really need to work with RestTemplate or DiscoveryClient to have the client side of my API?
An over all picture of this would be highly appreciated since nonwhere else I have found a sensible answer.
If you want get work like with ribbon, need connect spring cloud loadbalancer to consul. You can read how connnect spring cloud loadbalanncer to consul into link
https://docs.spring.io/spring-cloud-commons/docs/current/reference/html/#serviceregistry
Small question regarding Netty metrics for a Spring Webflux + actuator project please.
In the Spring MVC world, combined with actuator, we have metrics such as:
tomcat_threads_busy_threads
tomcat_threads_current_threads
tomcat_threads_config_max_threads
jetty_threads_busy
jetty_threads_current
jetty_threads_config_max
Which helps a lot to get the overall status of the application.
However, in Webflux, it seems there is no equivalent.
I was expecting something like netty_threads_busy or something equivalent, but could not find anything related.
May I ask what would be the equivalent in Netty Webflux world please?
Thank you
The metrics expose by reactor-netty are not enabled by default in spring boot. There was a previous discussion on this github issue and the decision was not to enable these by default.
If you wanted to enable the netty server metrics in your own application, you can add the following bean to customise the Netty HttpServer.
#Bean
public NettyServerCustomizer nettyServerCustomizer(){
return httpServer -> httpServer.metrics(true, uriMappingFunction);
}
Caveat:
If you have path parameters in any of your URIs you should provide a uriMappingFunction that converts them to templated URIs ie. /user/1 -> /user/{id}. Failure to do so could lead to cardinality explosion in your MeterRegistry.
Enabling this feature also comes with the following recommendation:
It is strongly recommended applications to configure an upper limit for the number of the URI tags.
Reference Documentation
Java Doc
I want to create a REST web service using Jersey. I also want to use Spring in the project. Now, my questions is the following:
I don't see any reason for integrating these 2 together in my application. So, I should be able to use Spring for bean management and Jersey for creating the web service. Am I correct, or Spring and Jersey somehow have to be integrated.
I see that there is a jersey-spring maven project, and so, I assume that this is for the purpose of integrating jersey and spring together. My question here is do I get any benefit of using this integrated form rather than simply use Jersey and Spring separately each for its own functionality?
Thanks,
Cyrus
You can absolutely combine the two projects. However, I would encourage you to look at Spring-MVC for doing REST as it is very powerful and easy to use. If memory serves, the jersey-spring project was helpful in integration of JAXB and other touch points. Again, this is all built into Spring. And if you use Spring-Boot it is amazingly simple to get running.
The jersey-spring project provides integration between Jersey and Spring. It allows you to wire in any beans in your Spring context into Jersey and vice-versa.
For instance, if you are using spring-security, it will provide your spring-security principal when wiring the Jersey specific SecurityContext into any of your REST resources.
If you want to access Spring beans from your Jersey REST endpoints (or use Spring Beans as implementations for your JAX-RS interfaces) you need to integrate Spring and Jersey, otherwise it won't work. If you don't have any connections between Spring beans and your REST endpoints, then it is not necessary.
I think your first statement is correct. I have used Jersey and Sprint as separate entities.
Jersey is really awesome to create a web server.
Spring is useful for dependency injection (beans) and other cools stuff.
About your second statement, I do not know anything jersey-spring maven project.
My suggestion/opinion is to do as your first comment. Use them in a separate way. You will have the best of both worlds. Using jersey-spring maven project might be a complication and maybe it is not what you want. Libraries usually are intend to be independent.
I'm trying to set up a STOMP WS endpoint using spring-websocket and spring-messaging. I am trying to do this manually: no application context is involved at all, and certainly no dispatcher. My goal is to wire up the appropriate Spring components in code inside a ServletContextListener, then register the wired up components directly with the javax.websocket.server.ServerContainer in my JSR 356 compatible container (Tomcat 7). At first, I would like to get this working with the "simple" broker built into spring-messaging; secondly, I would like to implement my own "broker" to directly integrate with an in-process ActiveMQ using the VM transport. This would be in contrast to the STOMP relay which spring-messaging also provides.
The Spring documentation states (http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html):
"...Spring’s WebSocket support does not depend on Spring MVC. It is relatively simple to integrate a WebSocketHandler into other HTTP serving environments with the help of WebSocketHttpRequestHandler."
However, I am not finding it to be simple. Essentially, I started with:
public void contextInitialized(ServletContextEvent sce) {
ServerContainer websocketContainer = (ServerContainer) sce.getServletContext().getAttribute("javax.websocket.server.ServerContainer");
???
websocketContainer.addEndpoint(???);
}
And ended up with an incoherent mess of assorted spring-websocket and spring-messaging constructor invocations which do not compile and are certainly not worth reproducing here.
I realize this is a bit vague, this is because I'm a bit lost! Has anyone done something like this, or has some general guidance to contribute?
Did you try sample application - tests for the stock portfolio. (This link is at the very end of the spring documentation link).
It says
Demonstrates 3 approaches to testing a Spring STOMP over WebSocket application:
Server-side controller tests that load the actual Spring configuration (context sub-package)
Server-side controller tests that test one controller at a time without loading any Spring configuration (standalone sub-package)
End-to-end, full integration tests using an embedded Tomcat and a simple STOMP Java client (tomcat sub-package)
See the Javadoc of the respective tests for more details.
Second option is probably what you need.