访问被拒绝写入 ApplicationResources.properties 文件

Question

对于我正在开发的应用程序中的双语支持，我们使用 Spring 消息传递，它使用两个文件，ApplicationResources.properties 和 ApplicationResources_fr.properties。这很好用。

现在我正在尝试通过使其更具动态性来扩展它。应用程序将从数据库中读取键值对并插入它们，这给了我以下错误：

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

我能够检查键值对，因此我知道我使用的路径是正确的。我还通过右键单击并访问我系统上的实际文件来检查 Eclipse 属性中的文件，它们不是只读的。我不相信它们是加密的，因为我可以使用 notepad++ 打开和查看。

这是我的测试代码，显示我可以查看它们

 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();
        }

这是我尝试写入文件并得到错误的地方：

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();
      }

所以数据库查询成功，用注释掉的system.out.println 测试。最终引发错误的是以下几行：

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

更新：我在 java.util.Properties 上进行了搜索，这让我找到了上面的 javadocs，哇，这简化了很多事情。我现在可以获取一个属性值或检查该键是否存在于 6 行代码中（不包括 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

更新 2： 使用 java.util.Properties 存在一个问题，即您丢失了原始文件的所有格式，因此空白、cmets 和排序都丢失了。在另一个answer 中，有人建议使用 Apache 的 Commons Configuration API。我打算试试看。

Answer 1

所以我最终创建了一个类来处理与 ApplicationResources(_fr).properties 文件的交互，而不是在 DAO 中进行。这是因为我计划在更多地方使用它。我还开始使用 java.util.Properties Javadocs 中的方法，这些方法被证明非常有用并简化了许多领域。

以下是我的新文件写入/属性存储代码。

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();
    }

让我们比较一下新的和原来的 OutputStreams：

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

此答案不完整，原因如下。

我无法解释为什么原始方法失败并导致“访问被拒绝错误”。

更多关于我的原因，这实际上并没有改变我期望或想要的文件。我希望更改出现在我的项目导航器中的文件，但是在查看时未观察到更改。如果我使用绝对路径 (C:\...) 并覆盖文件，那么我可以按预期更改它，但是随着服务器的更改以及它的不良编程和危险性，必须更改此路径。此工作方法正在更改某种临时文件或正在运行的文件（通过路径确认，因为显示新值的文件位于 tmp0 文件夹中）。经过一些测试，这个临时文件只有在原始文件发生变化时才会在启动时被覆盖，否则新值会在应用程序启动时保持不变。

我也不确定这个文件的范围。我无法判断是否所有与网站交互的用户都会导致对同一文件的更改。如果所有用户都在与文件交互，则可能会发生跨会话的潜在泄漏。每个会话也有可能具有孤立的值，并可能导致信息丢失。我怀疑所有用户都在与相同的资源进行交互，但没有执行完全肯定的测试。 更新：我已确认所有用户都与同一个临时文件进行交互。