Tomcat Tips

1. tomcat中如何禁止列目录下的文件
在{tomcat_home}/conf/web.xml中，把listings参数设置成false即可，如下：
<servlet> ... <init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param> ... </servlet> from tomcat中的几点配置说明
2. crossContext="true" 时两个context就可共享session了
3. reloadable="true" 时context下修改进会自动重载,即不必重启修改就会生效

Ant Tips - Ant使用注意事项

1. java task - 执行java代码
其参数fork="true" 就会在别外的VM中执行java代码,此时java类是个多线程程序不会结果;否则ant会继承往下执行task,ant退出时java类启动的线程也会被中止 spawn="true" - ant过程结束后，新起的java进程不会被中止
2. 产成ant dtd的bulid.xml

<?xml version="1.0"?>
<project default="dtd">
  <target name="dtd">
    <antstructure output="ant.dtd"/>
  </target>
</project>

from Where is Ant's DTD? (Through the blogging-glass)

Struts - Validator 集成注意事项

• 在struts主配置文件struts-config.xml中加入Validator plug-in
<plug-in classname="org.apache.struts.validator.ValidatorPlugIn"><set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"></plug-in>
• 改变form对象所继承的父类为ValidatorForm或其子类
Once you have configured the Validator Plug-In, so that it can load your Validator Resources you just have to extend org.apache.struts.validator.action.ValidatorForm instead of org.apache.struts.action.ActionForm
• validator的前台javascript验证默认采用commons-validator中的定义
Starting in Struts 1.2.0 the default javascript definitions have been consolidated to commons-validator. The default can be overridden by supplying a element with a CDATA section, just as in struts 1.1.
如 <validator name="mask" classname="org.apache.struts.validator.FieldChecks" method="validateMask" methodParams="java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionMessages, javax.servlet.http.HttpServletRequest" depends="" msg="errors.invalid"> <javascript><![CDATA[ function validateMask(form) { return true } ]]> </javascript> </validator>
• field定义中的msg,arg子元素中的属性name指的是对应验证器名称:mask,...

Struts 1.2 offers cool new features

Now is a great time to be developing with Struts. With the recent release of version 1.2.4, now more than ever Struts provides a solid platform for developing complex Java web applications. While working on the upcoming Jakarta Struts Cookbook, I have come to appreciate a number of the innovative new features in Struts 1.2. The move from Struts 1.0 to Struts 1.1 was a major shift. Struts 1.2 solidifies the Struts 1.1 platform and adds a number of additional features designed at empowering the Struts developer. Here are a couple of the features that I especially like in Struts 1.2. Valid When The Struts Validator introduced the ability to perform some types cross-field using the requiredif pluggable Validator. If you have ever used requiredif, you know what a pain it is. It is extremely verbose to code up the relationships in XML and, even then, you're still limited in how you compare different fields to each other; basically indicating that one field must be supplied if another field is empty (or not). The validwhen validator makes these rules easier to code – you use a simple expression language – and even easier to code up specific validations (e.g. checking if two fields have the same value) that were not even possible with requiredif. One knock against the validwhen rule (which also applies to requiredif) is that it does not support client-side (i.e. JavaScript-based) validation. Personally, I prefer server-side validations for the control offered, so this is not a major issue. Wildcard Mappings Wildcard mappings allow you to define a generic set of mappings that can be used across all actions that follow a common workflow pattern and naming convention. On numerous occasions people have complained on the struts-user list that they have to write so many repetitive action mappings; that all essentially implement the same workflow. A typical workflow might be: 1. prepare the form for viewing 2. display the form on a JSP 3. submit the form to an action that saves the data 4. display a success page Good developers will use common naming conventions that across-the-board so it's easy for other developers to know what purpose the actions serve. Wildcard mappings allow you to codify the common pattern and naming convention. For example, here's a set of action mappings that use wildcards: >forward name="success" path="/edit_{1}.jsp"/< Now you when I have an action path like http://com.oreilly.struts/myapp/EditUser.do, the Struts RequestProcessor matches the wildcarded mapping to the URL; the {1} represents the text that matches the wildcard (*) (similar to a capture group in a regular expression). So you end up with the following "virtual" mapping: >forward name="success" path="/edit_User.jsp"/< This is a powerful feature; promoting both reuse as well as naming standards across your application." 原文

Comparison of Commons Configuration With JFig and JConfig

以下内容是从mail-archives.eu.apache.org所找到的 [configuration] Comparison of Commons Configuration With JFig and JConfig "I have recently been looking at config tools and looked at Commons Configuration, JFig and JConfig. While JFig and JConfig appear to be quite similar, the Commons Configuration project seems a lot more flexible. Specifically I am keen on the ability to have my configuration details in different stores (property files, XML files, database or JNDI) at different stages of the development lifecycle i.e. I may start of with the config in a properties file for initial development but when moving across to testing and production I might start to use a database or LDAP server. This is a feature that neither of the other two packages has and is excellent. One feature that JFig has and Commons Configuration and JConfig appear to be missing (I am no expert in any of these packages so please correct me if I am wrong) is the ability to dynamically specify the configuration to use at runtime for example by setting a system parameter i.e. by using -Dconfig=test . This would allow different config files to be loaded dependent on the environment they are in i.e. development, test, uat or production. I have an updated version of the ConfigurationFactory class that has this feature if it is of interest to the project. The updated version allows the configuration to be retrieved using the code: Configuration config = ConfigurationFactory.getDynamicConfiguration(); I created a static method to minimise the number of lines of code to get the configuration and make it as simplistic as possible. This is similar to getting a Logger using Commons Logging. Then when I run my application or server I can optionally specify the "config" system property. If no "config" system property is set then the default config.xml file is loaded from the root of the classpath. Example config.xml If the "config" property is set e.g. -Dconfig=test, then the test-config.xml file is loaded from the root of the classpath. Example test-config.xml Finally if the "config" property is set e.g. -Dconfig=production, then the production-config.xml file is loaded from the root of the classpath. Example production-config.xml As I said, I am no expert in any of these packages so I may have missed if this sort of functionality is already in Commons Configuration but if is not and it is of interest to the project let me know and I will submit the code with tests. Keith Lyall." 原文 reference: jfig jconfig Commons-configuration 我个人认为在项目应用Commons-configuration

commons-configuration的使用

各独立相关的配置放在一个单独配置文件中,整个应用由一个统一的配置装配文件global-config.xml,然后统一个Configuration类实的例来获取各种配置参数 the ConfigurationFactory class:

ConfigurationFactory factory = new ConfigurationFactory("config.xml");
Configuration config = factory.getConfiguration();

The config.xml file used in the example above is a configuration descriptor,
it specifies the Configuration objects to load. 

Here is an example of descriptor:     

<?xml version="1.0" encoding="ISO-8859-1" ?>

<configuration>
<system/>
<properties fileName="application.properties"/>
</configuration>

What this says is that we are loading up all system properties,

as well as the propertiesfile application.properties.

The order of precedence is first to last.So in the above example,

if a property is not found in the system properties, it'll be searched in the properties file. This allows you to set up default values in a properties file, and override them with the system properties.

config.xml中格模块文件的配置顺序很重要,在前一配置中已找到配置参数值就不会再在后一文件中查找了

reference