 |
| XML配置文件的读取处理 |
|
JFML 转贴 更新：2002-07-31 10:35:27 版本: 1.0
|
|
XML配置文件的读取处理
板桥里人 jdon.com 2002/2
Java和XML是黄金组合,网上已经有很多文章介绍,XML作为电子商务中数据交换,已经有其不可替代的作用,但是在平时系统开发中,我们不一定都用到数据交换,是不是无法使用XML了?
当然不是,现在已经有一个新趋势,java程序的配置文件都开始使用XML格式,以前是使用类似windows的INI格式.(Java中也有Propertiesy这样的类专门处理这样的属性配置文件).使用XML作为Java的配置文件有很多好处,从Tomcat的安装配置文件和J2ee的配置文件中,我们已经看到XML的普遍应用,让我们也跟随流行趋势用XML武装起来.
现在关键是如何读取XML配置文件?有好几种XML解析器:主要有DOM和SAX ,这些区别网上文章介绍很多.
在apache的XML项目组中,目前有Xerces Xalan Cocoon几个开发XML相关技术的project.Tomcat本身使用的是 Sun 的 JAXP,而其XSL Taglib project中使用Xerces解析器.
好了,上面都是比较烦人的理论问题,还是赶快切入XML的配置文件的读取吧.
在我们的程序中,通常要有一些根据主机环境确定的变量.比如数据库访问用户名和密码,不同的主机可能设置不一样.只要更改XML配置文件,就可以正常运行.
<myenv>
<datasource>
<dbhost>localhost</dbhost>
<dbname>sqlname</dbname>
<dbuser>username</dbuser>
<dbpassword>password</dbpassword>
</datasource>
</myenv>
上面这个myenv.xml配置文件一般是放在tomcat的WEB-INF/classes目录下.
我们编制一个Java程序直接读取,将dbhost dbuser dbpassword提取出来供其他程序访问数据库用.
目前使用SAX比较的多,与DOM主要区别是 SAX是一行一行读取XML文件进行分析,适合比较大文件,DOM是一次性读入内存,显然不能对付大文件.这里我们使用SAX解析,由于SAX解析器不断在发展,网上有不少文章是针对老版本的.如果你使用JDK1.4 ,可以参考 使用SAX处理XML文档 一文.这里的程序是根据其改进并且经过实践调试得来的.
对上面myenv.xml读取的Java程序:
import org.xml.sax.Attributes;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.SAXException;
import java.util.Properties;
//使用DefaultHandler的好处 是 不必陈列出所有方法,
public class ConfigParser extends DefaultHandler {
////定义一个Properties 用来存放 dbhost dbuser dbpassword的值
private Properties props;
private String currentSet;
private String currentName;
private StringBuffer currentValue = new StringBuffer();
//构建器初始化props
public ConfigParser() {
this.props = new Properties();
}
public Properties getProps() {
return this.props;
}
//定义开始解析元素的方法. 这里是将<xxx>中的名称xxx提取出来.
public void startElement(String uri, String localName, String qName, Attributes attributes)
throws SAXException {
currentValue.delete(0, currentValue.length());
this.currentName =qName;
}
//这里是将<xxx></xxx>之间的值加入到currentValue
public void characters(char[] ch, int start, int length) throws SAXException {
currentValue.append(ch, start, length);
}
//在遇到</xxx>结束后,将之前的名称和值一一对应保存在props中
public void endElement(String uri, String localName, String qName) throws SAXException {
props.put(qName.toLowerCase(), currentValue.toString().trim());
}
}
上面的这个解析程序比较简单吧? 其实解析XML就是这么简单.
现在我们已经将dbhost dbuser dbpassword的值localhost sqlname username password提取了出来.但是这只是在在解析器内部,我们的程序还不能访问.需要再编制一个程序.
import java.util.Properties;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import java.net.URL;
public class ParseXML{
//定义一个Properties 用来存放 dbhost dbuser dbpassword的值
private Properties props;
//这里的props
public Properties getProps() {
return this.props;
}
public void parse(String filename) throws Exception {
//将我们的解析器对象化
ConfigParser handler = new ConfigParser();
//获取SAX工厂对象
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(false);
factory.setValidating(false);
//获取SAX解析
SAXParser parser = factory.newSAXParser();
//得到配置文件myenv.xml所在目录. tomcat中是在WEB-INF/classes
//下例中BeansConstants是用来存放xml文件中配置信息的类,可以自己代替或定义
URL confURL = BeansConstants.class.getClassLoader().getResource(filename);
try
{
//将解析器和解析对象myenv.xml联系起来,开始解析
parser.parse(confURL.toString(), handler);
//获取解析成功后的属性 以后 我们其他应用程序只要调用本程序的props就可以提取出属性名称和值了
props = handler.getProps();
}finally{
factory=null;
parser=null;
handler=null;
}
}
}
由于我们的XML文件是使用最简单的形式 ,因此解析器相对简单,但是这已经足够对付我们的配置文件了.
判断一个程序系统的先进性,我们先看看他的配置文件,如果还在使用老套的xxx=123 这样类似.ini的文件,
我们也许会微微一笑,他又落伍了.....
|
|
|
评论人：Erazor
|
发表时间: Wed Jul 31 22:23:53 CST 2002
|
[i]判断一个程序系统的先进性,我们先看看他的配置文件,如果还在使用老套的xxx=123 这样类似.ini的文件,
我们也许会微微一笑,他又落伍了.....[/i]
太武断了吧，程序先进和是否用xml做配置文件问题不大吧
|
|
|
评论人：CrazyJavar
|
发表时间: Wed Jul 31 23:14:29 CST 2002
|
to 楼上：
比较一下
是读取ini文件中的数据方便呢
还是读取xml方便：）
|
|
|
评论人：bruce
|
发表时间: Thu Aug 01 08:30:11 CST 2002
|
虽然说不使用XML配置文件并不能说明你就落伍了，但使用XML配置文件确实会有一些比使用.properties文件优越的地方。比如说，可以使用DTD对这个配置文件的有效性进行约束，而这是.properties文件所不具有的功能。
另外，XML正在成为一种数据交换的标准，现在很多基于Java的系统都把配置文件从原来的.properties文件修改为xml格式了。 ^_^ 个人观点，不用砸我。
|
|
|
评论人：kert
|
发表时间: Thu Aug 01 08:47:04 CST 2002
|
|
同意Erazor的观点。xml的配置方案只带来灵活性，并没有带来方便性。（至少我是这么认为的)。
|
|
|
评论人：Erazor
|
发表时间: Thu Aug 01 11:44:11 CST 2002
|
|
我觉得是否采用XML应该和具体的项目实际来做分析，并不是什么热门用什么
|
|
|
评论人：jc2cn
|
发表时间: Sat Aug 03 01:44:00 CST 2002
|
|
看看petstore对xml的处理
|
|
|
评论人：javamonkey
|
发表时间: Mon Aug 05 16:12:12 CST 2002
|
其实俩种观点在某些情况下都对
对于简单的配置信息，用类似.ini就够了
但是复杂的，如下例子（来自真实的一个配制文件），包含了复杂的信息
<?xml version="1.0" encoding="ISO-8859-1"?>
<treeView id="Resource Tree">
<!-- 扩展策略 -->
<mainType>100</mainType>
<startRootID>10001</startRootID>
<expand>
<if typeID ="100">
<realted typeID = "10002"/>
</if>
<if typeID = "10002">
<related typeID= "10003"/>
</if>
</expand>
<!--过滤 -->
<filter>
<entry id ='100132'>
<nameList>
<name>路由器</name>
</nameList>
<statusList>
<status name = "故障">
<value>正常</value>
<value>轻微</value>
</status>
</statusList>
<typeList>
<type id="12235"/>
</typeList>
</entry>
<entry id ='100232'>
<nameList>
<name>路由器</name>
</nameList>
<statusList>
<status name = "故障">
<value>正常</value>
<value>轻微</value>
</status>
<status name = "性能">
<value>正常</value>
<value>轻微</value>
</status>
</statusList>
<typeList>
<type id="12235"/>
</typeList>
</entry>
<!--定义多个entry的顾虑 -->
</filter>
<!-- 外观定制 -->
<status name = "fault">
<type id="1234">
<status_value value = "normal" >
<render>
<background>010011F</background>
</render>
</status_value>
<status_value value = "severity" >
<render>
<border>BevelBorder</border>
</render>
</status_value>
</type>
</status>
<status name = "performance">
<type id="1234">
<status_value value = "normal" >
<render>
<background>010011F</background>
</render>
</status_value>
<status_value value = "severity" >
<render>
<border>BevelBorder</border>
</render>
</status_value>
</type>
</status>
</treeView>
我想用.ini是不合适的。
另外，如果具有庞大的配制信息，用xml可能会导致解析慢，或者不具备关系描述，我想可采用本地数据库来包含配制信息（可惜我也没做个，这是个假设，...谁家的臭鸡蛋掉在我身上了）。
可以参考JCDatabase了解本地数据库
|
|
|
评论人：littleboys
|
发表时间: Wed Aug 07 20:44:30 CST 2002
|
|
我认为比较不错，我也要采用这个方法。
|
|
|
评论人：JFML
|
发表时间: Wed Aug 07 21:15:59 CST 2002
|
|
JDOM，还是觉得你最好
|
|
|
评论人：flyingwcy
|
发表时间: Thu Aug 08 17:25:57 CST 2002
|
请问：
//下例中BeansConstants是用来存放xml文件中配置信息的类,可以自己代替或定义
URL confURL = BeansConstants.class.getClassLoader().getResource(filename);
这个BeansConstants.java的内容应该怎么写，能不能给出个示范？？因为我编译到这里出错了
|
|
|
评论人：imcpator
|
发表时间: Wed Aug 14 16:24:06 CST 2002
|
|
我觉得读配置文件，没有必要用sax方法，用jdom就行了，因为那样很方便，至于效率，配置文件都是读一次，我们写的好多服务器端都是用xml做配置的，用数据来驱动程序，挺方便，而且清晰。
|
|
|
评论人：zzpapple
|
发表时间: Thu Feb 06 16:21:57 CST 2003
|
|
不知道大家用过apache的commons-digester包没有，它是从struts里面分离出来的，在解析配置文件方面很有独到之处，可以通过动态的定制规则来解析配置文件，将基于事件的思想更进了一步。
|
|
|
评论人：孤魂一笑
|
发表时间: Sat Feb 08 10:15:33 CST 2003
|
我个人也认为读xml配置文件使用jdom就可以了。没有必要去使用SAX.
通常配置文件配置文件不会很大，一次读入也没有什么不妥。而且配置文件
很多时候都作为全局变量来保存，一直存放在内存里面。开始解析的那点效率
问题可以不计。
至于使用properties文件还是xml文件做配置看需要啊，如果properties就可以完全
解决为使用要使用xml
|
|
|
评论人：jacobmee
|
发表时间: Mon Feb 10 10:11:30 CST 2003
|
|
大家有兴趣可以看看jakarta的common.configation，提供的配置源码
|
|
|
评论人：mem_fox
|
发表时间: Mon Feb 10 17:47:06 CST 2003
|
|
有时那XML文件作配置文件读取没有properties文件方便！！我一般用XML作数据交换文件，用带有一样的Element说明，这样用XPath来一次也不算浪费：）
|
|
|
评论人：SteveGY
|
发表时间: Tue Feb 18 11:28:21 CST 2003
|
我觉得对待技术问题应该有一种务实的态度，最好不要有什么“我偏爱于……”之类的感情色彩。至于“潮流”，我想说，我们不是时装设计师，紧跟“潮流”不应是我们对待技术问题的态度。我想我们之所以使用某项技术，是因为它能在一个合理的“开销”内，为我们完成工作。
其实用膝盖想一下，就应该知道properties只提供了简单的（换一种说法就是“高效的”）key/value存取方法，但这已经解决了40%（或者是100%）的关于“应用程序配置”问题。还剩下些什么问题？比如配置文件的文档，例如，我们要求配置文件应该是“自我描述”的，当系统管理人员在用NotePad或vi打开后就可以非常清楚的明白每个配置项的含义和作用，以及修改的后果等等。显然properties文件对这样的要求并不很适合。例如，我们还要求配置项目可能是key/value1,value2,...,valueN这样的形式，或者是key/sub_key1/sub_key2/value这种形式，我们也可以用properties来实现，但这样的配置文件会让大多数系统管理人员头大如斗。
改成XML形式可以解决上面的问题，但对于任何复杂的配置，手工修改配置文件都是一件令人头痛的事情，也许我们还应该提供一个修改配置文件的图形化用户界面（这有时违反了OpenSource世界里许多人的意愿），让你的系统看起来更象个成熟的商业级应用程序。那好，想象一下，完成这样一个配置管理器需要做多少工作呢？是不是觉得双休日有事可做了;-)
幸运的是，我们已经有了一些OpenSource的xml配置文件管理类库，这使我们的工作量减少了一半。
所以这篇文章可以算作是“时装设计师的SA(e)X初级入门使用实践”，也许这样的标题比较恰当;-^)
|
|
|
评论人：villion
|
发表时间: Wed Oct 15 16:25:20 CST 2003
|
收益。
首先声明，我是菜鸟。（说错话了，别扔鸡蛋）
你们这个老手老咬别人一句话不放，看文章是看什么重要啊？？不解。
|
|
|
|
|
|
9 
1
