I'm writing a service for Axis2 + Tomcat7.0 with Java for the application. I've chosen to write any information to xml file, the problem is where is the root of the service/application server?
I read the other question but isn't response good.
How can I get an absolute path to the writable directory by the service?
I would set an environment variable and then read the value of it by using System.getProperty().
I think the default file writing location is wherever you are when you start the server, at least that's what I found with JBoss one time. The easiest thing is to either set an environment variable in a server property file, or create a property file for your service to use to retrieve the location. I've done it both ways with JBoss in windows and unix.
Related
I am writing and small app using Java EE. I am using Apache Tomcat v 7 and Eclipse as IDE. When I Run the project (Run on server) I get :
http://127.0.0.1:8080/java-web/lis
(That's fine)
But I don't know If there is some way to rewrite the [java-web] dir just to get :
http://my-local-app.dev/list
I suppose there is some way like in Apache Server using confing files and enabling
the mod_rewrite.
I'll apreciate your help. Thanks
In short: All of the pieces you want to change are components of your deployment environment. Unless you have a specific need to override them, it's usually easiest during development to use the URLs that are a little less pretty.
If you do want to alter them, you need to familiarize yourself with what the various parts of an HTTP URL mean. What you have in your test environment is this:
http:// 127.0.0.1:8080/java-web/list
protocol host port path
You could insert an entry into your hosts file listing my-local-app.dev at 127.0.0.1, but that would not change the port or the path.
The port is determined when Tomcat starts up and is 8080 by default. The general port for HTTP is 80, but specific permission is required to bind to ports below 1024. On Linux, the authbind package makes this pretty easy; on Windows, the necessary steps will depend on your version and configuration (e.g., if you have a Group Policy).
In Tomcat, Web applications are prefixed with their names in the path; it looks like your (hypothetical?) application is named java-web.war. You can install an application as the "root application", but this requires a little bit more configuration and is generally skipped in development.
All of this can indeed also be done using something like mod_rewrite, but that seems like overkill to have slightly prettier URLs for your dev machine.
If you want your application to respond to the my-local-app.dev, you need to purchase the "my-local-app.dev" domain and get a Java web hotel running on it.
If your web application is named "java-web" and you do not want the URL to reflect that, you need to tell Tomcat that you want your application deployed at the ROOT location where the name of the web application is not present in the URL. This is typically done in the deployment stage but unfortunately there is no standard location to say this for WAR files so this is vendor dependent. For example does Glassfish use an extra XML file in your deployment.
I believe Tomcat supports this for ROOT.war files. If not, you probably needs to set the META-INF/context.xml file. See https://tomcat.apache.org/tomcat-7.0-doc/config/context.html for details on what to put in this file - especially the context path.
Dear fellow Developers,
I am working on improving my Java Web Services, and I am trying to use a more delicate way of getting the directory path of properties files in a Java Web Service.
In order to make my Java Web Application easier to be deployed on an Apache Tomcat Server, I add the following line to the web.xml file:
<env-entry>
<env-entry-name>loggerPropertyFile</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/Some/Long/Directory/File/Path/Which/May/Change/conf/LoggerInfo.properties</env-entry-value>
</env-entry>
As the above xml code depicts, I have placed a Properties file somewhere in the local Filesystem, and I want my Web Service to initialize its logger class, based on that configuration. As you can realize this path changes every time I deploy my web service to another server.
Thus, I figured out that I may be able to use the $CATALINA_BASE property, in order to make the environment entry path smaller. How can I retrieve the CATALINA_BASE value from inside my Java Web Service's Code (how is done on Linux and how is done on Windows)??
Thank you.
try System.getProperty("catalina.base");
I am working on web application which is running on jetty server.
In this application I am uploading and image and use this image in my jsp page.
Now when I want to delete it using
Files.delete(File Path)
It gives me error
java.nio.file.FileSystemException: "File Path": The process cannot access the file because it is being used by another process.
Close all streams associated with that file before you attempt to delete it. Consider also the use of try-with-resources with the file you're uploading to.
On Windows Jetty is locking static files it serves via default servlet. It is a common issue. It has something to do with caching. See wiki:
http://wiki.eclipse.org/Jetty/Howto/Deal_with_Locked_Windows_Files
You need to switch useFileMappedBuffer to false.
I have developed a Java EE web application. This application allows a user to upload a file with the help of a browser. Once the user has uploaded his file, this application first stores the uploaded file on the server (on which it is running) and then processes it.
At present, I am storing the file on the server as follows:
try {
// formFile represents the uploaded file
FormFile formFile = programForm.getTheFile();
String path = getServlet().getServletContext().getRealPath("") + "/"
+ formFile.getFileName();
System.out.println(path);
file = new File(path);
outputStream = new FileOutputStream(file);
outputStream.write(formFile.getFileData());
}
where, the formFile represents the uploaded file.
Now, the problem is that it is running fine on some servers but on some servers the getServlet().getServletContext().getRealPath("") is returning null so the final path that I am getting is null/filename and the file doesn't store on the server.
When I checked the API for ServletContext.getRealPath() method, I found the following:
public java.lang.String getRealPath(java.lang.String path)
Returns a String containing the real path for a given virtual path. For example, the path "/index.html" returns the absolute file path on the server's filesystem would be served by a request for "http://host/contextPath/index.html", where contextPath is the context path of this ServletContext.
The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).
So, Is there any other way by which I can store files on those servers also which is returning null for getServlet().getServletContext().getRealPath("")
By spec, the only "real" path you are guaranteed to get form a servlet container is a temp directory.
You can get that via the ServletContext.gerAttribute("javax.servlet.context.tempdir"). However, these files are not visible to the web context (i.e. you can not publish a simple URL to deliver those files), and the files are not guaranteed in any way to survive a web app or server restart.
If you simply need a place to store a working file for a short time, then this will work fine for you.
If you really need a directory, you can make it a configuration parameter (either an environment variable, a Java property (i.e. java -Dyour.file.here=/tmp/files ...), a context parameter set in the web.xml, a configuration parameter stored in your database via a web form, etc.). Then it's up to the deployer to set up this directory for you.
However, if you need to actually later serve up that file, you will either need a container specific mechanism to "mount" external directories in to your web app (Glassfish as "alternate doc roots", others have similar concepts), or you will need to write a servlet/filter to serve up file store outside of your web app. This FileServlet is quite complete, and as you can see, creating your own, while not difficult, isn't trivial to do it right.
Edit:
The basic gist is the same, but rather than using "getRealPath", simply use "getInitParameter".
So:
String filePath = getServletContext().getInitParameter("storedFilePath") + "/" + fileName;
And be on your way.
Edit again:
As for the contents of the path, I'd give it an absolute path. Otherwise, you would need to KNOW where the app server sets its default path to during exeuction, and each app server may well use different directories. For example, I believe the working directory for Glassfish is the config directory of the running domain. Not a particularly obvious choice.
So, use an absolute path, most definitely. That way you KNOW where the files will go, and you can control the access permissions at the OS level for that directory, if that's necessary.
Writing to the file system from a Java EE container is not really recommended, especially if you need to process the written data:
it is not transactional
it harms the portability (what if you are in a clustered environment)
it requires to setup external parameters for the target location
If this is an option, I would store the files in database or use a JCR repository (like Jackrabbit).
I have an AXIS servlet which deployed on an apache tomcat server on windows.
I wrote a web service which I want to run on AXIS.
When I want to deploy my web service, I make a jar file from the classes, and then I copy them to "axis\WEB-INF\lib" directory. Then I deploy the web service using a wsdd file.
My question is - how can I pass parameters to the web service, and how can I read them?
The only web.xml file that I have, is the AXIS web.xml file. Should I put them there?
I came across with exactly same issue. I have a not so perfect solution. I am using a properties file to store params and access this properties file in the service classes. I am facing problem when I put all my classes in to a jar file. I am able to access properties file in my service class if I place properties file inside the jar file. I am unable to access properties file (without hardcoding the path) when I place it outside jar file. For maintainance point of view it is good practice to keep properties file accessible easyly.
-Rao