In my spring boot application, I am adding resource handlers via the below method. Handler is added to the location on windows setup, however are not being done so when deployed on my linux machine.
#Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
//linux
registry.addResourceHandler("/content/**").addResourceLocations("file:/app/content/").setCachePeriod(0);
//windows
//registry.addResourceHandler("/content/**").addResourceLocations("file:/D:\files\").setCachePeriod(0);
}
NOTE: The target folder on the linux machine has read write permissions as well. Also, have tried with file:// and file:///
Any other settings that I might be missing. Access to the files on http://myhost/content/file.jpg result in 404 on linux
Resolved. Issue was with the apache proxy conf.
Initially I was serving the static files via apache. Later was doing so from within the spring boot application.
However,
ProxyPassMatch ^/content !
this setting was still there the conf which was not forwarding the requests to the interceptor.
Related
In a single machine named mbc the React app at port 3000 running using pm2, the backend Spring boot application demo.war file deployed on Tomcat 9 at port 8099. In the same machine with firefox browser it is working as expected.
But I am facing the problem when from another machine with the firefox browser http://mbc:3000 the UI opens and the fetch call to the backend Spring boot App the sent option call
ends in the CORS blocked. The OPTIONS request returns with CORS blocked. I am not using any Security such as Spring Security. The application is simple proof of concept application using Spring boot and JPA. Kindly guide me how to sort it out. Is this indicates network issue or any other settings to be done at backend server
(1) at each controller #CrossOrigin annotation
(2) at the spring boot application file
#Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurerAdapter() {
#Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**");
}
};
(3) I am not using spring security
(4) In my windows machine at the etc file in the host file added the entry for ipaddress mbc. Here the mbc is the name of the host.
Recently, I upgraded my spring boot version from 2.2.6 to 2.6.1. After the upgrade, the server no longer finds my files in ROOT. The static files are built from an angular project which is added to my ROOT.war file at build time and the war file is moved to my server.
On the server, my static files are located at tomcat/webapps/ROOT. Previously (before upgrading) my files were found here and there were no issues. Since the upgrade typing myurl.com returns 404 but will return if I type myurl.com/index.html. I've tried to set up the WebMvcConfigurer for example
public void addResourceHandlers(ResourceHandlerRegistry registry){
registry.addResourceHandler("/**")
.addResourceLocations("/");
}
I added to my application.properties
spring.mvc.pathmatch.matching-strategy=ant-path-matcher
I also added server.servlet.register-default-servlet=true thinking it was the DefaultServlet removal that caused the issue but this didn't make any difference.
In the logs, I can see the ResourceHttpRequestHandler is mapped to [classpath[META-INF/resources], classpath[resources/], classpath[static/], classpath[public], ServletContext[/]]
The logs also indicate the Resource is not found.
I can move the files to webapps/ROOT/WEB-INF/classpath/static and they show up but I was hoping to avoid messing with the build process. Was there a change in the framework to disable root level static file serving or am I missing something?
I'm trying to do something very simple in Spring Boot:
Serve my api calls from /api
Serve a single-page app located in src/main/resources/static
Shouldn't be that hard, but this question has been asked a dozen times in different ways, and there doesn't seem to be an answer. It's very easy to do in Dropwizard, or when you wire up Jersey and Jetty together directly.
The best answer so far is here:
#Configuration
public class WebConfiguration extends WebMvcConfigurerAdapter {
#Override
public void addViewControllers(ViewControllerRegistry registry) {
registry.addViewController("/{spring:\\w+}")
.setViewName("forward:/");
registry.addViewController("/**/{spring:\\w+}")
.setViewName("forward:/");
registry.addViewController("/{spring:\\w+}/**{spring:?!(\\.js|\\.css)$}")
.setViewName("forward:/");
}
}
The problem with this is that calls to /api/bad_missing_path get routed to the SPA, and not to an error message that says this is a bad api call. The other problem with it is that I just don't understand it. Yet another problem is it explicitly mentions .js and .css file types, and I'm going to have many more types than that. I want everything that starts with /api to be treated as an api call, and everything that doesn't start with /api to get passed through to the /static directory.
I have also tried to mount the DefaultServlet on "/*" but it didn't catch anything, either using the default Tomcat server or when I switched to Jetty.
How do I get this to work?
UPDATE:
This problem exists in jetty from 9.4.25.v20191220, i have set the version back to 9.4.24 it correctly serves. Whether this is a bug or change of configuration I don't know.
Maybe someone can help, i appreciate this is all configuration issues but I've only had this issue having upgrade spring-boot-starter-parent to 2.1.13-RELEASE from 2.1.10-RELEASE.
Using #SpringBootApplication and everything else default, except with the following WebMvcConfigurer (found in another post here)
#Configuration
public class WebApplicationConfiguration implements WebMvcConfigurer
{
#Override
public void addViewControllers(ViewControllerRegistry registry)
{
registry
.addViewController("/{spring:\\w+}")
.setViewName("forward:/");
registry
.addViewController("/**/{spring:\\w+}")
.setViewName("forward:/");
registry
.addViewController("/{spring:\\w+}/**{spring:?!(\\.js|\\.css|\\.svg)$}")
.setViewName("forward:/");
}
}
Using Jetty, and with an angular project present at \src\resources\public\ including a index.html in the public directory.
In the previous spring version I could navigate to localhost:8080 and it would direct automatically to localhost:8080/list this is setup up as the redirect within the angular project index file.
But now using 2.1.13 i have to explicitly go to localhost:8080/index.html which does work, redirects to /list and i can navigate the website, but if i refresh the page or if i went explicitly to :8080/list i get whitelabel error 500
I've tried:
1.
Adding various other view controller rules:
registry.addViewController("/").setViewName("forward:/index.html");
registry.addViewController("/").setViewName("forward:index.html");
registry.addViewController("/**").setViewName("forward:index.html");
... But I don't think these are the problem anyway.
2.
Viewed ResourceHandlerRegistry to see the default resource locations, so it should pick up my index.html file.
3.
Adding spring.resources.static-locations=classpath:/public/xxx/**
I then get by going to localhost:8080/xxx/ or localhost:8080/xxx/index.html whitelabel 404
I upgraded spring due to security vulnerabilities, so currently tempted to go back to 2.1.10 or 11, and pull only the dependency versions required to mitigate vulnerabilities. I'd just like to understand what is going wrong, and obviously don't enjoy being defeated.
Does anyone know if there is changelogs for versions of spring that would shed any light to what has changed? I guess it could be due to any number of dependent projects though.
So it turns out that whatever the issue was it is fixed in jetty 9.4.27.v20200227.
Spring Boot releases from 2.1.10 contained new Jetty version for each release, with now release currently using 9.4.27.
Using spring boot 2.1.13-RELEASE with 9.4.27.v20200227, returns forwarding to what is expected with localhost:8080 loading /list
I'm trying to get WebSockets working on top of Grizzly / Glassfish. I've cloned the sample WebSockets chat application, built it and deployed it to Glassfish 3.1.2. However, I cannot get WebSockets to connect. The WebSockets handshake is failing because I'm getting a 405 (Method Not Allowed) response. This makes sense because of what is in the Servlet:
public class WebSocketsServlet extends HttpServlet {
private final ChatApplication app = new ChatApplication();
#Override
public void init(ServletConfig config) throws ServletException {
WebSocketEngine.getEngine().register(app);
}
#Override
public void destroy() {
WebSocketEngine.getEngine().unregister(app);
}
}
There is no doGet method specified, so I'm wondering if there is more configuration required somewhere, or if you need to implement the handshake logic in the servlet doGet method yourself?
I was trying to use grizzly-websockets-chat-2.1.9.war on glassfish 3.1.2 and getting same error.
Followed the advice from this page http://www.java.net/forum/topic/glassfish/glassfish/websocket-connection-not-establishing-glasshfish-server-how-fix-it-0
which states to use the version found here (I would think the version would indicate it being older however the time stamps on the files are Jan 30 2012):
WAR
https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.grizzly.samples&a=grizzly-websockets-chat&v=1.9.46&e=war
SOURCES
https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.grizzly.samples&a=grizzly-websockets-chat&v=1.9.46&e=jar&c=sources
By using that war everything works.
For those that like using the glassfish web console. You can enable web-sockets by:
Configurations > server-config > Network Config > Protocols > http-listener-1, then HTTP tab > Scroll to bottom and check off Websockets Support.
Note Configurations > default-config > ... also has the same options
You might find this more continent that keeping a terminal around.
It appears you haven't enabled websocket support (disabled by default).
Issue the following command and then restart the server:
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.websockets-support-enabled=true
You can replace http-listener-1 with whatever http-listener you wish to enable WS support for.