Path when creating a new file

[Angus Ferguson]

Think of the WAR as being its own virtual filesystem completely distinct from the OS filesystem of the server that the webapp is deployed to

.

Taking to path from the root of the .WAR like this:

 InputStream inputStream = request.getResourceAsStream("LeanRouteREST_SPRING_TDD_MAVEN/src/main/resources/config/test.xml");

But the reason why I cant compile is that

getResourceAsStream

doesnt compile.

The error is:

cant find symbol 
                   symbol getResourceAsStream(String)
                   location: variable request of type HttpServletRequest

Any idea, please?

[Dave Tolls]

I know how both resource things work (and getResourceAsStream on class uses '/' not '.').

Am I being blind then?
Where in HttpServletRequest is there a getResourceAsStream method?

The getResourceAsStream for servlets etc is on ServletContext.

ETA: And there you go. A compilation error.
Wouldn't it be an idea to actually tell us what the problem is?

[Angus Ferguson]

I changed it by context and the compilation error went. The code now is like this:

public class ControllerLeanRoute extends HttpServlet {
  
    private String path = "";

    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException, MessagingException {
        response.setContentType("text/html;charset=UTF-8");

        LeanRouteLoadTestAnalyzerFilesTasks analyzerFilesTasks = new LeanRouteLoadTestAnalyzerFilesTasks();
        try (PrintWriter out = response.getWriter()) {


            Properties prop = new Properties();
            String filePath = "";
         

               ServletContext context = this.getServletContext();
              
                InputStream inputStream = context.getResourceAsStream("LeanRouteREST_SPRING_TDD_MAVEN/src/main/resources/config/test.xml");
                prop.load(inputStream);
                filePath = prop.getProperty("json.filepath");       
        
            request.getSession().setAttribute("status", analyzerFilesTasks.analyzerReader(3.6f, filePath));
         

            response.sendRedirect("respuesta.jsp");
        }

    }

The app compiles I have uploaded the .war to a server and after submit the info I get a white screen. I have checked the remote Tomcat and no errors at all it looks normal.

I am also trying to debug it locally in order to discover the possible error but I get this

NetBeans: Deploying on tomcat80:home=/Users/isaac/Documents/servidor/apache-tomcat-8.0.26
    profile mode: false
    debug mode: false
    force redeploy: true

Any idea, please about the reason of the white page or the reason it is not been displayed in local?

[Dave Tolls]

Why are you getting the response writer and then not using it, but redirect to a jsp instead?

Do one or the other, not both.

Also, why redirect and not forward?

[Angus Ferguson]

public class ControllerLeanRoute extends HttpServlet {
   
    private String path = "";
 
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException, MessagingException {
        response.setContentType("text/html;charset=UTF-8");
 
        LeanRouteLoadTestAnalyzerFilesTasks analyzerFilesTasks = new LeanRouteLoadTestAnalyzerFilesTasks();
       
 
 
            Properties prop = new Properties();
            String filePath = "";
          
 
               ServletContext context = this.getServletContext();
               
                InputStream inputStream = context.getResourceAsStream("LeanRouteREST_SPRING_TDD_MAVEN/src/main/resources/config/test.xml");
                prop.load(inputStream);
                filePath = prop.getProperty("json.filepath");       
         
            request.getSession().setAttribute("status", analyzerFilesTasks.analyzerReader(3.6f, filePath));
          
 
            response.sendRedirect("respuesta.jsp");
     
 
    }

I tried forward with the same result.

I have detected the line which provokes the white line.

 prop.load(inputStream);

I think it is still a problem with the path.

[Dave Tolls]

I would add a decent logging system and log everything.
At the moment you're flying blind.

What does your JSP page do?
What is it supposed to display?

Speaking of logs, is there anything in the logs?

[Angus Ferguson]

The jsp displays a text just hardcoded it is not relevant. It issue is about the path, the logs doesnt show any error.

catalina.out

Dec 18, 2015 12:09:28 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deployment of web application archive /home/leeanrou/appservers/apache-tomcat-7.0.62/webapps/LeanRouteREST_SPRING_TDD_MAVEN-1.0-SNAPSHOT.war has finished in 120 ms

[Tim Holloway]

Dave Tolls wrote:I know how both resource things work (and getResourceAsStream on class uses '/' not '.').

You are correct, but the CLASSLOADERs do. Classpath-retrieved resources use package (dot) path format.

The J2EE getResource methods don't use the classloaders. They operate on resource paths, which as I said, are a "file system" rooted at the WAR root. The stock classpath for a WAR is based on WEB-INF/lib JARs and WEB-INF/classes. So not only is the path notation different, but the path roots are different.

[Dave Tolls]

Tim Holloway wrote:

Dave Tolls wrote:I know how both resource things work (and getResourceAsStream on class uses '/' not '.').

You are correct, but the CLASSLOADERs do. Classpath-retrieved resources use package (dot) path format.

The J2EE getResource methods don't use the classloaders. They operate on resource paths, which as I said, are a "file system" rooted at the WAR root. The stock classpath for a WAR is based on WEB-INF/lib JARs and WEB-INF/classes. So not only is the path notation different, but the path roots are different.

As I said, though, I was trying to find out exactly what getResourceAsStream Isaac was on about, as the one he was using didn't exist, so made an assumption (my mistake) that it was the Class one.

I knew that the context one used the war as the root.

Not sure what you are talking about re: "(c)lasspath-retrieved resources" as I'm solely talking about the methods getResource and getResourceAsStream. Both of which (on both Class and ClassLoader) use '/' as the separator.
Class.getResource
ClassLoader.getResource

[Dave Tolls]

Isaac Ferguson wrote:The jsp displays a text just hardcoded it is not relevant. It issue is about the path, the logs doesnt show any error.

How do you know the issue is about the path?
All you have given us here is that the page is coming up blank (does the url in the browser change, by the way?).

[Angus Ferguson]

public class ControllerLeanRoute extends HttpServlet {
    
    private String path = "";
  
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException, MessagingException {
        response.setContentType("text/html;charset=UTF-8");
  
        LeanRouteLoadTestAnalyzerFilesTasks analyzerFilesTasks = new LeanRouteLoadTestAnalyzerFilesTasks();
        
  
  
            Properties prop = new Properties();
            String filePath = "";
           
  
               ServletContext context = this.getServletContext();
                
                InputStream inputStream = context.getResourceAsStream("LeanRouteREST_SPRING_TDD_MAVEN/src/main/resources/config/test.xml");
                prop.load(inputStream);
                filePath = prop.getProperty("json.filepath");       
          
            request.getSession().setAttribute("status", analyzerFilesTasks.analyzerReader(3.6f, filePath));
           
  
            response.sendRedirect("respuesta.jsp");
      
  
    }

I tried forward with the same result.

I have detected the line which provokes the white line.

prop.load(inputStream);


I think it is still a problem with the path.

[Tim Holloway]

Dave Tolls wrote:

Not sure what you are talking about re: "(c)lasspath-retrieved resources" as I'm solely talking about the methods getResource and getResourceAsStream.

Let's go back to the original question. The intent was to retrieve a property resource in order to obtain a property value.

There are 2 clean ways (and quite a few dirty ones) to do that within a web application when the property resource is contained within the web application (WAR).

One is to use the getResource methods. The other is to retrieve the resource as a classpath resource. Both are equally good although I favor the classpath approach for properties, since you can then leverage off the resource bundling and I18n support of basic Java properties instead of merely retrieving the resource plain and simple. However we never went into that, it's merely that the classpath was briefly considered as a channel to get the resource in question. If you used the classpath, however, the proper mechanism to use is a classloader, since classloaders may or may not get all or part of the resources that they return from actual file paths. And classloaders identify resources (including property files) using classname notation (dots).

Of course, neither method works for resources that are external to the WAR, which is how this particular project seems to be currently set up (attempting to pull from an IDE workfile). In the case of an external resource, you need to supply the resource file location as an absolute classpath (because relative paths are dangerous in webapps), and use the java.io methods to open and read it. Or obtain the resource in some other non-J2EE method such as from a table in a database. Or, for small sets of resource values, via JNDI.

[Dave Tolls]

Tim Holloway wrote:
Let's go back to the original question. The intent was to retrieve a property resource in order to obtain a property value.

(snip bits for brevity)

I see where you're coming from now!

I was focussing on what Isaac was posting at that point, since I figured he had rejected (for whatever reason) other solutions.
Which is why I was looking simply at the (attempted) call to getResourceAsStream.

Anyway...we can probably shove this derail off to the side.

[Dave Tolls]

Isaac Ferguson wrote:
I tried forward with the same result.

I have detected the line which provokes the white line.

prop.load(inputStream);


I think it is still a problem with the path.

How is prop.load causing a blank page?
How did you figure out it was that line?
You say there's no exception.

I see no logging.

[Angus Ferguson]

For the following code:

 ServletContext context = this.getServletContext();

        InputStream inputStream = context.getResourceAsStream("/filesRawDataTests/testStaticSports.rtf");
        
        try {
            prop.load(inputStream);

        } catch (Exception e) {

            System.out.println("exception :"+e.getStackTrace());
             System.out.println("exception :"+e.getMessage());
            LOG.getName().toString(); 
        }

This is the info I get:

exception :[Ljava.lang.StackTraceElement;@4f538918
exception :null

This happens in the remote server. I moved the file with the data to a folder in the Macintosh level (like C:/ in Windows) like this:

/filesRawDataTests/testStaticSports.rtf

Any idea, please?

[Bear Bibeault]

You're getting a null pointer exception. Are you going to start using logging to see what's going on, or are you going to continue to waste time guessing?

Also, always post the entire stack trace. Guessing what small portions are meaningful is a losing game.

[Dave Tolls]

So, an exception.

You have to remember, we cannot see your computer, or how you are running this thing.
You need to explain everything, and exceptions and their stack traces (using printStackTrace or a proper logging framework) are fundamental at trying to work out what is wrong.

Anyway, that null pointer exception implies that the file does not exist.

Which brings us back to, is that file being deployed on the server?
For which you have to actually look at the server, and not your IDE.

[Angus Ferguson]

First I am testing in my local and then when it will work I will upload the working version.

I will work in building a proper logging piece of code. I will keep you updated!

Happy Christmas!!

Isaac