博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
java配置文件的书写
阅读量:2401 次
发布时间:2019-05-10

本文共 14141 字,大约阅读时间需要 47 分钟。

Using Properties Files in Java Applications (And Autoload)

Properties files are one of the most frequently used mechanism for storing configuration information for applications. And so is the code to access these properties from the application. This article is intended to demonstrate (source code can be downloaded ) a simple way of configuring and using Properties files in Java applications.

Please note that, the mechanism is not limited to properties files. The approach supports XML configuration files as well.

The steps are defined below and as we move along, we’ll try and explain the rationale for each of the items:

1.    Define System variable for properties file location. Define a system/environment variable that points to the folder, where the properties files will be placed. Finding the properties files through a system/environment variable is straight-forward and helps avoid the classpath issues often found using properties files in webapps. In cases where a system/environment variable cannot be defined, this variable can be passed to the application as an argument. For e.g., java –D APP_PROPS=d:/Properties App

Let’s say the environment variable is called APP_PROPS and it points to D:/Properties. For demonstration, let’s assume there’re two properties files:

a.    app.properties
b.    security.properties

2.    The Properties Store. The properties store (class PropStore), will be used by the application code to fetch properties. For e.g., the following code reads the application title from the app.properties file.

String title = PropStore.getAppProps(“title”);

Let’s get into the code and see how the PropStore will be structured and how do we add new properties.

Structure. The properties store will have a static “Properties” field, for each “properties” file annotated with a custom annotation (PropertiesHolder, defined later). For e.g.,

public class PropStore {	@PropertiesHolder(file="app.properties", autoLoad=true)	private static Properties appProps;	@PropertiesHolder(file="security.properties")	private static Properties securityProps;	public static Properties getAppProps() {		return appProps;	}	public static Properties getSecurityProps() {		return securityProps;	}	protected static void setAppProps(Properties appProps) {		PropStore.appProps = appProps;	}	protected static void setSecurityProps(Properties securityProps) {		PropStore.securityProps = securityProps;	}}

For now, assume, the properties appProps and securityProps are magically loaded. So, the following code sippet can be used in the application code to read securityProps:

String appUser = PropStore.getSecurityProps().getProperty("APP_USER");

To add another properties file, all that needs to be done is add a static field, annotate it with PropertiesHolder with the properties file name as the file attribute, and define a public getter.

3.    PropertiesHolder. PropetiesHolder is a custom annotation, that we will use to annotate fields in the PropStore, and set the properties file that field will go against.

@Target(ElementType.FIELD)@Retention(RetentionPolicy.RUNTIME)public @interface PropertiesHolder {	String file();	boolean autoLoad() default false;}

4.    Loading Properties. Properties file need to be loaded at application startup since the application code uses the properties files. We’ll load the properties using PropsLoader class as demonstrated below. PropsLoader can then be used by a startup class (a startup servlet in webapps, or a bootstrap class in a desktop application, for e.g.).

Here’s what the PropsLoader does to load the properties files:

i.    Introspect the PropStore to get declared fields.
ii.    Loop on the fields and check if the field is annotated with PropertiesHolder.
iii.    If it is annotated with PropertiesHolder, create a “Properties” object and load the properties file (set with the file attribute of PropertiesHolder).
iv.    Call the appropriate setter, on the PropStore with this “Properties” object.
v.    Please note that if there’s a XML configuration file, another reading mechanism can be provided and a Properties object be built from that.

public class PropsLoader {	private static final String VAR_NAME = "APP_PROPS";	//TODO: Better Exception Handling	public static void load() throws Exception {		Field[] fields = PropStore.class.getDeclaredFields();		for(Field field:fields) {			if( field.isAnnotationPresent(PropertiesHolder.class) ) {				PropertiesHolder propsHolder = field.getAnnotation(PropertiesHolder.class);				loadPropsAndWatch( field.getName(), propsHolder );			}		}	}	//TODO: Better Exception Handling	private static void loadPropsAndWatch(String fieldName, PropertiesHolder propsHolder) throws Exception {		String propsFile = System.getProperty(VAR_NAME) + File.separator + propsHolder.file();		loadProperties(fieldName, propsFile);		if( propsHolder.autoLoad() ) {			PropsWatcherTask.watch( fieldName, propsFile, propsHolder );		}	}	//TODO: Better Exception Handling	protected static void loadProperties(String fieldName, String propsFile)			throws Exception {		String setterName = "set" + Character.toUpperCase(fieldName.charAt(0)) + fieldName.substring(1);		Method setter = PropStore.class.getDeclaredMethod(setterName, Properties.class);		Properties props = new Properties();		props.load( new FileInputStream(new File(propsFile) ) );		setter.invoke(null, props);	}}

5.    Auto Load. Although, not an absolute essential, sometimes, the properties files need to be auto-loaded in case there’s a change while the application is running.

To auto load properties, the PropsWatcherTask:

a.    Schedules itself to run every “x” minutes, and check the last modified time of the properties file to watch.
b.    If the new modified timestamp is newer than the timestamp used to build the task, the properties file is reloaded and the local timestamp set accordingly.

public class PropsWatcherTask extends TimerTask {	private String propsFile;	private long lastMod;	private String fieldName;	private final static Timer timer = new Timer();	private static final long INITIAL_DELAY = 1000 * 60 * 5;	private static final long INTERVAL  = 1000 * 60 * 5;	private PropsWatcherTask(long lastMod, String fieldName, String propsFileName) {		this.propsFile = propsFileName;		this.lastMod = lastMod;		this.fieldName = fieldName;	}	@Override	public void run() {		//check last modified time.		long newModTime = new File(propsFile).lastModified();		if( newModTime > lastMod ) {			try {				PropsLoader.loadProperties(fieldName, propsFile);			} catch (Exception e) {				e.printStackTrace();			}			this.lastMod = newModTime;		}	}	protected static void watch(String fieldName, String propsFileName, PropertiesHolder propsHolder) {		File propsFile = new File(propsFileName);		long lastMod = propsFile.lastModified();		timer.scheduleAtFixedRate( new PropsWatcherTask( lastMod, fieldName, propsFileName ) , INITIAL_DELAY, INTERVAL );	}}

6.    Test. The following simple JUnit can be used to test the PropsLoader for both auto load and otherwise.

public class PropStoreTest {	@Before	public void load() {		try {			PropsLoader.load();		} catch (Exception e) {			e.printStackTrace();		}	}	@Test	public void testProperties() throws Exception{		Assert.assertEquals("ABC Desktop", PropStore.getAppProps().getProperty("APP_TITLE"));		Assert.assertEquals("ADMIN", PropStore.getSecurityProps().getProperty("APP_USER"));	}	@Test	public void testAutoLoad() throws Exception {		write("APP_TITLE=New ABC Desktop");		synchronized(this) {			this.wait(45 * 1000);		}		Assert.assertEquals("New ABC Desktop", PropStore.getAppProps().getProperty("APP_TITLE"));		write("APP_TITLE=ABC Desktop");	}	private void write(String text) throws Exception {		PrintWriter pw = new PrintWriter( new FileWriter(System.getProperty("APP_PROPS") + File.separator + "app.properties"));		pw.print(text);		pw.close();	}	public static junit.framework.Test suite() {        return new JUnit4TestAdapter(PropStoreTest.class);    }}

Note the PropsLoader.load() being called from the load method of PropStoreTest. The PropsLoader.load() call will generally be made from some startup class (like a startup servlet, etc). To run the test, make sure the APP_PROPS variable is passed as a JVM parameter, or is set in the system properties.

Click to download the source code. Tester.zip contains the Tester folder, which can be directly imported into Eclipse. If you wish to run this with ant, use Tester/build/build.xml. (Please change the value for APP_PROPS on line 9 in build.xml).

<!--[endif]--><!--[if gte mso 9]> Normal 0 false false false MicrosoftInternetExplorer4 <![endif]--><!--[if gte mso 9]> <![endif]--> <!--[endif]-->

Properties files are one of the most frequently used mechanism for storing configuration information for applications. And so is the code to access these properties from the application. This article is intended to demonstrate a simple (Simple to use from the app and easy to maintain) way of configuring and using Properties files in Java applications.

 

Please note that, the mechanism is not limited to properties files. The approach supports XML configuration files as well.

 

The steps are defined below and as we move along, we’ll try and explain the rationale for each of the items:

 

<!--[if !supportLists]-->1. <!--[endif]-->Define System variable for properties file location. Define a system/environment variable that points to the folder, where the properties files will be placed. Finding the properties files through a system/environment variable is straight-forward and helps avoid the classpath issues often found using properties files in webapps. In cases where a system/environment variable cannot be defined, this variable can be passed to the application as an argument. For e.g., java –D APP_PROPS=d:/Properties App

 

Let’s say the environment variable is called APP_PROPS and it points to D:/Properties. For demonstration, let’s assume there’re two properties files:

<!--[if !supportLists]-->a. <!--[endif]-->app.properties

<!--[if !supportLists]-->b. <!--[endif]-->security.properties

 

<!--[if !supportLists]-->2. <!--[endif]-->The Properties Store. The properties store (class PropStore), will be used by the application code to fetch properties. For e.g., the following code reads the application title from the app.properties file.

 

String title = PropStore.getAppProps(“title”);

 

Let’s get into the code and see how the PropStore will be structured and how do we add new properties.

 

Structure. The properties store will have a static “Properties” field, for each “properties” file annotated with a custom annotation (PropertiesHolder, defined later). For e.g.,

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]-->

 

For now, assume, the properties appProps and securityProps are magically loaded. So, the following code sippet can be used in the application code to read securityProps:

 

String appUser =

PropStore.getSecurityProps().getProperty(“APP_USER”);

 

To add another properties file, all that needs to be done is add a static field, annotate it with PropertiesHolder with the properties file name as the file attribute, and define a public getter.

 

<!--[if !supportLists]-->3. <!--[endif]-->PropertiesHolder. PropetiesHolder is a custom annotation, that we will use to annotate fields in the PropStore, and set the properties file that field will go against.

 

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]-->

<!--[if !supportLists]-->4. <!--[endif]-->Loading Properties. Properties file need to be loaded at application startup since the application code uses the properties files. We’ll load the properties using PropsLoader class as demonstrated below. PropsLoader can then be used by a startup class (a startup servlet in webapps, or a bootstrap class in a desktop application, for e.g.).

 

Here’s what the PropsLoader does to load the properties files:

<!--[if !supportLists]-->i. <!--[endif]-->Introspect the PropStore to get declared fields.

<!--[if !supportLists]-->ii. <!--[endif]-->Loop on the fields and check if the field is annotated with PropertiesHolder.

<!--[if !supportLists]-->iii. <!--[endif]-->If it is annotated with PropertiesHolder, create a “Properties” object and load the properties file (set with the file attribute of PropertiesHolder).

<!--[if !supportLists]-->iv. <!--[endif]-->Call the appropriate setter, on the PropStore with this “Properties” object.

<!--[if !supportLists]-->v. <!--[endif]-->Please note that if there’s a XML configuration file, another reading mechanism can be provided and a Properties object be built from that.

 

Below is the code snapshot that loads the properties.

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]-->

 

 

<!--[if !supportLists]-->5. <!--[endif]-->Auto Load. Although, not an absolute essential, sometimes, the properties files need to be auto-loaded in case there’s a change while the application is running.

 

To auto load properties, the PropsWatcherTask:

<!--[if !supportLists]-->a. <!--[endif]-->Schedules itself to run every “x” minutes, and check the last modified time of the properties file to watch.

<!--[if !supportLists]-->b. <!--[endif]-->If the new modified timestamp is newer than the timestamp used to build the task, the properties file is reloaded and the local timestamp set accordingly.

 

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]-->

 

 

<!--[if !supportLists]-->6. <!--[endif]-->Testing. The following simple JUnit can be used to test the PropsLoader for both auto load and otherwise.

 

 

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]-->

 

Note the PropsLoader.load() being called from the load method of PropStoreTest. The PropsLoader.load() call will generally be made from some startup class (like a startup servlet, etc). To run the test, make sure the APP_PROPS variable is passed as a JVM parameter, or is set in the system properties.

 

The code is attached with this article. Tester.zip contains the Tester folder, which can be directly imported into Eclipse. If you wish to run this with ant, use Tester/build/build.xml. (Please change the value for APP_PROPS on line 9 in build.xml).

 

 

 

<!--[if gte vml 1]> <![endif]--><!--[if !vml]--><!--[endif]--><!--[if gte mso 9]> <![endif]-->

转载地址:http://yspob.baihongyu.com/

你可能感兴趣的文章
广域网(WAN)简介(转)
查看>>
DDN综述-1(转)
查看>>
详细定义嵌入式系统(转)
查看>>
linux入门教程(3)(转)
查看>>
动手制作自己的启动盘(转)
查看>>
在Linux中做系统引导盘(转)
查看>>
2.6内核的安装(转)
查看>>
多用户,多语言设置(转)
查看>>
断电后的系统修复(转)
查看>>
Squid优化完全手册(1)(转)
查看>>
全都是外国人写的防火墙脚本,我也来写一个,希望大家跟我一块做好(转)
查看>>
使用iptables实现数据包过滤(转)
查看>>
创建iptables NAT规则(转)
查看>>
初始化简单的IP放火墙(Script)(转)
查看>>
恢复IpTables的默认设置(Script)(转)
查看>>
用iptales实现包过虑型防火墙(一)(转)
查看>>
用iptables实现NAT(转)
查看>>
MYSQL(解决方法):Client does not support authentication(转)
查看>>
Oracle 游标使用大全(转)
查看>>
天龙八步-》打造debian-desktop-》安装声卡[五](转)
查看>>