I am learning to use React at the moment, and I have a problem: I want react to work with my Java Spring Boot backend (Tomcat). React is running on port 3000 (default) and my Tomcat server on port 8080 (default). Now, when I make a REST call, I get the following error
script.js:13 GET http://localhost:8080/api/path?p=test net::ERR_CONNECTION_REFUSED
My rest call looks like:
fetch('http://localhost:8080/api/path?p=test')
.then(res => {
console.log(res);
});
What do I make wrong? I do not really have an idea.
An net::ERR_CONNECTION_REFUSED error is typically thrown when your frontend (React application) cannot connect to your backend (your Spring boot application). There are many possible reasons for this to happen, such as:
Your back-end application is not running
The path to your back-end application is not correct
There is some kind of firewall between your front- and back-end application that is stopping the traffic
...
In your case it appeared to be the back-end application that was not running properly.
Your second problem is related to CORS, which is a mechanism that prevents JavaScript from connecting to other APIs/websites that are not on the same (sub)domain and port. In your case your frontend is running on a different port than you backend, so that means you have to deal with CORS.
To handle CORS, you have to add a header to your backend (namely the Access-Contol-Allow-Origin header the error is mentioning). With Spring, you can do that by adding the following annotation to your controller:
#CrossOrigin(origins = "http://localhost:3000")
Or you can configure CORS globally with a filter or using WebMvcConfigurer:
#Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurerAdapter() {
#Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/api/**").allowedOrigins("http://localhost:3000");
}
};
}
As mentioned in the comments by #Lutz Horn, this is also described in a Spring guide.
Related
Context
My micro-services application is based on spring-cloud: a zuul gateway is configured in front of two micro-services: service-a and service-b.
One of my API requires that service-a requests service-b; I use feign for that.
Zuul send X-FORWARDED-* headers to the services, for them to rewrite the HATEOAS links correctly (when the services are configured with ForwardedHeaderFilter).
My problem is that the services communicate with each other using Feign, which relies on Hystrix.
Hystrix creates a new thread for each request (we don't use the SEMAPHORE config), so the request in Spring's RequestContextHolder is lost in the Feign request from service-a to service-b, I can't enrich the feign request with an feign interceptor anymore since the original request is lost.
Some potential solutions
Forwarding authorization token is now supported directly by Spring with the parameter hystrix.shareSecurityContext: true
There isn't any "out of the box" configuration to have Hystrix shares the request between threads.
A solution could be to implement my own HystrixConcurrencyStrategy, which is a class from netflix.hystrix.
My latest find is this Pull Request that has been sent to spring-cloud-netflix, but unfortunately not integrated.
I can try to copy the code of the Pull request, and create a bean, just as what "eacdy" wrote:
#Bean
public RequestAttributeHystrixConcurrencyStrategy hystrixRequestAutoConfiguration() {
return new RequestAttributeHystrixConcurrencyStrategy();
}
Is there an easier solution to forward the headers from Zuul with Hystrix?
I suppose that what I am trying to do is very standard when using Zuul, Hystrix, and HATEOAS micro-services that communicate with each other, so maybe there is something that exists already (and that I couldn't find)?
Thanks !
I thought it was quite a common thing to achieve, but after a lot of research, I couldn't find a way to forward the X-FORWARDED-* headers automatically with Feign and Hystrix.
So, I looked for another solution, which works and is quite clean:
In the Feign client from service-a to service-b, I declared a specific configuration "ServiceBFeignConfig", which, in addition to forward the token, also add the X-Forwarded-* headers corresponding to the gateway:
#Configuration
public class ServiceBFeignConfig {
#Autowired
private ApplicationProperties applicationProperties;
#Bean
public RequestInterceptor requestTokenBearerInterceptor() {
return new RequestInterceptor() {
#Override
public void apply(RequestTemplate requestTemplate) {
OAuth2AuthenticationDetails details =
(OAuth2AuthenticationDetails) SecurityContextHolder.getContext().getAuthentication().getDetails();
requestTemplate.header("Authorization", "bearer " + details.getTokenValue());
if (applicationProperties.getFeign().getGatewayEnabled()) {
requestTemplate.header("X-Forwarded-Host", applicationProperties.getFeign().getGatewayHost());
requestTemplate.header("X-Forwarded-Port", applicationProperties.getFeign().getGatewayPort());
requestTemplate.header("X-Forwarded-Proto", applicationProperties.getFeign().getGatewayProtocol());
requestTemplate.header("X-Forwarded-Prefix", applicationProperties.getFeign().getServiceBPrefix());
}
}
};
}
}
You can see that the gateway host and port is configured in the properties files (that is served by Spring Cloud Config in my case). The service-b prefix is also set in these files.
These headers are only added if the "gatewayEnabled" property is set in the properties files.
You have to ignore this configuration from the component scan of Spring Boot, even if it needs the #Configuration annotation, so put it in a "ignorescan" package, and on your main Spring boot class, use:
#ComponentScan(basePackages = { "com.myservice" }, excludeFilters = #ComponentScan.Filter(type = FilterType.REGEX, pattern = "com.myservice.ignorescan.*"))
At the end, the Forward headers will be added if you have the gatewayEnabled set to true, and the API call to the gateway get the correct HATEOAS links.
Environment
Spring Boot 1.5.13.RELEASE
Spring Cloud Edgware.SR3
Java 8
Configuration
Eureka client is enabled and working correctly (I have tested and everything's working as I expect).
Some relevant properties from my configuration:
feign.hystrix.enabled=true
eureka.client.fetch-registry=true
spring.cloud.service-registry.auto-registration.enabled=true
service1.ribbon.listOfServers=https://www.google.com
Context
I have an application which speaks to 3 other services using feign clients. Two of these are discovered via Eureka service discovery. These are working well. The final service is an external one with a single static hostname and I do not want this resolved via Eureka. Since I do want Eureka for 2 of these services I would like to keep Eureka enabled.
Question
For the final service I tried adding service1.ribbon.listOfServers=https://www.google.com to the application.properties, however this cases the following error at runtime when invoking the feign client:
Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.netflix.hystrix.exception.HystrixRuntimeException: Service1Client#test() failed and no fallback available.] with root cause
pricing_1 |
pricing_1 | com.netflix.client.ClientException: Load balancer does not have available server for client: service1
pricing_1 | at com.netflix.loadbalancer.LoadBalancerContext.getServerFromLoadBalancer(LoadBalancerContext.java:483) ~[ribbon-loadbalancer-2.2.5.jar!/:2.2.5]
My client is configured as follows:
#FeignClient("service1")
public interface Service1Client {
#GetMapping(value = "/")
String test();
}
Thanks in advance for any advice.
Consideration
Since the spirit of Ribbon as I understand it is to act as a client side load balancer and given in my case there is nothing to load balance (I have one fixed static hostname that returns a single A record in DNS). Ribbon actually feels like an unnecessary component - what I really wanted was the Feign client as I like the fact that it abstracts away the lower level HTTP request and object seralization. So I suppose an alternative follow up question is, can I use feign without ribbon - it seems the nice out of the box behaviour would be to use ribbon - even the Javadoc of the #FeignClient annotation says:
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.
suggesting the two are quite closely related even if they are serving different purposes.
As you mentioned, there are two ways to solve your problem.
Use Feign without Ribbon
If you specify url attribute in #FeignClient annotation, it will work without Ribbon like the below.
#FeignClient(name = "service1", url = http://www.google.com)
public interface Service1Client {
#GetMapping(value = "/")
String test();
}
In this case, your other two Feign client will still work with Ribbon and Eureka.
Use Feign with Ribbon and without Eureka
What you are missing is in your configuration is NIWSServerListClassName.
Its default value is com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList and it will use Eureka to retrieve the list of server. If you set NIWSServerListClassName to ConfigurationBasedServerList for a ribbon client (feign client), only that client will work with listOfServers list without retrieving server list from Eureka. And other feign clients will still work with Eureka.
service1:
ribbon:
NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList
listOfServers: http://www.google.com
I am working on creating a Camel, Spring boot application that implements the OPC-UA connection. Till now, I was successfully able to run the examples obtained from Eclipse milo github repository.
Now, my task is to create a camel route that will connect to the opc-ua server that is running on a different machine, read data from there and store in a jms queue.
Till now, I am able to run the BrowseNodeExample and ReadNodeExample where I am connecting to a server simulator (Top Server V6). In the example code, when connecting to the server, the endpoint of the server is given as - "opc.tcp://127.0.0.1:49384/SWToolbox.TOPServer.V6"
Now in the camel routing piece of code, in the .configure() part, what shall I write in the .from() part. The piece of code is as -
#Override
public void configure() throws Exception {
from("opc.tcp://127.0.0.1:49384/SWToolbox.TOPServer.V6")
.process(opcConnection)
.split(body().tokenize(";"))
.to(opcBean.getKarafQueue());
}
While searching for the solution I came across one option: milo-server:tcp://127.0.0.1:49384/SWToolbox.TOPServer.V6/nodeId=2&namespaceUri=http://examples.freeopcua.github.io. I tried that but it didn't work. In both the cases I get the below error:
ResolveEndpointFailedException: Failed to resolve endpoint: (endpoint
given) due to: No component found with scheme: milo-server (or
opc.tcp)
You might want to add the camel-opc component to your project.
I've found one on Github
and also milo version on maven central for the OPC-UA connection.
Hope that helps :-)
The ResolveEndpointFailedException is quite clear, Camel cannot find the component. That means that the auto-discovery failed to load the definition in the META-INF directory.
Have you checked that the camel-milo jar is contained in your fat-jar/war?
As a workaround you can add the component manualy via
CamelContext context = new DefaultCamelContext();
context.addComponent("foo", new FooComponent(context));
http://camel.apache.org/how-do-i-add-a-component.html
or in your case
#Override
public void configure() throws Exception {
getContext().addComponent("milo-server", new org.apache.camel.component.milo.server.MiloServerComponent());
from("milo-server:tcp://127.0.0.1:49384/SWToolbox.TOPServer.V6/nodeId=2&namespaceUri=http://examples.freeopcua.github.io")
...
}
Furthermore be aware that milo-server starts an OPC UA server. As I understood your question you want to connect to an OPC UA server. Therefore you need the milo-client component.
camel-milo client at github
I have web application that is deployed to a local WildFly server. I am currently working on the front-end and am having troubles testing the data calls. All of my data gathering is done via AJAX and thus requires that I be on an actual server to silence any Cross-Site issues. This isn't a problem, but it is very time-consuming to re-deploy the entire application just to tweak a line of javascript.
I have successfully been able to deploy an exploded war. However, this forces a re-deploy when I saved the file. Is there a way for me to have it automatically update static content quickly without re-deploying?
You can also use this CORSFilter I think I found
here. There are plenty around.
This will add Access-Control-Allow-* headers to responses which in turn prevents the client from rejecting the reply as it would otherwise do for security reasons.
I have it included in my web app (for now), running on http://localhost:8080
and I can then run my grunt/gulp/node server on
http://localhost:8000 on the same machine w/ livereload ''as
usual'' doing requests between the servers.
I am a backend architect and I haven't done much frontend so there
might be better sollutions around; this is how I solved it today.
The CORSFilter:
#Singleton
#Provider
public class CORSFilter implements ContainerResponseFilter {
#Override
public void filter(final ContainerRequestContext requestContext, final ContainerResponseContext cres)
throws IOException {
cres.getHeaders().add("Access-Control-Allow-Origin", "*");
cres.getHeaders().add("Access-Control-Allow-Headers", "origin, content-type, accept, authorization");
cres.getHeaders().add("Access-Control-Allow-Credentials", "true");
cres.getHeaders().add("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS, HEAD");
cres.getHeaders().add("Access-Control-Max-Age", "1209600");
}
}
Probably not the answer you hoped for; but you another way is to use the right front-end development tools. For example: Webpack (http://webpack.github.io/) to build and test your front-end while mocking your REST-backend. That way you can also easily unit test your JavaScript front-end.
I have been going through the google tutorial ( which I find very good ) at
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
I have the service up and running on my local server and my JavaScript client can call it fine. OK so far. Now, what I want to do is deploy the service on a remote server JoeSoapHost:8080
How do I now tell my client where to send it's requests? I can't see any server/url being created in my RPC call. It just works by magic but now I want to get under the bonnet and start breaking it.
[Edit}
This is the Interface my client uses to know what service on the Server is to be called. I know that my Web.xml web descriptor must have a url that matches this. It has this because my server is invoked ok. Problem is, if I now decide to deploy my server elsewhere how do I tell my client what server/domain name to use?
#RemoteServiceRelativePath("stockPrices")
public interface StockPriceService extends RemoteService
{
StockPrice[] getPrices(String[] symbols);
}
What I want to achieve first is have a simple GWT client calling into an RPC service. I have this working but only when the server is localhost.
Next step, I deploy my app to the Google App Engine. What must I change now because my RPC service in my JavaScript is not being called when I deploy my app to
http://stockwatcherjf.appspot.com/StockWatcher.html
1) Brian Slesinsky excellent document on RPC - https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit#heading=h.amx1ddpv5q4m
2) #RemoteServiceRelativePath("stockPrices") allows GWT code to determine relative to your host/server/domain i.e http//mydomain.com/gwtapp/stockPrices
3) You can search GOOGle IO Sessions from 2009 - 2012 for some more in depth stuff on GWT RPC usage.
#RemoteServiceRelativePath gives the path of the servlet relative to the GWT.getModuleBaseURL() (which is more or less the URL of the *.nocache.js script); it doesn't "just work by magic".
If you deploy your services on a different server than the one serving your client code, then you'll likely hit the Same Origin Policy. CORS can help here, but you'll lose compatibility with IE (up to IE9 included). You'd better stick serving everything from the same origin.