0 Replies Latest reply: May 8, 2012 3:26 PM by Suman Ghosh RSS

    Accessing local file-system using Java 7 NIO.2 classes throws an exception when deployed in JBoss

    Suman Ghosh Newbie

      Hi,

       

      I am actually working on a mainframe/unix platform (the problem is restricted to mainframe/unix platforms only - it does not occur with JBoss in windows), and would like to read the metadata (dataset name etc) for the underlying file system. I am using the following NIO.2 constructs to achieve the same -

       

      File file = new File(folderPath);    /* folderPath corresponds to a valid folder location. */

      System.out.println("Read: "+file.canRead()+", Write: "+file.canWrite()+", Execute: "+file.canExecute());  /* Gives true for all three */

      //final Path mypath = FileSystems.getDefault().getPath(folderPath);   /* Have used this or the next statement to get the Path object, and am getting the same results in both cases */

      Path mypath = file.toPath();

      final FileStore myfs = Files.getFileStore(mypath);

      String fileSystemName = myfs.name();

      String fileSystemType = myfs.type();

      System.out.println("Current file system, name: " + fileSystemName);

      System.out.println("Current file system, type: " + fileSystemType);

       

       

      This code works perfectly fine when deployed as a standalone Java class on the system.

       

      But whenever this code is deployed and run from inside a WAR in JBoss, it is throwing an exception like -

       

      java.nio.file.NoSuchFileException: /u/users/myfolder

      sun.nio.fs.UnixException.translateToIOException(UnixException.java:98)

      sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:114)

      sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:119)

      sun.nio.fs.UnixFileStore.devFor(UnixFileStore.java:69)

      sun.nio.fs.UnixFileStore.<init>(UnixFileStore.java:76)

      sun.nio.fs.ZosFileStore.<init>(ZosFileStore.java:20)

      sun.nio.fs.ZosFileSystemProvider.getFileStore(ZosFileSystemProvider.java:27)

      sun.nio.fs.ZosFileSystemProvider.getFileStore(ZosFileSystemProvider.java:19)

      sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:379)

      java.nio.file.Files.getFileStore(Files.java:1416)

      org.apache.jsp.nio2_jsp._jspService(nio2_jsp.java:101)

      org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

      javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

      org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)

      org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)

      org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)

      javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

      org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

       

       

      Can anybody shed some light on why this exeption appears ONLY when deployed inside a WAR file, and not otherwise? I was thinking in the lines of security, but since the legacy java.io.File object can easily access (read/write/execute) everything in this environment, I am stumped here!