Access is denied for writing to ApplicationResources.properties file

Question

For bilingual support in an application I am working on, we are using Spring messaging which uses two files, ApplicationResources.properties and ApplicationResources_fr.properties. This works well.

Now I am trying to expand on this by making it a little more dynamic. The application will read key value pairs from the database and insert them, which gives me the following error:

 java.io.FileNotFoundException: \ApplicationResources.properties (Access is denied)

I am able to check on the key value pairs so I know the path I am using is correct. I have also checked the files in Eclipse properties by right clicking, and by visiting the actual file on my system, and they are not read-only. I do not believe they are encrypted because I am able to open and view with notepad++.

Here is my testing code which shows I can view them

 Properties test_prop = null;
        InputStream is = null;
        try {
            test_prop = new Properties();

            is = this.getClass().getResourceAsStream(en_path);
            test_prop.load(is);
            Set<Object> keys = test_prop.keySet();
            boolean key_found = false;
            for(Object k:keys) {
                String key = (String)k;
                if(key.equals("f12345"))    
                {
                    key_found=true;
                    break;
                }
            }
System.out.println("Language Properties Test in DAO:" + (key_found? "Key Found" : "Key not found"));
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (NullPointerException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

Here is where I try to write to the file, and get the error:

ResultSet rs = null;
try ( 
    Connection connection = jdbcTemplate.getDataSource().getConnection();
    CallableStatement callableStatement = connection.prepareCall(test_prod_cur);
    )
    {
        callableStatement.registerOutParameter(1, OracleTypes.CURSOR);
        callableStatement.executeUpdate();
        rs = (ResultSet) callableStatement.getObject(1);
        while (rs.next())
        {
              String thead = rs.getString(1);
//System.out.println(thead + " " + rs.getString(2) + " " + rs.getString(3));
              en_prop.setProperty(keyheader+thead, rs.getString(2));
              fr_prop.setProperty(keyheader+thead, rs.getString(3));
          }
      }
      catch (SQLException e)
      {
          System.out.println("SQLException - bilingual values - CLUDAOImpl");
          System.out.println(e.getMessage());
      }

    //add to properties files
      //*       
      try (OutputStream en_os = new FileOutputStream(en_path);)
      {
            en_prop.store(en_os, null);
        } catch (IOException e) {
            e.printStackTrace();
        }

      try(OutputStream fr_os = new FileOutputStream(en_path);)
      {
            fr_prop.store(fr_os, null);
        } catch (IOException e) {
            e.printStackTrace();
      }

So the database query is successful, that was tested with the commented out system.out.println. It is the following lines that end up throwing the error:

 en_prop.store(en_os, null);
 fr_prop.store(fr_os, null);

Update: I did a search on the java.util.Properties which lead me to the javadocs on it and wow does that simplify many things. I can now grab a property value or check if the key exists in 6 lines of code (not counting try catch).

 Properties prop = null;
 InputStream is = null;
 this.prop = new Properties();
 is = this.getClass().getResourceAsStream(path);
 prop.load(is);
 this.prop.getProperty("key name"); //returns value of key, or null
 this.prop.containsKey("key name"); //returns true if key exists

Update2: There is an issue using java.util.Properties and that is you lose all formatting of the original file, so white-space, comments, and ordering are all lost. In another answer someone suggested using Apache's Commons Configuration API. I plan on trying it out.

Answer 1

So I ended up creating a class to handle interactions with the ApplicationResources(_fr).properties files instead of doing it in the DAO. This was because I plan on using it in more places. I also started using methods from the java.util.Properties Javadocs which proved very helpful and simplified many areas.

Below is my new file write/properties store code.

try (
        OutputStream en_os = new FileOutputStream(getClass().getResource(en_path).getFile(),false);
        OutputStream fr_os = new FileOutputStream(getClass().getResource(fr_path).getFile(), false);
    )
    {
        en_prop.store(en_os, null);
        fr_prop.store(fr_os, null);
    } catch (IOException e) {
        e.printStackTrace();
    }

Lets compare the new and original OutputStreams:

OutputStream en_os = new FileOutputStream(getClass().getResource(en_path).getFile(),false); //new
OutputStream en_os = new FileOutputStream(en_path); //original, Access is Denied

This answer is incomplete for the following reasons .

I am unable to explain why the original method failed and resulted in a "Access is denied error".

More concerning reason to me, this doesnt actually alter the file I am expecting or wanting. I expected to alter the file that appears in my project navigator, but when viewed changes are not observed. If I use an absolute path (C:\\...) and overwrite the file then I can alter it as expected, but this path would have to be changed as servers are changed and its bad programming and dangerous. This working method is altering some kind of temp or running file (as confirmed via the path as the file that shows the new values is in the tmp0 folder). After some testing, this temporary file is overwritten on startup only when the original file has been changed, otherwise the new values persist across application starting.

I am also unsure as to the scope of this file. I am unable to tell if all users interacting with the website would cause changes to the same file. If all users are interacting with the file, then potential leakage across sessions could occur. It is also possible that each session has isolated values and could lead to missing information. I suspect that all users are interacting with the same resource but have not performed the testing required to be absolutely positive about this. UPDATE: I have confirmed that all users interact with the same temporary file.