In my WEB-INF/web.xml file, an upload path is set absolutely.
Can I make this relative to the application root?
Or is there a better "best practices" approach to configuring paths for file uploads?
Below is the relevant config code.
entire config file
<filter>
<filter-name>PrimeFaces FileUpload Filter</filter-name>
<filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
<init-param>
<param-name>uploadDirectory</param-name>
<param-value>/var/webapp/mdjdreview/upload/temp</param-value>
</init-param>
</filter>
If you make it a relative path, and use new File(path) to access the directory, it will be relative to the directory from which your container is started.
You can do it, but except for making it more difficult to know where the files are actually stored, and for risking to look at the wrong place because the container is started from elsewhere, I don't really see the point.
If waht you plan to do is storing the uploaded files in the directory of the deployed webapp, then you should definitely not do that, as a redeploy of the webapp will remove all the uploaded files. Treat the webapp directory as read-only.
Related
I'm packaging a web application and tomcat into a zip file. This zip should be able to use in any location or path.
This web application require to load an additional folder (response-folder) to be able to startup.
Due to the zip can be unzip anywhere, I need to find out my current path when the server is started and set the path in the startup.bat.
The following is my zip folder structure:
my.zip
- apache-tomcat
- bin
- startup.bat
- webapp
- mywebapp
- WEB-INF
- web.xml
- response-folder
In my startup.bat, I had the following line
set CATALINA_OPTS=-Dapache-tomcat-current-folder="%TOMCAT_CURRENT_FOLDER%"
I would like achieve something like below:
<servlet>
<description>MyService</description>
<display-name>MyService</display-name>
<servlet-name>MyService</servlet-name>
<servlet-class>com.my.package.MyService</servlet-class>
<init-param>
<description>Folder that contains response files</description>
<param-name>RESPONSE_FOLDER</param-name>
<param-value>${apache-tomcat-current-folder}\response-folder</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Note: I'm not able to the change the web application java code, as the web application is not belong to me.
May I know is there anyway to make web.xml to support variable interpolation or achieve behavior such as above?
Any help would be great.
To use environment variables in web.xml, you can add
set "CATALINA_OPTS=-Dapache-tomcat-current-folder=somevalue"
or if you want to reference a System environment variable
set "CATALINA_OPTS=-Dapache-tomcat-current-folder=%apache-tomcat-current-folder%"
in bin/setenv.bat (bin/setenv.sh for *nix).
You need to create this file.
This is the error I am getting.
com.sun.jersey.api.container.ContainerException: A root resource, class
org.apache.hadoop.hdfs.server.datanode.web.resources.DatanodeWebHdfsMethods,
has a non-unique URI template /
I am using Hadoop and REST API.
This is how I am initialising REST API in web.xml
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>
com.sun.jersey.server.impl.container.servlet.ServletAdaptor</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/RESTMOB/CALL/*</url-pattern>
</servlet-mapping>
I have tried removing the Hadoop JARs and it works, but I need those Hadoop JARs so what's the alternative. Thanks in advance
what is likely happening is some .class file(s) in the jar you removed are also present in the other jars - this is common in java and can create issue restarting your app and it might load different versions on restarts. I would open up the jars and search for duplicate class files and remove them from one jar and test. You can extract the jars to file system and search for all .class files and sort by name. Its always a good idea to eliminate duplicate .class files when possible even though it requires some tedious work
I'm trying to test a war that I deployed in Tomcat 7, however it seems its missing a xml configuration:
web.xml
<servlet>
<servlet-name>StorageEngine</servlet-name>
<servlet-class>com.jpeterson.littles3.StorageEngine</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:StorageEngine-servlet.xml</param-value>
</init-param>
</servlet>
I have downloaded the StorageEngine-servlet.xml separately, to be able to satisfy this init-param where do I need put the
xml file in the \webapps\littleS3-2.3.0\WEB-INF folder, just relative to the web.xml? Or?
No, it belongs in WEB-INF/classes of your WAR file. That is always in the CLASSPATH of a Tomcat app, loaded by the app class loader.
Given the mapping it would need to be placed in the root of your classpath. Try placing it within the root of any source folder
Is there a way to place applicationContext.xml into WEB-INF folder? I am specific to WEB-INF folder because I know that it can be placed into WEB-INF\classes folder.
As per the requirement, Clients should be able to configure applicationContext.xml according to their setup.
There is another option I thought of importing xml configuration files from WEB-INF folder to applicationContext.xml. But I didn't tried it yet and not sure how feasible it is.
From your requirement point of view, there is absolutely no difference between putting it in the WEB-INF or in WEB-INF/classes directory: Either way it needs to be accessed from the exploded WAR/EAR after deployment, which may not be possible if your app server don't explode it (ie, JBoss can work directly with the WAR).
IMO, the solution for you is to stop using the WebApplicationContext implementation. Use DefaultListableBeanFactory which should be initialized in a ServletContextListener, reading the configuration file manually. That way you can obtain the path to the applicationContextFile from the ApplicationServer environment (using JNDI or whatever method suits you), so it can be places anywhere in the machine where the Application Server resides.
At least that's what we did, for the very same reason you have.
Yes, you can do this, but the classpath is a pretty logical place to put them.
In your web.xml, in the definition for "contextConfigLocation", just add /WEB-INF/applicationContext.xml to the section.
If you add this in the web.xml then you can access the applicationContext
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml
</param-value>
</context-param>
GWT RPC call don't seems to work when i deploy my war file to TOMCAT (tomcat/webapps/ROOT/war).
It gives me an error:
The requested resource
(/war/myproject/call) is not
available.
If i change the directory structure and then deploy directly war contents (not war directory itself), like (tomcat/webapps/ROOT/project.html, project.css, project, etc...) then it works.
Can someone please explain me whats going on?
I think there might a problem at:
<servlet>
<servlet-name>callServlet</servlet-name>
<servlet-class>com.myproject.server.dao.Call</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>callServlet</servlet-name>
<url-pattern>/myproject/call</url-pattern>
</servlet-mapping>
The thing is that a single Tomcat server can have multiple applications deployed, each in its so-called context. The applications are deployed in the webapps folder and each folder is mapped to one context, while the ROOT folder is the default (no-context).
To access an application on Tomcat, you specify the context after the URL. For example if you had an application (context) Test in webapps/Test folder, you would access it like this:
http://localhost:8080/Test
But applications in the ROOT folder have no context and are accessed by simply going to localhost:8080. And this is your case. Tomcat is looking for you application directly in the ROOT folder but you have your app in the ROOT/war folder. In other words, the RPC call expects the myproject folder to be under the ROOT folder and not under the ROOT/war folder. That's why it's not working.
If you still wanted to have your war folder within the ROOT folder, you would have to change the url-pattern to /war/myProject/call.
Well i found the solution, it had to do with Tomcat's way of operation.
Open your project war directory
Select all the files (html/jsp , images, WEB-INF etc...)
Compress all the files into a single project.zip archieve
Rename the project.zip into project.war
Copy project.war into Tomcat/webapps/
Restart Tomcat server
You will now notice inside webapps directory that project.war has been decompressed into a project directory, if you open it you will find all the .war contents(html/jsp, images, WEB-INF, etc...)
Access it from here http://localhost/project or http://localhost/project/index.html or index.jsp.
The error was: I was compressing only the war directory (not it's inside contents) into project.war.
look like, servlet is not initializing for you war try to change SERVLET tag as
i.e. add tag
<load-on-startup>1</load-on-startup>
this tag ensures that servlet should be loaded
<servlet>
<servlet-name>callServlet</servlet-name>
<servlet-class>com.myproject.server.dao.Call</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
hopefully this will work