避免对属性文件路径规范进行硬编码
我在将 JAVA 程序使用的属性文件的路径规范与实现本身解耦时遇到了一个小问题。 该程序可能部署在具有不同目录结构的多个位置，并且我不希望将路径规范硬编码到程序代码中。
这就是现在的情况。
我有一个文件夹服务器/ 里面有2个包core/ & support/ （两者下面都有很多子包）
我之前所做的是，只要需要指定属性文件的路径，我就给出一个相对路径，即properties/ 在这种情况下，属性文件需要位于您启动程序的任何位置。这在测试期间有效，当我使用手动启动程序时 “java”。我会将属性文件夹放在启动程序的任何位置。 但在实际场景中，该程序将由脚本（ksh）自动启动，该脚本由作业按计划的时间间隔执行。
在这种情况下，给出相对路径不起作用。我尝试将属性文件放入脚本所在的文件夹中，但这也不起作用。
现在，我必须手动指定每个环境的路径，重新编译代码并为每个环境部署单独的副本。 有没有一种方法可以消除这种耦合，并且只为属性文件提供一个位置，而不管它需要部署在哪里？
I'm having a small problem decoupling the path specification for properties files that my JAVA program uses , from the implementation itself.
The program may be deployed at multiple locations with different directory structures and I don't want the path specification to be hard coded into the Program code.
Here is the situation as it exists now.
I have one folder server/
Inside which there are 2 packages core/ & support/ (both of which have many subpackages underneath)
What I had done earlier was that , wherever the path for a properties file needed to be specified , I just gave a relative path i.e. properties/
In this scenario, the properties file needs to be wherever you're launching the program from. This worked during testing , when i was manually starting the program up using
"java ". and i would put the properties folder wherever I was starting the program from.
But in a real scenario, this program will be autostarted by a script (ksh) which is executed at scheduled intervals by a job.
In this case , giving the relative path doesn't work. I tried putting the properties files in the folder where the scripts are located , but that doesn't work either.
Right now , I am having to manually specify the path for each environment recompile the code and deploy a separate copy for each environment.
Is there any way to remove this coupling and just have one location for the properties file regardless of where it needs to be deployed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 System.Properties 条目指定路径，然后在命令行上通过添加它
在您的应用程序中，您可以使用 System.getProperty("myProp") 检索它，只需确保添加适当的测试并处理“未找到属性”场景。
另一种做法是将 props 放在 jar 中，然后使用 LoadResource 加载它们，这样您只需要在每次部署中部署不同的配置 jar，但我认为 System.setProperty 方式是最快的。
use a System.Properties entry to specify the path, then on command line add it via
In your app, you can retrieve it with
System.getProperty("myProp"), just be sure to add proper testing and handle the Property Not Found scenario.Another practice is to leave props in a jar and then load 'em with the LoadResource, in this way you just need to deploy different config jars in each deployment, but I think that the System.setProperty way is the fastest.
通常，一些客户可能不喜欢在启动应用程序时使用 -D=。事实上，您还应该提供一个 .sh/.bat 脚本文件以及您的 jar 文件，以便客户端只需双击该脚本即可运行您的应用程序。
在此脚本中，您可以声明变量，您可以要求客户端进行相应配置。客户端只需在文本编辑器中打开脚本文件并输入配置文件的路径即可。
使用此脚本文件的其他方法是执行以下操作：
1) 检查系统环境中是否设置了 YOUR_APP_NAME_CONFIG 变量。如果是，则转到步骤 3 或转到步骤 2
2) 在命令行上询问用户配置文件的位置。检查位置是否正确。如果正确，则使用配置文件位置的值设置环境变量 YOUR_APP_NAME_CONFIG。
3）启动您的应用程序
拥有应用程序的脚本文件可以让您自由地围绕应用程序的环境配置自动化进行许多工作。
在您的应用程序中，通过 System.getProperty("YOUR_APP_NAME_CONFIG") 获取配置文件路径。
这一切看起来可能很痛苦，但从客户的角度思考。对于客户来说，这很简单，他只需双击脚本即可启动您的应用程序，并且对于首次启动应用程序，脚本会根据需要要求一些输入，然后您的应用程序就可以开始运行了:)
Generally some clients may not prefer to use -D= while starting your application. In fact you should also provide a .sh/.bat script file along with your jar file so that client can just double click on the script to run your application.
In this script you can have variable declared which you can ask the client to be configure accordingly. Client can just open the script file in text editor and type in the path of the configuration file.
Other way to use this script file would be to do following :
1) Check if YOUR_APP_NAME_CONFIG variable is set in system environment. If yes then go to step 3 or got to step 2
2) Ask the user on command line for the location of configuration file. Check if the location is correct. If correct then set the environment variable YOUR_APP_NAME_CONFIG with value of location of configuration file.
3)Start your application
Having a script file for your application gives you lots of liberty to do many stuff around automating the environment configuration for your application.
In your application get the config file path by System.getProperty("YOUR_APP_NAME_CONFIG").
This all may look like lot of pain but think from client perspective. Its cake walk for client that he just double click a script to start your application and for the first launch of application the script asks for some inputs if needed and then your application is good to go :)
我所做的是通过 jar 调用传递另一个类路径参数。
java -cp classpath1;folder-where-propertiesfile- located Application.jar并在应用程序中使用
getClass().getClassLoader( ).getResourcesAsStream("properties-file");这将自动从相应的类路径文件夹中获取属性文件。
通过此设置，我可以更改文件夹内的属性文件并使用相同的 jar 文件无需重新归档 jar..
What I did was pass another classpath parameter with the jar invocation..
java -cp classpath1;folder-where-propertiesfile-located Application.jarand in the application use
getClass().getClassLoader().getResourcesAsStream("properties-file");This will automatically fetch the properties file form the appropriate classpath folder..
With this setup, I could change the properties file inside the folder and use the same jar file without re-archiving the jar..