I am working on a Web Application using the Spring Framework in version 4.1.5
I have a resources folder configured and set up correctly and am already loading css, js and image files out of that.
<mvc:resources mapping="/images/**" location="/resources/" />
However, I am also using the resources folder for uploading images into it and displaying them in the frontend. And there's a point where I'm currently stuck and am not proceeding my understanding. I am getting 404 Error (resource not available), while others are working perfectly fine. The paths are all correct and the files are successfully uploaded, I am sure of that.
I have also seen the reverse effect - renaming or even removing resources out of the resources folder does not impact their accessibility over their web url. I am not copying any files to another folder during building the application, so I am working with those files in the resources folder. I also have looked for the filename on my filesystem and its not there anymore, so I assume there must be some cache in place.
Does Spring build an index or cache over the existing resource files at startup? Do I have to refresh any ApplicationContext after uploading files to notify the framework of changes in the file system and if so, how do I do that?
Hopefully someone can help me here :)
Thank you,
Tom
EDIT:
When calling an URL like: localhost:8080/EstelV2/images/testimage.jpg
I run into a 404 resource is not available, even though the testimage.jpg is in the correct folder structure on the file system and get the log output:
2015-04-30 22:13:05,035 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:845) - DispatcherServlet with name 'spring-dispatcher' processing GET request for [/EstelV2/images/testimage.jpg]
2015-04-30 22:13:05,035 - [DEBUG] - [http-nio-8080-exec-4] (AbstractHandlerMethodMapping.java:297) - Looking up handler method for path /images/testimage.jpg
2015-04-30 22:13:05,041 - [DEBUG] - [http-nio-8080-exec-4] (AbstractHandlerMethodMapping.java:305) - Did not find handler method for [/images/testimage.jpg]
2015-04-30 22:13:05,041 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:168) - Matching patterns for request [/images/testimage.jpg] are [/images/**]
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:193) - URI Template variables for request [/images/testimage.jpg] are {}
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (AbstractUrlHandlerMapping.java:123) - Mapping [/images/testimage.jpg] to HandlerExecutionChain with handler [ResourceHttpRequestHandler [locations=[ServletContext resource [/resources/]], resolvers=[org.springframework.web.servlet.resource.PathResourceResolver#280f257d]]] and 1 interceptor
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:931) - Last-Modified value for [/EstelV2/images/testimage.jpg] is: -1
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (DispatcherServlet.java:1018) - Null ModelAndView returned to DispatcherServlet with name 'spring-dispatcher': assuming HandlerAdapter completed request handling
2015-04-30 22:13:05,042 - [DEBUG] - [http-nio-8080-exec-4] (FrameworkServlet.java:996) - Successfully completed request
Soo after hours of investigations I came to a conclusion:
My problem was not related to spring, it was a problem about my eclipse project. It seemed, as long as I didn't refresh my project in eclipse, the newly uploaded files were not accessible by the tomcat server - and the old ones which were removed from the file system but still were in the eclipse project kept being accessible.
I turned on both auto-refresh options at Preferences -> General -> Workspace -> "Refresh using native hooks and polling" and "Refresh on access", which solved my problem for now.
Thank you for your help!
servlet specification not mention that WEB_INF is Document root
A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren’t in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. so use it for secure your content only but for images put it in other folder in your web path
Related
I would like to configure my application (that already works fine with Shiro) using Shiro programmatic configuration and leaving shiro.ini file.
I use the official tutorial here.
This is the code i implemented:
Realm realm = new AuthAuthRealmFactory();
org.apache.shiro.mgt.SecurityManager securityManager = new DefaultSecurityManager(realm);
//Make the SecurityManager instance available to the entire application via static memory:
SecurityUtils.setSecurityManager(securityManager);
The problem is when i remove shiro.ini file i experience this exception:
> org.apache.shiro.web.env.IniWebEnvironment - Checking
> any specified config locations.
> - org.apache.shiro.web.env.IniWebEnvironment - No INI instance or config locations specified. Trying default config
> locations. - org.apache.shiro.io.ResourceUtils
> - Opening resource from class path [shiro.ini] - org.apache.shiro.util.ClassUtils - Resource [shiro.ini] was not found via the thread context ClassLoader.
> Trying the current ClassLoader... - org.apache.shiro.util.ClassUtils
> - Resource [shiro.ini] was not found via the current class loader. Trying the system/application ClassLoader... -
> org.apache.shiro.util.ClassUtils - Resource
> [shiro.ini] was not found via the thread context, current, or
> system/application ClassLoaders. All heuristics have been exhausted.
> Returning null. - org.apache.shiro.web.env.IniWebEnvironment
> - Unable to load optional path 'classpath:shiro.ini'.
> - java.io.IOException: Resource [classpath:shiro.ini] could not be found.
Thanks
If you are using Shiro's servlet plugin (fragment):
https://github.com/apache/shiro/blob/master/support/servlet-plugin/src/main/resources/META-INF/web-fragment.xml
You would need to configure Shiro directly (either your web.xml or equivalent) and make sure the default impl is not loaded. If you share a little more about your app (what type is it, how are you trying to configure Shiro, I'm guessing we can help you more directly)
I'm writing some microservices (fat jar) which expose some http endpoint using a router. As I like every microservice automatically expose a /doc endpoint which just fetches a /src/main/resource/doc/readme.adoc and renders that to html I created a new project doc-renderer.
It puts a /doc endpoint to the router and in its handler method it tries to access the readme.adoc and renders it to html. If I now use that bundle as dependency within my microservices and put a readme.adoc under /src/main/resources/doc/ it isn't really working as it loads the readme.adoc in the dependend bundle.
So this is the resulting jar structure
microservice.jar
- /doc/
- readme.adoc
- /lib/
- docRenderer.jar ( here it tries to load the readme from outside )
- /doc/
- readme.adoc
To load the resource I use: getClass().getResourceAsStream("/doc/readme.adoc")
Is there a way I can force it to always use the /doc/readme.adoc file from the outer jar?
Regards, Marco
I have been testing Spring Boot with embedded Tomcat for about a month now to build a REST API. Everything was working fine. We now want to deploy the API in a separate development environment which has a couple of other (non-Spring) applications running on a Tomcat container.
I made the changes specified in Converting a Spring Boot JAR Application to a WAR using Maven and Spring Boot Docs.
The deployment goes well (logs are fine, no errors) and looking at Tomcat management i see my application deployed. However, when I attempt to access http://localhost:8080/sophia/users in curl I get 404.
Any help is much appreciated.
UPDATE:
Here are my logs:
Netbeans:
NetBeans: Deploying on Apache Tomcat 8.0.17
profile mode: false
debug mode: false
force redeploy: true
In-place deployment at /home/bugz/workspace/pdcore/sophiaserver/target/sophia-server-1.0.0-SNAPSHOT
Deployment is in progress...
deploy?config=file%3A%2Ftmp%2Fcontext1845402702541504208.xml&path=/sophia
OK - Deployed application at context path /sophia
Start is in progress...
start?path=/sophia
OK - Started application at context path /sophia
Tomcat:
INFO 10:47:52:703 org.springframework.boot.context.embedded.ServletRegistrationBean - Mapping servlet: 'dispatcherServlet' to [/sophia/*]
INFO 10:47:54:042 org.springframework.boot.SpringApplication - Started application in 8.285 seconds (JVM running for 12087.301)
22-Jan-2015 10:47:54.060 INFO [http-nio-8080-exec-99] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of configuration descriptor /home/bugz/workspace/server/apache-tomcat-8.0.17/conf/Catalina/localhost/sophia.xml has finished in 12,091 ms
And in sophia.xml for Catalina localhost:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" docBase="/home/bugz/workspace/pdcore/sophiaserver/target/sophia-server-1.0.0-SNAPSHOT" path="/sophia"/>
I've tried accessing
http://localhost:8080/sophia/users
http://localhost:8080/sophia-server-1.0.0-SNAPSHOT/users (name of WAR)
The first returns a 404 but with the CORS information from my CORS filter bean. The second return 404 without CORS information (which indicates the application has started and is configured but I do not seem to have access to the Controllers).
When running an application the path to call consists of a couple of parts.
The first is the base URL on which the application is deployed, in your case that is /sophia.
The second is the servlet mapping of the DispatcherServlet in your case that is /sohpia/*.
The third is the mapping of the controller inside the DispatcherServlet, in your example that is /users.
All those things combined create the URL /sophia/sophia/users.
The difference between the deployment as a WAR is that you included a separate URL to deploy on, when running as a jar it, by default, is deployed to / (the root).
You could fix it by putting /sophia as the server.context-path in the application.properties and map the DispatcherServlet to /* or /. That will in both situations give you the URL you want (and expected).
check java -version means the if you complied war in java 8 and tomcat is running on java 7 then it doesn't work.
Have you tried extending the SpringBootServletInitializer and overriding the configure method? As stated here
The entry point for jar file is different [Main Class] when compared to running your app as war file inside a container.
Hope this helps.
check the java version
version that exists in pom.xml must be the same that the version installed on the server
openjdk 11 works fine for me
https://adoptopenjdk.net/
May be I have phrased the question wrongly but here's the issue. I have a library called util, inside util we have a database class that will be using C3P0 for database connectivity. This util library is used by different devs within the team .
To make life easier for everyone since we have a modular system, each module in the system can specify it's own database connection and properties as it sees fit for their module. The only reason we are doing this is because the methods for calling executing queries are all defined in this libraries and so instead of everyone rewriting the same code over and over it's much efficient to use a shared lib with that functionality.
The current set up is that I have the C3P0.properties file inside my util library classpath and inside it I have defined the path of the C3P0-config.xml file like this.
com.mchange.v2.c3p0.cfg.xml=./conf/c3p0-config.xml
I then build and the jar and give it to the rest of the devs . They then create a conf directory in their application and add the c3p0-config.xml.
The Strucuture of the Directory looks like this
Parent directory - module name {
Sub directories
-lib -> {Util.jar & other jars}
-conf -> {c3p0-config.xml & other config files}
-logs
-modulename.jar
}
On executing the jar file we get the error
2014-02-12 20:50:59 INFO MLog:124 - MLog clients using log4j logging.
2014-02-12 20:50:59 DEBUG MLog:101 - Could not find resource path text file for path '/com/mchange/v2/cfg/vmConfigResourcePaths.txt'. Skipping.
2014-02-12 20:50:59 DEBUG MLog:101 - Added paths from resource path text file at '/mchange-config-resource-paths.txt'
2014-02-12 20:50:59 DEBUG MLog:101 - Reading VM config for path list /com/mchange/v2/log/default-mchange-log.properties, /mchange-commons.properties, /c3p0.properties, hocon:/reference,/application,/c3p0,/, /mchange-log.properties, /
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier '/mchange-commons.properties' could not be found. Skipping.
java.io.FileNotFoundException: Resource not found at path '/mchange-commons.properties'.
at com.mchange.v2.cfg.BasicPropertiesConfigSource.propertiesFromSource(BasicPropertiesConfigSource.java:64)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:185)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier 'hocon:/reference,/application,/c3p0,/' could not be found. Skipping.
java.io.FileNotFoundException: HOCON lib (typesafe-config) is not available. Also, no resource available at '/reference,/application,/c3p0,/' for HOCON identifier 'hocon:/reference,/application,/c3p0,/'.
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.configSource(BasicMultiPropertiesConfig.java:86)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:184)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
2014-02-12 20:50:59 DEBUG MLog:101 - The configuration file for resource identifier '/mchange-log.properties' could not be found. Skipping.
java.io.FileNotFoundException: Resource not found at path '/mchange-log.properties'.
at com.mchange.v2.cfg.BasicPropertiesConfigSource.propertiesFromSource(BasicPropertiesConfigSource.java:64)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.firstInit(BasicMultiPropertiesConfig.java:185)
at com.mchange.v2.cfg.BasicMultiPropertiesConfig.<init>(BasicMultiPropertiesConfig.java:110)
at com.mchange.v2.cfg.ConfigUtils.read(ConfigUtils.java:63)
at com.mchange.v2.cfg.ConfigUtils.readVmConfig(ConfigUtils.java:115)
at com.mchange.v2.cfg.MLogConfigSource.readVmConfig(MLogConfigSource.java:46)
at com.mchange.v2.log.MLogConfig.refresh(MLogConfig.java:59)
at com.mchange.v2.log.MLog.refreshConfig(MLog.java:59)
at com.mchange.v2.log.MLog.<clinit>(MLog.java:51)
at com.mchange.v2.naming.JavaBeanReferenceMaker.<clinit>(JavaBeanReferenceMaker.java:51)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<clinit>(PoolBackedDataSourceBase.java:260)
What could be the problem ? What I'm I doing wrong ?
In the log messages and stack traces that you've shown, there is nothing wrong at all. These are all DEBUG level messages. (c3p0 & com.mchange libraries should usually be logged at INFO.)
c3p0 & mchange-commons-java check for potential config information in lots of different places. In many of those places, they find nothing, and so move on. Logging at DEBUG, you are watching the process of libraries checking for, e.g., /mchange-log.properties, in the CLASSPATH and failing to find it. At DEBUG, the libraries log that they looked, that they did not find, and the Exception that went along with not finding.
None of this is of concern at all. It is normal.
The main question is whether the config users put in c3p0-config.xml is taking. You are using a relative directory for the file, rather than an absolute filesystem location. I presume that will work, with relative being interpreted relative to the working directory of the process, but I'm not sure it will work, and even if it does, are you sure that it won't be fragile, depend on how users start up your process? Will users run a script that will ensure the proper working directory?
When routing to my webservice folder (localhost:8080/myproject) all i see is 404 error.
Note : I have changed the server location , so now the main page of the apache server loads up ok.
What may cause this problame?
It might be due to you have configured different context root for your application than that of myproject. e.g. context root allows you to have different url than that of the actual folder name. Below link might help you to do that.
How to change context root of a dynamic web project in Eclipse?