getRealPath Depricated?

[Mike London]

Hi,

If you need the full path to a directory under the Web Root, how do you do that without getRealPath()?

Creating a file with f = new FileOutputStream() will fail without a full path.

In my testing a path like \webroot\somedir\somefile.txt will fail.

I'm in a JSF page so I am currently using:

HttpServletRequest request = (HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();

to get to the request scope, but I'm sure this applies to JSP as well.

Any help would be appreciated.

Thanks!!!

-- Mike

[Bear Bibeault]

but I'm sure this applies to JSP as well

Nope. No such thing as FacesContext outside of JSF.

But to answer your original question, check out the methods on ServletContext.

[Mike London]

Sorry, my question must have not have been clear.

I was trying to ask what I would use instead of getRealPath() that would give me a full path to be able to create a file (now that getRealPath() is depricated).

Hope this is clear.

Thanks.

-- M

[Ben Souther]

First, getRealPath isn't going anywhere.
The notes in request.getRealPath (the deprecated one) tell you to use ServletContext.getRealPath which isn't deprecated.
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#getRealPath(java.lang.String)

Regardless of whether it's deprecated or not, it's not a great idea to rely on it. There can only be a path to a resource in a webapp if the app is being run from an exploded file system. If the application is being run from a packed war file, getRealPath will return null.

I've always felt it's better to make the path to any resources you want to write to configurable via context or servlet init-params. For read-only resources, it's better to rely on Request.getResourceAsStream
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContext.html#getResourceAsStream(java.lang.String)
[ December 27, 2005: Message edited by: Ben Souther ]

[Mike London]

Hi Ben,

Hmmm, doesn't work...

If I change

HttpServletRequest request =
(HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();

String webRoot = request.getRealPath("/");


to:


ServletContext request =
(ServletContext)FacesContext.getCurrentInstance().getExternalContext().getRequest();

String webRoot = request.getRealPath("/");

==============

And, then try to create a FileOutputStream that's located on the Web Root, it fails with a FileNotFound Exception.

Using the full path of the first example above succeeds.

Is there a programmatic solution for this?

Were you suggesting to hard-code full path in an init-param?

Thanks again!!!

-- Mike

[Bear Bibeault]

Since you are using JSF interfaces this would be more appropriate in the JSF forum.

[Gregg Bolinger]

Were you suggesting to hard-code full path in an init-param?

I would follow Ben's advice on this. There are several different ways to configure this since getRealPath is not reliable, as Ben stated. You can put it in the web.xml as an init-param or you can put it in your own config of sorts. For example, on one project I worked on I had a simple properties file that I loaded on application startup via a context listener. I loaded the config file into a map and put it in application scope. I had a helper class that made it real easy for me to get the map back starting from the FacesContext.

But that is only one way. You could store the value in the database if you wanted to.

[Mike London]

Hi Gregg,

So, I'd just create a properties file and on each server, store the full path to the webRoot in there. Then, I could just concatenate the file name I need to create and I'm all set.

I was hoping this could be done programmatically, but perhaps this is the best and most reliable method.

Thanks!!!

- Mike

[Gregg Bolinger]

Originally posted by Mike London:
Hi Gregg,

So, I'd just create a properties file and on each server, store the full path to the webRoot in there. Then, I could just concatenate the file name I need to create and I'm all set.

I was hoping this could be done programmatically, but perhaps this is the best and most reliable method.

Thanks!!!

- Mike

Right, the problem with doing it all programmatically (by that I mean all from java code, no config type files) is that, like Ben already mentioned, there is no 100% reliable means to get the path you need.

[Mike London]

Thanks again.

I really appreciate your replies. <s>

- Mike

[Tim Holloway]

For temporary files, go all the way back to basic java.io.File and use the create temp file method. Your appserver will generally customize the runtime, so as an example, createTempFile() when used in a Tomcat-deployed app will probably construct the file in TOMCAT_HOME/temp.

If you intend on reading and writing permanent files, What I'd recommend is that you define their location in your web.xml as env-entry items. This takes their definitions out of program code and places them in a file that can be edited using a deployment tool (Tomcat can also override the value in web.xml as a Context directive). Your webapp program code can retrieve the configured path info using JNDI (java:comp/env).

People tend to forget that the classpath for a webapp not only need not be sourcing from a directory tree, in fact, it need not even be coming from a local source. If Tomcat (or WebLogic for that matter), wanted to define a context as getting its classes from URL "svn://production-modules.myco.com/webapps/funnyapp.war", that's perfectly allowable under the servlet architecture. Which is why using a relative path may sound like a good idea, but isn't.

[Sudhakar Ponnazhagan]

Use ServletContext.getRealPath which is not deprecated.

This is not avaiable to JSF layers.

As JSF is purely a presentation layer, there should be a business
and transaction layer in your design.

Whereas getRealPath it is available on Spring Framework layer.

getRealPath(ServletContext servletContext, String path)

JSF is good on presentation. Don't dig to much on JSF.
Your ideas are great.

[Mike London]

I seem to recall that I tried this, but, as I recall, it only returned a relative path which failed when trying to create a file.

-- Mike

[Rich Sezov]

If anyone still cares about this (this thread is a year old as of my post), I have solved this issue in my application.

I'm writing an Ajax application that has a dynamic call to a JFreeChart chart that I want to display only after the user has made some database queries. JFreeChart's writeChartAsPNG() function does not allow a null chart object to be passed, so I want to serve up a transparent png instead of the chart in the servlet which serves up the chart.

Using the Jakarta Commons IO package, my code looks like this:

OutputStream out = res.getOutputStream();
ServletContext ctx = this.getServletContext();
URL context = ctx.getResource("/images/transparent.png");
byte [] transparent = FileUtils.readFileToByteArray(new File(new URI(context.toString())));
IOUtils.write(transparent, out);

This allows programmatic access to stream a resource from the web application's file system.

[Mike London]

Rich,

Interesting. Do you know if the JFreeChart ($) documentation covers the issue you solved?

I'm about to order it, but am wondering about "basic issues" (that is, that should be documented) like the one you solved (where the issue is nowhere to be found in the docs).

Thanks in advance for your reply.

-- Mike