BlogJava-呆呆向前冲的blog-文章分类-工作：Java技术

[struts1.1] 一些开发经验

呆呆向前冲的blog — Fri, 02 Sep 2005 02:48:00 GMT

1 DispatchAction
一个DispatchAction可以是针对一个实体的一组crud操作。这样可以保证每个操作对应相同的ActionForm。还有相同的input

呆呆向前冲的blog 2005-09-02 10:48 发表评论

[struts1.1] 多语言配置

呆呆向前冲的blog — Sat, 27 Aug 2005 19:34:00 GMT

步骤
1 资源文件
     添加资源文件：JB里默认的资源文件名称为ApplicationResources.properties。需要添加和语言地区对应的资源文件。如：ApplicationResources_zh_CN.properties、ApplicationResources_en_US.properties
      注意：命名一定要注意后缀的正确。否则struts不能自动加载

      转换编码：将资源文件内容转换为unicode编码。以中文资源文件转换为例，命令如下：

native2ascii -encoding GBK src/zh_cn.properties src/ApplicationResources_zh_CN.properties

注：zh_cn.properties文件是暂存原始内容的文件

配置资源文件到struts-config.xml中：在配置文件中加入如下资源文件引用

<message-resources parameter="ApplicationResources" />

2 设置JSP编码为UTF-8

3 切换当前Locale
      Struts是根据Session中存储的关键字为org.apache.struts.action.LOCALE的Locale对象判断当前的Locale，
并自动加载相应的资源文件。
      即如果当前locale是zh CN,那么会自动加载 ApplicationResources_zh_CN.properties。所以如果要显示多语言版本，必须切换当前locale。例子如下：
      切换Locale的Action代码：

public class SetLocaleAction extends Action {
  public ActionForward execute(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest req, HttpServletResponse httpServletResponse) {
    String langFlag = req.getParameter("lang");
    String[] lang = langFlag.split("_");
    Locale locale = new Locale(lang[0],lang[1]);
    HttpSession session = req.getSession(true);
    session.setAttribute("org.apache.struts.action.LOCALE",locale);
    return actionMapping.findForward("forward");
  }
}

页面文件中调用该Action的链接：

<html:link action="setLocale.do?lang=zh_CN">chinesehtml:link>
<html:link action="setLocale.do?lang=en_US">Americahtml:link>

不过对于Java中的编码问题，理解的还不透彻。比如中文字符在页面之间的传递问题。如何保证能正确的接收各种语言的输入。

呆呆向前冲的blog 2005-08-28 03:34 发表评论

[Struts1.1]配置Validator

呆呆向前冲的blog — Sat, 27 Aug 2005 14:37:00 GMT

步骤：

1 环境配置：首先要为struts加入Validator支持
lib包：加入validator所需的jar包
配置文件：struts-config.xml里加入

  <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
    <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml" />
  plug-in>

      这里所需的validator-rules.xml和validation.xml也需要放到/WEB-INF/下

2 配置actionForm
      2.1 修改Form基类：将actionForm继承的基类改为ValidatorForm
      2.2 配置struts-config.xml文件：把要验证的form的validator属性设为true

xml version="1.0" encoding="UTF-8"?>
DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
<struts-config>
  <form-beans>
    <form-bean name="userForm" type="com.satesoft.test.UserForm" />
  form-beans>
  <action-mappings>
    <action input="/index.jsp" name="userForm" path="/show" scope="request" type="com.satesoft.test.ShowAction" validate="true">
      <forward name="forward" path="/show.jsp" />
    action>
  action-mappings>
  <message-resources parameter="ApplicationResources" />
  <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
    <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml" />
  plug-in>
struts-config>

注意：一定要配置对应的Action里的input属性，否则struts找不到要返回的路径

2.3 配置validator.xml文件：在validation.xml里加入对要验证的actionform的定义

xml version="1.0" encoding="UTF-8"?>
DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN" "http://jakarta.apache.org/commons/dtds/validator_1_0.dtd">
<form-validation>
  <formset>
    <form name="userForm">
      <field property="name" depends="required">
        <arg0 key="user.name.required"/>
      field>
    form>
  formset>
form-validation>

这里同时要配置的还有消息资源。在资源文件中加入上述配置文件中所需的消息

errors.header=<H3><font color="blue">errorsfont><br>
errors.footer=<p>p>
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {1} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid email address
user.name.required=user name

2.4 配置作为input的jsp页面：

<%@ page contentType="text/html; charset=GBK" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<html>
<head>
<title>
index
title>
head>
<body bgcolor="#ffffff">
<html:form action="show.do" method="post">
  <html:text property="name"/>
  <html:submit title="确定"/>
  <html:cancel title="取消">
  html:cancel>
html:form>
<html:errors/>

body>
html>

如果需要加入javascript支持，则：

<%@ page contentType="text/html; charset=GBK" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<html>
<head>
<title>
index
title>
head>
<body bgcolor="#ffffff">
<html:form action="show.do" method="post" onsubmit="return validateUserForm(this);">
  <html:text property="name"/>
  <html:submit title="确定"/>
  <html:cancel title="取消">
  html:cancel>
html:form>
<html:javascript formName="userForm"/>
body>
html>

注意：onsubmit里的validatorUserForm要和下面的formName里的名字一致，只不过首字母大写

最后要注意：这只是客户端自动生成Javascript的验证。还要在服务器端进行验证。

呆呆向前冲的blog 2005-08-27 22:37 发表评论

我是老土:第一次使用JNDI从WebLogic获取数据库连接

呆呆向前冲的blog — Wed, 17 Aug 2005 15:53:00 GMT

package com.satesoft.testjndi;

import java.sql.*;
import java.util.*;
import javax.naming.*;
import javax.sql.*;

public class TestJNDI {
  public TestJNDI() {
  }

  public static void main(String[] args) {
    TestJNDI testJNDI1 = new TestJNDI();
    testJNDI1.connect();
  }

  public void connect() {
    Context ctx = null;
    Hashtable ht = new Hashtable();
    ht.put(Context.PROVIDER_URL, "t3://localhost:7001");
    ht.put(Context.INITIAL_CONTEXT_FACTORY,
           "weblogic.jndi.WLInitialContextFactory");
//    ht.put(Context.SECURITY_PRINCIPAL,"wwx");
//    ht.put(Context.SECURITY_CREDENTIALS,"11111111");
    try {
      ctx = new InitialContext(ht);
      System.out.println("ok");
      DataSource ds = (DataSource) ctx.lookup("sapp_source");
      Connection conn = ds.getConnection();
      PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM S_ENTITY");
      ResultSet rs = pstmt.executeQuery();
      while (rs.next()){
        System.out.println(rs.getString(2));
      }
      pstmt.close();
      conn.close();
    }
    catch (SQLException ex) {
    }
    catch (NamingException e) {
      e.printStackTrace();
    }
    finally {
      try {
        ctx.close();
      }
      catch (Exception e) {
      }
    }
  }
}

呆呆向前冲的blog 2005-08-17 23:53 发表评论

加快JBuilder里编辑XML文件的速度

呆呆向前冲的blog — Thu, 11 Aug 2005 09:41:00 GMT

加快jbuilder编辑xml的速度

我们知道,在jbuilder中,编辑xml文件的话, 如果在头部加了dtd, JB会自动去网上下载这个DTD,来验证XML文件, 这功能当然是非
常好的, 但是,给我们造成了速度慢的困扰, 特别是打开xml和保存,修改的时候.
其实在jb中,是可以改变这个速度的. 采用的是地址映射的方法, 把HTTP地址,映射到本地的目录上来.
我是在hibernate的xml文件中实践的
先用flashget 下载 http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd 这个DTD文件. 把他放到硬盘上的一
个目录里,然后在JB里,选择TOOLS, preferences, 然后选xml 下面的 System ID Catalog, 点ADD,加入一个映射
在输入框是里填入http://hibernate.sourceforge.net/ 这代表要把这段网址映射成硬盘上的某个目录, 然后下面选directy, 选择放上面dtd的目录.
当然也可以映射文件. 方法同上,只是remap成file就OK了.
以上方法，是在jbuilderX中通过的

呆呆向前冲的blog 2005-08-11 17:41 发表评论

Struts中文乱码问题解决方案

呆呆向前冲的blog — Wed, 10 Aug 2005 15:06:00 GMT

三种解决方式如下

1、可以覆盖父类ActionServelt 的process 方法（针对服务器）
在其中加入如下代码：
request.setCharacterEncoding ("GB2312");//字符集内码转换
super.process (request, response);//ActionServlet 的处理

2、针对Validate方法
native2ascii -encoding GBK ApplicationResources_xx.properties ApplicationResources_zh.properties

3、提交的中文字符在服务器端(JBOSS)乱码
解决办法：增加一个filter，里面将request中的中文转换为GBK
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding("GBK");
chain.doFilter(request,response);
}

呆呆向前冲的blog 2005-08-10 23:06 发表评论

在JBuilderX中配置Tomcat5(改编自Borland网站的一篇文章)

呆呆向前冲的blog — Wed, 10 Aug 2005 14:50:00 GMT

1 配置步骤（来自原文）

This is not a supported or tested configuration. This is just a workaround to get the server running in JBuilder X. JSP debugging will not work with this solution.

Steps:

1. Tools | Configure Servers, select the Tomcat 4.1 server and click the Copy button. Change the name to Tomcat 5.0. Next, set the home directory to the root of the Tomcat 5.0 installation, and remove the entry in the Class list and add /bin/bootstrap.jar.

2. File | New Project. Set server to Tomcat 5.0 and create a web module. This will trigger generation of the Tomcat 5.0 Servlet library.

3. Tools | Configure Libraries. Edit the Tomcat 5.0 Servlet library and add the following jars :

/common/lib/jsp-api.jar
/common/lib/servlet-api.jar
/bin/commons-logging-api.jar
/common/lib/commons-el.jar

Make a backup of this library (in your user home directory) as it gets regenerated when you create a new web module/JSP/servlet. Please make sure that you replace the library when you use any of the web gallery wizards.

4. Set server for the project to Tomcat 5.0.

5. If a "Tomcat" folder is not present under the project's root directory, create one (e.g. ../jbproject/untitled1/Tomcat). Next, create a directory named "conf" under this directory (e.g. ../jbproject/untitled1/Tomcat/conf). and create an XML file named server8080.xml. Sample server8080.xml is below. Please modify the appBase, docBase, and workDir, etc. according to your web module properties:

xml version="1.0" encoding="UTF-8"?>
<Server debug="0" port="8081" shutdown="SHUTDOWN">
  <Service name="Tomcat-Standalone">
    <Connector acceptCount="10" className="org.apache.coyote.tomcat5.CoyoteConnector" connectionTimeout="60000" debug="0" maxProcessors="75" minProcessors="5" port="8080"/>
    <Engine debug="0" defaultHost="localhost" name="Standalone">
      <Host appBase="{项目根目录}\Tomcat\webapps" debug="0" name="localhost" unpackWARs="true">
        <Context debug="0" docBase="{项目根目录}\{web文件目录名称}" path="/sapp" reloadable="true" workDir="{项目根目录}\Tomcat\work\{web文件目录名称}"/>
      Host>
    Engine>
  Service>
Server>

6. Start the server in JBuilder. This should use the modified server8080.xml

You should be able to compile JSPs using this workaround but not debug. You should be able to debug any java code. You will see a number of exceptions for the admin, manager, balancer services which do not get started when you normally run the server in JBuilder. Please ignore these exceptions. The server should function normally without these services.

2 配置过程中遇到的一些问题及解决办法
2.1 出现XML解析异常
解决方法：为项目引用加上JDom Library引用
2.2 Servlet引用Library引用有问题
解决方法：仔细检查上述步骤三的是否为Tomcat 5 Servlet配置成功相应的jar。
2.3 一定要把上述步骤5中的配置文件设置正确，否则出现严重错误。

呆呆向前冲的blog 2005-08-10 22:50 发表评论

Ant的Build.xml示例

呆呆向前冲的blog — Mon, 08 Aug 2005 19:55:00 GMT

xml version="1.0"?>

<project name="jcatalog" default="build.war" basedir=".">

  <property name="project.name"     value="catalog" />
  <property name="build.dir"       value="${basedir}/build" />
  <property name="src.dir"         value="${basedir}/src" />
  <property name="src.java.dir"     value="${src.dir}" />
  <property name="docs.dir"         value="${basedir}/docs" />
  <property name="docs.api.dir"     value="${docs.dir}/api" />
  <property name="web.dir"         value="${basedir}/web" />
  <property name="lib.dir"        value="${basedir}/lib" />
  <property name="dist.dir"         value="${basedir}/dist" />

  <path id="classpath">
      <fileset dir="${lib.dir}">
        <include name="**/*.jar"/>
      fileset>
  path>

  <target name="clean" >
    <delete dir="${build.dir}" />
  target>

  <target name="prepare" depends="clean"
        description="Create build directories.">
    <mkdir dir="${build.dir}/${project.name}" />
    <mkdir dir="${build.dir}/${project.name}/WEB-INF" />
    <mkdir dir="${build.dir}/${project.name}/WEB-INF/classes" />
    <mkdir dir="${build.dir}/${project.name}/WEB-INF/lib" />
  target>

  <target name="deploy.copyJars">
      <copy todir="${build.dir}/${project.name}/WEB-INF/lib">
       <fileset dir="lib">
        <include name="**/*.jar"/>
        <include name="**/*.dtd"/>
      fileset>
    copy>
  target>


  <target name="build" depends="prepare,deploy.copyJars"
     description="Compile Java files and copy static files." >
    <javac srcdir="${src.java.dir}" destdir="${build.dir}/${project.name}/WEB-INF/classes">
        <include name="**/*.java" />
         <classpath refid="classpath"/>
    javac>

    <copy todir="${build.dir}/${project.name}/WEB-INF">
        <fileset dir="${web.dir}/WEB-INF">
        <include name="*.xml" />
        <include name="*.tld" />
      fileset>
    copy>

    <copy todir="${build.dir}/${project.name}/">
      <fileset dir="${web.dir}">
        <include name="*.html" />
        <include name="*.gif" />
        <include name="*.jpg" />
        <include name="*.jsp" />
        <include name="*.xml" />
        <include name="*.css" />
      fileset>
    copy>

     <copy todir="${build.dir}/${project.name}/images">
      <fileset dir="${web.dir}/images">
        <include name="**/*.gif" />
        <include name="**/*.jpg" />
      fileset>
    copy>

    <copy todir="${build.dir}/${project.name}/WEB-INF/classes">
        <fileset dir="${src.java.dir}">
           <include name="**/*.properties" />
           <include name="**/*.xml" />
           <exclude name="**/*.java" />
        fileset>
      copy>
  target>

  <target name="build.war" depends="build">
    <delete dir="${dist.dir}" />
    <mkdir dir="${dist.dir}" />

    <jar destfile="${dist.dir}/${project.name}.war" basedir="${build.dir}/${project.name}"/>
    <delete dir="${build.dir}" />
  target>
project>

呆呆向前冲的blog 2005-08-09 03:55 发表评论

JBuiler X下Hiberante 2.1.7配置

呆呆向前冲的blog — Mon, 08 Aug 2005 05:57:00 GMT

发送的发

呆呆向前冲的blog 2005-08-08 13:57 发表评论

JBuilder X下Tomcat 5 服务器配置

呆呆向前冲的blog — Mon, 08 Aug 2005 05:51:00 GMT

稍等

呆呆向前冲的blog 2005-08-08 13:51 发表评论

Eclipse运行命令行参数大全

呆呆向前冲的blog — Sat, 06 Aug 2005 04:37:00 GMT

包括英文版本和中文版本两种的说明,特别需要值得一提的是那个-nl参数,可以指定程序启动时所使用的语言.例如:
eclipse -nl en_US
将启动英文语言,这个特性在安装了国际化语言包以后特别有用,可以方便的切换各个语言的版本.注意IBMWSADv5.1也支持这个功能.

运行Eclipse
将Eclipse驱动程序安装（解压缩）到某个目录（例如，c:\eclipse）中之后，通过运行顶级安装目录中的Eclipse可执行文件来启动"工作台"。在Windows系统上，该可执行文件称为eclipse.exe，而在Linux系统上称为eclipse。注意：下列讨论描述Windows系统上的设置。Linux上的设置是相似的。

如果您没有另行指定，则平台将缺省工作区目录创建为可执行文件的兄弟目录（例如c:\eclipse\workspace）。此工作区目录用作项目的缺省内容区，还用于保存任何必需的元数据。要进行共享安装或多工作区安装，应明确指出工作区的位置而不是使用缺省值。有两种控制工作区位置的方法：使用当前工作目录或使用-data命令行自变量。

将工作区位置设置为在当前工作目录内
在此方案中，工作区位置将是当前工作目录中称为workspace的目录。

实现此目的最容易的方法可能是使用下列步骤来创建快捷方式：

导航到Windows资源管理器中的eclipse.exe并使用右键拖动来创建eclipse.exe的快捷方式。
编辑快捷方式的属性，以使启动位置：字段标识工作区位置的父目录（例如，c:\users\robert）。
关闭属性对话框并双击快捷方式（如果提供的目录为c:\users\robert，则工作区位置将为c:\users\robert\workspace）。
当然，您也可以使用命令提示符（通过将目录切换为工作区父目录然后运行eclipse.exe）来获得同样的效果。

使用-data设置工作区的特定位置
要使用-data命令行自变量，只要将-datayour_workspace_location（例如，-datac:\users\robert\myworkspace）添加至快捷方式属性中的目标字段或显式地将它包括在命令行上。

使用-vm设置javaVM
建议显式指定在运行Eclipse时要使用哪个JavaVM。使用-vm命令行自变量（例如，-vmc:\jre\bin\javaw.exe）可以实现此目的。如果不使用-vm，则Eclipse将使用在O/S路径上找到的一个JavaVM。当安装其它产品时，它们可更改您的路径，导致在下一次启动Eclipse时使用另一JavaVM。

运行Eclipse中的高级主题
Eclipse可执行文件及平台本身提供了人们感兴趣的开发或调试Eclipse各部件的许多执行选项。运行Eclipse可执行文件的一般格式是：

eclipse[platformoptions][-vmargs[JavaVMarguments]]
Eclipse启动参数命令描述原因
-archarchitecture
定义Eclipse平台在其上运行的处理器体系结构。Eclipse平台通常使用Javaos.arch属性的常用值来计算最佳设置。如果在此处指定该项，则这是Eclipse平台使用的值。此处指定的值可作为BootLoader.getOSArch()用于插件。示例值有："x86"、"sparc"、"PA-RISC"和"ppc"。2.0
-applicationapplicationId
要运行的应用程序。应用程序由向org.eclipse.core.runtime.applications扩展点提供扩展的插件来声明。通常不需要此自变量。如果指定了此项，则该值会覆盖配置提供的值。如果不指定此项，则会运行"Eclipse工作台"。1.0
-bootbootJarURL
（建议不使用；用-configuration代替；支持1.0兼容）。Eclipse平台的引导插件代码（boot.jar）的位置，表示为URL。如果指定此项，则会用它来为装入Eclipse平台引导程序类装入器的类装入器设置类路径。仅当更改startup.jar和boot.jar的相对位置时才需要它。注意，不允许使用相对URL。*1.0
-classloaderproperties[file]
如果指定的话，则使用给定位置处的类装入器属性文件来激活平台类类装入器增强。文件自变量可以是文件路径或URL。注意，不允许使用相对URL。单击此处以获得更多详细信息。2.0.2
-configurationconfigurationFileURL
Eclipse平台配置文件的位置，表示为URL。配置文件确定Eclipse平台、可用插件集和主要功能部件的位置。注意，不允许使用相对URL。当安装或更新Eclipse平台时配置文件被写至此位置。2.0
-consolelog
将Eclipse平台的错误日志镜像到用来运行Eclipse的控制台。与-debug组合时很方便使用。1.0
-dataworkspacePath
要运行Eclipse平台的工作区的路径。工作区位置也是项目的缺省位置。相对于从中启动eclipse的目录来解释相对路径。1.0
-debug[optionsFile]
将平台置于调试方式，并从给定位置处的文件装入调试选项（如果指定的话）。此文件指示哪些调试点可用于插件以及是否已启用它们。如果未给出文件位置，则平台在启动eclipse的目录中查找称为".options"的文件。URL和文件系统路径都可作为文件位置。1.0
-dev[classpathEntries]
将平台置于开发方式。将可选类路径条目（用逗号分隔的列表）添加至每个插件的运行时类路径。例如，当工作区包含要开发的插件时，指定-devbin会为每个插件项目的名为bin的目录添加类路径条目，允许在其中存储最新生成的类文件。除去了冗余或不存在的类路径条目。1.0
-endsplashparams
用于在Eclipse平台启动并运行时关闭闪屏的内部选项。此选项在闪屏处理链中不同的位置有不同的语法和语义。2.0
-featurefeatureId
主要功能部件的标识。主要功能部件为Eclipse的已启动实例提供了产品个性，并确定使用的产品定制信息。2.0
-keyringkeyringFilePath
磁盘上授权数据库（或"密钥环"文件）的位置。此自变量必须与-password选项配合使用。相对于从中启动eclipse的目录来解释相对路径。1.0
-nllocale
定义Eclipse平台在其上运行的语言环境的名称。Eclipse平台通常自动计算最佳设置。如果在此处指定该项，则这是Eclipse平台使用的值。此处指定的值可作为BootLoader.getNL()用于插件。示例值有："en_US"和"fr_FR_EURO"。2.0
-nolazyregistrycacheloading
取消激活装入优化的平台插件注册表高速缓存。缺省情况下，仅当需要时才从注册表高速缓存（可用时）中装入扩展的配置元素，以减少内存占用。此选项将在启动时强制完全装入注册表高速缓存。2.1
-noregistrycache
绕过读写内部插件注册表高速缓存文件。2.0
-nosplash
运行平台而不显示闪屏。1.0
-osoperatingSystem
定义Eclipse平台在其上运行的操作系统。Eclipse平台通常使用Javaos.name属性的常用值来计算最佳设置。如果在此处指定该项，则这是Eclipse平台使用的值。此处指定的值可作为BootLoader.getOS()用于插件，并用于解析插件清单文件中提及的路径中$os$变量的出现。示例值有："win32"、"linux"、"hpux"、"solaris"和"aix"。1.0
-passwordpassword
授权数据库的密码。与-keyring选项配合使用。1.0
-perspectiveperspectiveId
启动时要在活动工作台窗口中打开的透视图。如果没有指定该参数，则将打开关闭时活动的透视图。1.0
-plugincustomizationpropertiesFile
包含插件首选项缺省设置的属性文件的位置。这些缺省设置覆盖在主要功能部件中指定的缺省设置。相对于从中启动eclipse的目录来解释相对路径。2.0
-pluginspluginsFileURL
（建议不使用；用-configuration代替；支持1.0兼容）。指定Eclipse平台查找插件的文件的位置，表示为URL。该文件为属性文件格式，其中键是任意用户定义名称，值是指向plugin.xml文件的显式路径或指向包含插件的目录的路径的用逗号分隔的列表。注意，不允许使用相对URL。如果指定此项，则此选项会导致创建适当的临时配置。*1.0
-refresh
启动时执行工作区的全局刷新的选项。这将使从上次平台运行以来在文件系统中所做的任何更改一致。1.0
-showlocation
用于在窗口标题栏中显示工作区的位置的选项。在发行版2.0中，此选项仅与-data命令行自变量一起使用。2.0
-showsplashparams
用于显示闪屏（由可执行的Eclipse平台启动器执行）的内部选项。此选项在闪屏处理链中不同的位置有不同的语法和语义。2.0
-vmvmPath
要用来运行Eclipse平台的"Java运行时环境"（JRE）的位置。如果不指定此项，则JRE位于jre（它是Eclipse可执行文件的兄弟目录）。相对于从中启动eclipse的目录来解释相对路径。1.0
-wswindowSystem
定义Eclipse平台在其上运行的Windows系统。Eclipse平台通常使用Javaos.name属性的常用值来计算最佳设置。如果在此处指定该项，则这是Eclipse平台使用的值。此处指定的值可作为BootLoader.getWS()用于插件、用于配置SWT以及用于解析插件清单文件中提及的路径中$ws$变量的出现。示例值有："win32"、"motif"和"gtk"。1.0

将-vmargs条目后面的所有自变量（但不包括-vmargs）作为虚拟机自变量（即，在要运行的类的前面）直接传递到所指示的JavaVM。注意：如果Eclipse启动在Javavm自变量（-vmargs）之后提供的自变量（例如，-data），则Eclipse将不会启动并且您将接收到"JVM已终止。出口代码为1"的错误。

在不同的VM上运行
在J9上运行Eclipse
当在J9版本1.5上运行Eclipse时，建议使用以下VM选项：

eclipse.exe[eclipsearguments]-vmpath_to_j9w.exe-vmargs-ms:32-mm:2048-mo:32768-moi:32768-mca:32-mco:128-mx:2000000
当在J9版本2.0上运行Eclipse时，J9W选择的缺省自变量应为合适的选项。但是，要覆盖Eclipse可执行文件以内部方式自动设置的参数，必须指定-vmargs不带任何参数，如下所示：

eclipse.exe[eclipsearguments]-vmpath_to_j9w.exe-vmargs
有关进一步信息，参考J9VM文档和帮助。

在IBMDeveloperKit,Java(TM)TechnologyEditionVM上运行Eclipse
IBMDeveloperKit,Java(TM)TechnologyEdition1.3Linux的缺省VM设置适合进行初期研究工作，但在进行大型开发时是不够的。对于大型开发，应修改VM自变量以使有更多的堆可用。例如，下列设置将允许Java堆增大为256MB：

呆呆向前冲的blog 2005-08-06 12:37 发表评论

《jakarta struts编程》阅读笔记

呆呆向前冲的blog — Wed, 03 Aug 2005 12:14:00 GMT

第五章 Struts控制器组件

实用工具类
1.RequestUtils
2.ResponseUtils
3.BeanUtils
4.Common Collection包

第六章 Struts模型组件

一.模型种类
      模型:标明真实世界的逻辑表达,也表明供程序所使用的类和接口的物理组成.
      模型开发过程:彻底分析问题域,用例分析,下一步就是开发概念模型
1.概念模型
      (1) 概念模型从系统中的一套用例中开发出来
      (2) 建立这个模型的[目的]:帮助识别实体并更好的了解问题域,这些实体在设计阶段极可能成为类
      (3) [价值]:表示出问题域所使用的实体
2.设计模型
      (1) 内容:通常包括类图表,交互图表

二.业务对象
      业务对象就是简单的真实世界的软件抽象.
      1.业务对象的必要条件
            · 业务对象由状态和行为组成.
            · 表达了来自业务域的一个人,地点,事物或概念
            · 可以重用
    2.业务对象的种类
       · 实体业务对象
            通常是从业务域中的业务名词直接提取出来的.如客户,订单,物品.
            可以映射到实体bean或包含业务应用程序的状态和行为的普通JavaBean
      · 过程业务对象
            表达应用程序中的业务处理过程或者工作流程任务.
            通常依赖于实体业务对象,是业务的动词
            可以映射到会话Bean,消息驱动bean,或者包含特定行为作为应用程序管理者或者控制者的Javabean
       · 事件业务对象

呆呆向前冲的blog 2005-08-03 20:14 发表评论

Log4j入门(讲的真不错，把重要内容基本讲到了，详细配置要参照文档了)

呆呆向前冲的blog — Thu, 28 Jul 2005 14:09:00 GMT

Short introduction to log4j

Ceki Gülcü

March 2002

Copyright © 2000-2004 The Apache Software Foundation. All rights reserved. This software is published under the terms of the Apache Software License version 1.1, a copy of which has been included in the LICENSE.txt file shipped with the log4j distribution. The present short manual also borrows some text from "The complete log4j manual", which contains more detailed and up to date information, by the same author (yours truly).

Abstract

This document describes the log4j API, its unique features and design rationale. Log4j is an open source project based on the work of many authors. It allows the developer to control which log statements are output with arbitrary granularity. It is fully configurable at runtime using external configuration files. Best of all, log4j has a gentle learning curve. Beware: judging from user feedback, it is also quite addictive.

Introduction

Almost every large application includes its own logging or tracing API. In conformance with this rule, the E.U. SEMPER project decided to write its own tracing API. This was in early 1996. After countless enhancements, several incarnations and much work that API has evolved to become log4j, a popular logging package for Java. The package is distributed under the Apache Software License, a fully-fledged open source license certified by the open source initiative. The latest log4j version, including full-source code, class files and documentation can be found at http://logging.apache.org/log4j/. By the way, log4j has been ported to the C, C++, C#, Perl, Python, Ruby, and Eiffel languages.

Inserting log statements into code is a low-tech method for debugging it. It may also be the only way because debuggers are not always available or applicable. This is usually the case for multithreaded applications and distributed applications at large.

Experience indicates that logging was an important component of the development cycle. It offers several advantages. It provides precise context about a run of the application. Once inserted into the code, the generation of logging output requires no human intervention. Moreover, log output can be saved in a persistent medium to be studied at a later time. In addition to its use in the development cycle, a sufficiently-rich logging package can also be viewed as an auditing tool.

As Brian W. Kernighan and Rob Pike put it in their truly excellent book "The Practice of Programming"

  As personal choice, we tend not to use debuggers beyond getting a
  stack trace or the value of a variable or two. One reason is that it
  is easy to get lost in details of complicated data structures and
  control flow; we find stepping through a program less productive
  than thinking harder and adding output statements and self-checking
  code at critical places. Clicking over statements takes longer than
  scanning the output of judiciously-placed displays. It takes less
  time to decide where to put print statements than to single-step to
  the critical section of code, even assuming we know where that
  is. More important, debugging statements stay with the program;
  debugging sessions are transient.

Logging does have its drawbacks. It can slow down an application. If too verbose, it can cause scrolling blindness. To alleviate these concerns, log4j is designed to be reliable, fast and extensible. Since logging is rarely the main focus of an application, the log4j API strives to be simple to understand and to use.

Loggers, Appenders and Layouts

Log4j has three main components: loggers, appenders and layouts. These three types of components work together to enable developers to log messages according to message type and level, and to control at runtime how these messages are formatted and where they are reported.

Logger hierarchy

The first and foremost advantage of any logging API over plain System.out.println resides in its ability to disable certain log statements while allowing others to print unhindered. This capability assumes that the logging space, that is, the space of all possible logging statements, is categorized according to some developer-chosen criteria. This observation had previously led us to choose category as the central concept of the package. However, since log4j version 1.2, Logger class has replaced the Category class. For those familiar with earlier versions of log4j, the Logger class can be considered as a mere alias to the Category class.

Loggers are named entities. Logger names are case-sensitive and they follow the hierarchical naming rule:

Named Hierarchy: A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger.

For example, the logger named "com.foo" is a parent of the logger named "com.foo.Bar". Similarly, "java" is a parent of "java.util" and an ancestor of "java.util.Vector". This naming scheme should be familiar to most developers.

The root logger resides at the top of the logger hierarchy. It is exceptional in two ways:

it always exists,
it cannot be retrieved by name.

Invoking the class static Logger.getRootLogger method retrieves it. All other loggers are instantiated and retrieved with the class static Logger.getLogger method. This method takes the name of the desired logger as a parameter. Some of the basic methods in the Logger class are listed below.

  package org.apache.log4j;

  public class Logger {

    // Creation & retrieval methods:
    public static Logger getRootLogger();
    public static Logger getLogger(String name);

    // printing methods:
    public void debug(Object message);
    public void info(Object message);
    public void warn(Object message);
    public void error(Object message);
    public void fatal(Object message);

    // generic printing method:
    public void log(Level l, Object message);
}

Loggers may be assigned levels. The set of possible levels, that is DEBUG, INFO, WARN, ERROR and FATAL are defined in the org.apache.log4j.Level class. Although we do not encourage you to do so, you may define your own levels by sub-classing the Level class. A perhaps better approach will be explained later on.

If a given logger is not assigned a level, then it inherits one from its closest ancestor with an assigned level. More formally:

Level Inheritance: The inherited level for a given logger C, is equal to the first non-null level in the logger hierarchy, starting at C and proceeding upwards in the hierarchy towards the root logger.

To ensure that all loggers can eventually inherit a level, the root logger always has an assigned level.

Below are four tables with various assigned level values and the resulting inherited levels according to the above rule.

Example 1
Logger name	Assigned level	Inherited level
root	Proot	Proot
X	none	Proot
X.Y	none	Proot
X.Y.Z	none	Proot

In example 1 above, only the root logger is assigned a level. This level value, Proot, is inherited by the other loggers X, X.Y and X.Y.Z.

Example 2
Logger name	Assigned level	Inherited level
root	Proot	Proot
X	Px	Px
X.Y	Pxy	Pxy
X.Y.Z	Pxyz	Pxyz

In example 2, all loggers have an assigned level value. There is no need for level inheritence.

Example 3
Logger name	Assigned level	Inherited level
root	Proot	Proot
X	Px	Px
X.Y	none	Px
X.Y.Z	Pxyz	Pxyz

In example 3, the loggers root, X and X.Y.Z are assigned the levels Proot, Px and Pxyz respectively. The logger X.Y inherits its level value from its parent X.

Example 4
Logger name	Assigned level	Inherited level
root	Proot	Proot
X	Px	Px
X.Y	none	Px
X.Y.Z	none	Px

In example 4, the loggers root and X and are assigned the levels Proot and Px respectively. The loggers X.Y and X.Y.Z inherits their level value from their nearest parent X having an assigned level..

Logging requests are made by invoking one of the printing methods of a logger instance. These printing methods are debug, info, warn, error, fatal and log.

By definition, the printing method determines the level of a logging request. For example, if c is a logger instance, then the statement c.info("..") is a logging request of level INFO.

A logging request is said to be enabled if its level is higher than or equal to the level of its logger. Otherwise, the request is said to be disabled. A logger without an assigned level will inherit one from the hierarchy. This rule is summarized below.

Basic Selection Rule: A log request of level p in a logger with (either assigned or inherited, whichever is appropriate) level q, is enabled if p >= q.

This rule is at the heart of log4j. It assumes that levels are ordered. For the standard levels, we have DEBUG < INFO < WARN < ERROR < FATAL.

Here is an example of this rule.

   // get a logger instance named "com.foo"
   Logger  logger = Logger.getLogger("com.foo");

   // Now set its level. Normally you do not need to set the
   // level of a logger programmatically. This is usually done
   // in configuration files.
   logger.setLevel(Level.INFO);

   Logger barlogger = Logger.getLogger("com.foo.Bar");

   // This request is enabled, because WARN >= INFO.
   logger.warn("Low fuel level.");

   // This request is disabled, because DEBUG < INFO.
   logger.debug("Starting search for nearest gas station.");

   // The logger instance barlogger, named "com.foo.Bar",
   // will inherit its level from the logger named
   // "com.foo" Thus, the following request is enabled
   // because INFO >= INFO.
   barlogger.info("Located nearest gas station.");

   // This request is disabled, because DEBUG < INFO.
   barlogger.debug("Exiting gas station search");

Calling the getLogger method with the same name will always return a reference to the exact same logger object.

For example, in

   Logger x = Logger.getLogger("wombat");
   Logger y = Logger.getLogger("wombat");

x and y refer to exactly the same logger object.

Thus, it is possible to configure a logger and then to retrieve the same instance somewhere else in the code without passing around references. In fundamental contradiction to biological parenthood, where parents always preceed their children, log4j loggers can be created and configured in any order. In particular, a "parent" logger will find and link to its descendants even if it is instantiated after them.

Configuration of the log4j environment is typically done at application initialization. The preferred way is by reading a configuration file. This approach will be discussed shortly.

Log4j makes it easy to name loggers by software component. This can be accomplished by statically instantiating a logger in each class, with the logger name equal to the fully qualified name of the class. This is a useful and straightforward method of defining loggers. As the log output bears the name of the generating logger, this naming strategy makes it easy to identify the origin of a log message. However, this is only one possible, albeit common, strategy for naming loggers. Log4j does not restrict the possible set of loggers. The developer is free to name the loggers as desired.

Nevertheless, naming loggers after the class where they are located seems to be the best strategy known so far.

Appenders and Layouts

The ability to selectively enable or disable logging requests based on their logger is only part of the picture. Log4j allows logging requests to print to multiple destinations. In log4j speak, an output destination is called an appender. Currently, appenders exist for the console, files, GUI components, remote socket servers, JMS, NT Event Loggers, and remote UNIX Syslog daemons. It is also possible to log asynchronously.

More than one appender can be attached to a logger.

The addAppender method adds an appender to a given logger. Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy. In other words, appenders are inherited additively from the logger hierarchy. For example, if a console appender is added to the root logger, then all enabled logging requests will at least print on the console. If in addition a file appender is added to a logger, say C, then enabled logging requests for C and C's children will print on a file and on the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag to false.

The rules governing appender additivity are summarized below.

Appender Additivity

The output of a log statement of logger C will go to all the appenders in C and its ancestors. This is the meaning of the term "appender additivity".

However, if an ancestor of logger C, say P, has the additivity flag set to false, then C's output will be directed to all the appenders in C and it's ancestors upto and including P but not the appenders in any of the ancestors of P.

Loggers have their additivity flag set to true by default.

The table below shows an example:

Logger Name	Added Appenders	Additivity Flag	Output Targets	Comment
root	A1	not applicable	A1	The root logger is anonymous but can be accessed with the Logger.getRootLogger() method. There is no default appender attached to root.
x	A-x1, A-x2	true	A1, A-x1, A-x2	Appenders of "x" and root.
x.y	none	true	A1, A-x1, A-x2	Appenders of "x" and root.
x.y.z	A-xyz1	true	A1, A-x1, A-x2, A-xyz1	Appenders in "x.y.z", "x" and root.
security	A-sec	false	A-sec	No appender accumulation since the additivity flag is set to `false`.
security.access	none	true	A-sec	Only appenders of "security" because the additivity flag in "security" is set to `false`.

More often than not, users wish to customize not only the output destination but also the output format. This is accomplished by associating a layout with an appender. The layout is responsible for formatting the logging request according to the user's wishes, whereas an appender takes care of sending the formatted output to its destination. The PatternLayout, part of the standard log4j distribution, lets the user specify the output format according to conversion patterns similar to the C language printf function.

For example, the PatternLayout with the conversion pattern "%r [%t] %-5p %c - %m%n" will output something akin to:

176 [main] INFO  org.foo.Bar - Located nearest gas station.

The first field is the number of milliseconds elapsed since the start of the program. The second field is the thread making the log request. The third field is the level of the log statement. The fourth field is the name of the logger associated with the log request. The text after the '-' is the message of the statement.

Just as importantly, log4j will render the content of the log message according to user specified criteria. For example, if you frequently need to log Oranges, an object type used in your current project, then you can register an OrangeRenderer that will be invoked whenever an orange needs to be logged.

Object rendering follows the class hierarchy. For example, assuming oranges are fruits, if you register an FruitRenderer, all fruits including oranges will be rendered by the FruitRenderer, unless of course you registered an orange specific OrangeRenderer.

Object renderers have to implement the ObjectRenderer interface.

Configuration

Inserting log requests into the application code requires a fair amount of planning and effort. Observation shows that approximately 4 percent of code is dedicated to logging. Consequently, even moderately sized applications will have thousands of logging statements embedded within their code. Given their number, it becomes imperative to manage these log statements without the need to modify them manually.

The log4j environment is fully configurable programmatically. However, it is far more flexible to configure log4j using configuration files. Currently, configuration files can be written in XML or in Java properties (key=value) format.

Let us give a taste of how this is done with the help of an imaginary application MyApp that uses log4j.

 import com.foo.Bar;

 // Import log4j classes.
 import org.apache.log4j.Logger;
 import org.apache.log4j.BasicConfigurator;

 public class MyApp {

   // Define a static logger variable so that it references the
   // Logger instance named "MyApp".
   static Logger logger = Logger.getLogger(MyApp.class);

   public static void main(String[] args) {

     // Set up a simple configuration that logs on the console.
     BasicConfigurator.configure();

     logger.info("Entering application.");
     Bar bar = new Bar();
     bar.doIt();
     logger.info("Exiting application.");
   }
 }

MyApp begins by importing log4j related classes. It then defines a static logger variable with the name MyApp which happens to be the fully qualified name of the class.

MyApp uses the Bar class defined in the package com.foo.

 package com.foo;
 import org.apache.log4j.Logger;

 public class Bar {
   static Logger logger = Logger.getLogger(Bar.class);

   public void doIt() {
     logger.debug("Did it again!");
   }
 }

The invocation of the BasicConfigurator.configure method creates a rather simple log4j setup. This method is hardwired to add to the root logger a ConsoleAppender. The output will be formatted using a PatternLayout set to the pattern "%-4r [%t] %-5p %c %x - %m%n".

Note that by default, the root logger is assigned to Level.DEBUG.

The output of MyApp is:

0    [main] INFO  MyApp  - Entering application.
36   [main] DEBUG com.foo.Bar  - Did it again!
51   [main] INFO  MyApp  - Exiting application.

The figure below depicts the object diagram of MyApp after just having called the BasicConfigurator.configure method.

As a side note, let me mention that in log4j child loggers link only to their existing ancestors. In particular, the logger named com.foo.Bar is linked directly to the root logger, thereby circumventing the unused com or com.foo loggers. This significantly increases performance and reduces log4j's memory footprint.

The MyApp class configures log4j by invoking BasicConfigurator.configure method. Other classes only need to import the org.apache.log4j.Logger class, retrieve the loggers they wish to use, and log away.

The previous example always outputs the same log information. Fortunately, it is easy to modify MyApp so that the log output can be controlled at run-time. Here is a slightly modified version.

 import com.foo.Bar;

 import org.apache.log4j.Logger;
 import org.apache.log4j.PropertyConfigurator;

 public class MyApp {

   static Logger logger = Logger.getLogger(MyApp.class.getName());

   public static void main(String[] args) {


     // BasicConfigurator replaced with PropertyConfigurator.
     PropertyConfigurator.configure(args[0]);

     logger.info("Entering application.");
     Bar bar = new Bar();
     bar.doIt();
     logger.info("Exiting application.");
   }
 }

This version of MyApp instructs PropertyConfigurator to parse a configuration file and set up logging accordingly.

Here is a sample configuration file that results in exactly same output as the previous BasicConfigurator based example.

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

Suppose we are no longer interested in seeing the output of any component belonging to the com.foo package. The following configuration file shows one possible way of achieving this.

log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# Print only messages of level WARN or above in the package com.foo.
log4j.logger.com.foo=WARN

The output of MyApp configured with this file is shown below.

2000-09-07 14:07:41,508 [main] INFO  MyApp - Entering application.
2000-09-07 14:07:41,529 [main] INFO  MyApp - Exiting application.

As the logger com.foo.Bar does not have an assigned level, it inherits its level from com.foo, which was set to WARN in the configuration file. The log statement from the Bar.doIt method has the level DEBUG, lower than the logger level WARN. Consequently, doIt() method's log request is suppressed.

Here is another configuration file that uses multiple appenders.

log4j.rootLogger=debug, stdout, R

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# Pattern to output the caller's file name and line number.
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log

log4j.appender.R.MaxFileSize=100KB
# Keep one backup file
log4j.appender.R.MaxBackupIndex=1

log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

Calling the enhanced MyApp with the this configuration file will output the following on the console.

 INFO [main] (MyApp2.java:12) - Entering application.
DEBUG [main] (Bar.java:8) - Doing it again!
 INFO [main] (MyApp2.java:15) - Exiting application.

In addition, as the root logger has been allocated a second appender, output will also be directed to the example.log file. This file will be rolled over when it reaches 100KB. When roll-over occurs, the old version of example.log is automatically moved to example.log.1.

Note that to obtain these different logging behaviors we did not need to recompile code. We could just as easily have logged to a UNIX Syslog daemon, redirected all com.foo output to an NT Event logger, or forwarded logging events to a remote log4j server, which would log according to local server policy, for example by forwarding the log event to a second log4j server.

Default Initialization Procedure

The log4j library does not make any assumptions about its environment. In particular, there are no default log4j appenders. Under certain well-defined circumstances however, the static inializer of the Logger class will attempt to automatically configure log4j. The Java language guarantees that the static initializer of a class is called once and only once during the loading of a class into memory. It is important to remember that different classloaders may load distinct copies of the same class. These copies of the same class are considered as totally unrelated by the JVM.

The default initialization is very useful in environments where the exact entry point to the application depends on the runtime environment. For example, the same application can be used as a stand-alone application, as an applet, or as a servlet under the control of a web-server.

The exact default initialization algorithm is defined as follows:

Setting the log4j.defaultInitOverride system property to any other value then "false" will cause log4j to skip the default initialization procedure (this procedure).

Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value "log4j.properties".

Attempt to convert the resource variable to a URL.

If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the classpath by calling org.apache.log4j.helpers.Loader.getResource(resource, Logger.class) which returns a URL. Note that the string "log4j.properties" constitutes a malformed URL.
See Loader.getResource(java.lang.String) for the list of searched locations.
If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL.
The PropertyConfigurator will be used to parse the URL to configure log4j unless the URL ends with the ".xml" extension, in which case the DOMConfigurator will be used. You can optionaly specify a custom configurator. The value of the log4j.configuratorClass system property is taken as the fully qualified class name of your custom configurator. The custom configurator you specify must implement the Configurator interface.

Example Configurations

Default Initialization under Tomcat

The default log4j initialization is particularly useful in web-server environments. Under Tomcat 3.x and 4.x, you should place the log4j.properties under the WEB-INF/classes directory of your web-applications. Log4j will find the properties file and initialize itself. This is easy to do and it works.

You can also choose to set the system property log4j.configuration before starting Tomcat. For Tomcat 3.x The TOMCAT_OPTS environment variable is used to set command line options. For Tomcat 4.0, set the CATALINA_OPTS environment variable instead of TOMCAT_OPTS.

Example 1

The Unix shell command

   export TOMCAT_OPTS="-Dlog4j.configuration=foobar.txt"

tells log4j to use the file foobar.txt as the default configuration file. This file should be place under the WEB-INF/classes directory of your web-application. The file will be read using the PropertyConfigurator. Each web-application will use a different default configuration file because each file is relative to a web-application.

Example 2

The Unix shell command

   export TOMCAT_OPTS="-Dlog4j.debug -Dlog4j.configuration=foobar.xml"

tells log4j to output log4j-internal debugging information and to use the file foobar.xml as the default configuration file. This file should be place under the WEB-INF/classes directory of your web-application. Since the file ends with a .xml extension, it will read using the DOMConfigurator. Each web-application will use a different default configuration file because each file is relative to a web-application.

Example 3

The Windows shell command

   set TOMCAT_OPTS=-Dlog4j.configuration=foobar.lcf -Dlog4j.configuratorClass=com.foo.BarConfigurator

tells log4j to use the file foobar.lcf as the default configuration file. This file should be place under the WEB-INF/classes directory of your web-application. Due to the definition of the log4j.configuratorClass system property, the file will be read using the com.foo.BarConfigurator custom configurator. Each web-application will use a different default configuration file because each file is relative to a web-application.

Example 4

The Windows shell command

   set TOMCAT_OPTS=-Dlog4j.configuration=file:/c:/foobar.lcf

tells log4j to use the file c:\foobar.lcf as the default configuration file. The configuration file is fully specified by the URL file:/c:/foobar.lcf. Thus, the same configuration file will be used for all web-applications.

Different web-applications will load the log4j classes through their respective classloaderss. Thus, each image of the log4j environment will act independetly and without any mutual synchronization. For example, FileAppenders defined exactly the same way in multiple web-application configurations will all attempt to write the same file. The results are likely to be less than satisfactory. You must make sure that log4j configurations of different web-applications do not use the same underlying system resource.

Initialization servlet

It is also possible to use a special servlet for log4j initialization. Here is an example,

package com.foo;

import org.apache.log4j.PropertyConfigurator;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;

public class Log4jInit extends HttpServlet {

  public
  void init() {
    String prefix =  getServletContext().getRealPath("/");
    String file = getInitParameter("log4j-init-file");
    // if the log4j-init-file is not set, then no point in trying
    if(file != null) {
      PropertyConfigurator.configure(prefix+file);
    }
  }

  public
  void doGet(HttpServletRequest req, HttpServletResponse res) {
  }
}

Define the following servlet in the web.xml file for your web-application.

  
    log4j-init
    com.foo.Log4jInit

    
      log4j-init-file
      WEB-INF/classes/log4j.lcf
    

    1

Writing an initialization servlet is the most flexible way for initializing log4j. There are no constraints on the code you can place in the init() method of the servlet.

Nested Diagnostic Contexts

Most real-world systems have to deal with multiple clients simultaneously. In a typical multithreaded implementation of such a system, different threads will handle different clients. Logging is especially well suited to trace and debug complex distributed applications. A common approach to differentiate the logging output of one client from another is to instantiate a new separate logger for each client. This promotes the proliferation of loggers and increases the management overhead of logging.

A lighter technique is to uniquely stamp each log request initiated from the same client interaction. Neil Harrison described this method in the book "Patterns for Logging Diagnostic Messages," in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997).

To uniquely stamp each request, the user pushes contextual information into the NDC, the abbreviation of Nested Diagnostic Context. The NDC class is shown below.

  public class NDC {
    // Used when printing the diagnostic
    public static String get();

    // Remove the top of the context from the NDC.
    public static String pop();

    // Add diagnostic context for the current thread.
    public static void push(String message);

    // Remove the diagnostic context for this thread.
    public static void remove();
  }

The NDC is managed per thread as a stack of contextual information. Note that all methods of the org.apache.log4j.NDC class are static. Assuming that NDC printing is turned on, every time a log request is made, the appropriate log4j component will include the entire NDC stack for the current thread in the log output. This is done without the intervention of the user, who is responsible only for placing the correct information in the NDC by using the push and pop methods at a few well-defined points in the code. In contrast, the per-client logger approach commands extensive changes in the code.

To illustrate this point, let us take the example of a servlet delivering content to numerous clients. The servlet can build the NDC at the very beginning of the request before executing other code. The contextual information can be the client's host name and other information inherent to the request, typically information contained in cookies. Hence, even if the servlet is serving multiple clients simultaneously, the logs initiated by the same code, i.e. belonging to the same logger, can still be distinguished because each client request will have a different NDC stack. Contrast this with the complexity of passing a freshly instantiated logger to all code exercised during the client's request.

Nevertheless, some sophisticated applications, such as virtual hosting web servers, must log differently depending on the virtual host context and also depending on the software component issuing the request. Recent log4j releases support multiple hierarchy trees. This enhancement allows each virtual host to possess its own copy of the logger hierarchy.

Performance

One of the often-cited arguments against logging is its computational cost. This is a legitimate concern as even moderately sized applications can generate thousands of log requests. Much effort was spent measuring and tweaking logging performance. Log4j claims to be fast and flexible: speed first, flexibility second.

The user should be aware of the following performance issues.

Logging performance when logging is turned off.
When logging is turned off entirely or just for a set of levels, the cost of a log request consists of a method invocation plus an integer comparison. On a 233 MHz Pentium II machine this cost is typically in the 5 to 50 nanosecond range.
However, The method invocation involves the "hidden" cost of parameter construction.
For example, for some logger cat, writing,
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
incurs the cost of constructing the message parameter, i.e. converting both integer i and entry[i] to a String, and concatenating intermediate strings, regardless of whether the message will be logged or not. This cost of parameter construction can be quite high and it depends on the size of the parameters involved.
To avoid the parameter construction cost write:
if(logger.isDebugEnabled() { logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); }

This will not incur the cost of parameter construction if debugging is disabled. On the other hand, if the logger is debug-enabled, it will incur twice the cost of evaluating whether the logger is enabled or not: once in debugEnabled and once in debug. This is an insignificant overhead because evaluating a logger takes about 1% of the time it takes to actually log.
In log4j, logging requests are made to instances of the Logger class. Logger is a class and not an interface. This measurably reduces the cost of method invocation at the cost of some flexibility.
Certain users resort to preprocessing or compile-time techniques to compile out all log statements. This leads to perfect performance efficiency with respect to logging. However, since the resulting application binary does not contain any log statements, logging cannot be turned on for that binary. In my opinion this is a disproportionate price to pay in exchange for a small performance gain.
The performance of deciding whether to log or not to log when logging is turned on.

This is essentially the performance of walking the logger hierarchy. When logging is turned on, log4j still needs to compare the level of the log request with the level of the request logger. However, loggers may not have an assigned level; they can inherit them from the logger hierarchy. Thus, before inheriting a level, the logger may need to search its ancestors.
There has been a serious effort to make this hierarchy walk to be as fast as possible. For example, child loggers link only to their existing ancestors. In the BasicConfigurator example shown earlier, the logger named com.foo.Bar is linked directly to the root logger, thereby circumventing the nonexistent com or com.foo loggers. This significantly improves the speed of the walk, especially in "sparse" hierarchies.
The typical cost of walking the hierarchy is typically 3 times slower than when logging is turned off entirely.
Actually outputting log messages
This is the cost of formatting the log output and sending it to its target destination. Here again, a serious effort was made to make layouts (formatters) perform as quickly as possible. The same is true for appenders. The typical cost of actually logging is about 100 to 300 microseconds. See org.apache.log4.performance.Logging for actual figures.

Although log4j has many features, its first design goal was speed. Some log4j components have been rewritten many times to improve performance. Nevertheless, contributors frequently come up with new optimizations. You should be pleased to know that when configured with the SimpleLayout performance tests have shown log4j to log as quickly as System.out.println.

Conclusions

Log4j is a popular logging package written in Java. One of its distinctive features is the notion of inheritance in loggers. Using a logger hierarchy it is possible to control which log statements are output at arbitrary granularity. This helps reduce the volume of logged output and minimize the cost of logging.

One of the advantages of the log4j API is its manageability. Once the log statements have been inserted into the code, they can be controlled with configuration files. They can be selectively enabled or disabled, and sent to different and multiple output targets in user-chosen formats. The log4j package is designed so that log statements can remain in shipped code without incurring a heavy performance cost.

Acknowledgments

Many thanks to N. Asokan for reviewing the article. He is also one of the originators of the logger concept. I am indebted to Nelson Minar for encouraging me to write this article. He has also made many useful suggestions and corrections to this article. Log4j is the result of a collective effort. My special thanks go to all the authors who have contributed to the project. Without exception, the best features in the package have all originated in the user community.

呆呆向前冲的blog 2005-07-28 22:09 发表评论

Log4j配置

呆呆向前冲的blog — Thu, 28 Jul 2005 13:34:00 GMT

Log4j的几个问题：
·log4j的三大组件：logger,appender,layout

·怎么在web环境中配置Log4j
·如何理解log4j
·正确的配置log4j.properties
      ConversionPattern的配置：

·程序中如何正确的使用logger


1.Log4j在web环境中的配置
　　首先到jakarta下载一个log4j的组件。把jakarta-log4j-1.2.8\dist\lib下的log4j-1.2.8.jar文件copy到classpath指定的目录下！可以是Tomcat的common\lib目录下，也可以是你需要用到log4j的application下的lib目录。
　　1.4在Application目录下的web.xml文件加入以后代码
　　
　　log4j
　　com.apache.jakarta.log4j.Log4jInit
　　
　　log4j
　　/WEB-INF/log4j.properties
　　
　　1
　　

Logger的四个级别：DEBUG
      log4j的配置文件大致分为以下几部分：
      1.rootLogger的配置

log4j.rootLogger=debug, stdout, R

2.具体appender的配置

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# Pattern to output the caller's file name and line number.
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

详细要弄懂的就是appender要配置的东西，比如输出类型，输出格式，

呆呆向前冲的blog 2005-07-28 21:34 发表评论

package和import机制

呆呆向前冲的blog — Wed, 20 Jul 2005 07:52:00 GMT

   java编译器开始编译某个类的源代码时：
第一步：根据选项-classpath或环境变量CLASSPATH建立“类路径引用表”;如果都没有，使用缺省的“.”
注意：环境变量的内容会被选项-classpath覆盖。没有累加效果

                                          1 D:\test
                                          2 C:\p.jar
                                          类路径引用表内容

第二步：编译器要确定它可以利用类引用表里的数据作为相对起始路径，找到所有用到的package，并将import语句里的.用/替换

第三步：根据类路径内容为起点，比较其中一个路径是否存在同名的目录或文件名称。

呆呆向前冲的blog 2005-07-20 15:52 发表评论

深入类装载器

呆呆向前冲的blog — Mon, 18 Jul 2005 16:57:00 GMT

隐式方法：new
显式方法：
1。java.lang.Class的forName方法
2。java.lang.ClassLoader里的loadClass方法

◆ 无法自行产生Class的实体，因为构造函数声明为private。
◇ 只能通过Object的getClass方法，或者Class.forName("类名")获得。
◆ Class类的实体在第一次载入内存时就建立了。以后在程序中产生Class代表的类的实体，其内部都会有个字段记录着这个Class类所在的位置。
◇ 可以把每个Class类的实体当作是某个类(*.class)在内存中的代理。
◆ 在Java中，每个类都是由某个类加载器(ClassLoader)来载入的，因此在Class类的实体中，由字段记录载入它的ClassLoader的实体。如果该字段是null，不代表它不是由类装载器所载入，而是代表这个类由引导式装载器(bootstrap loader)载入。但是这个装载器不是java编写的，所以没有实体。

图1
注意：系统里同时存在多个ClassLoader实体。而且一个类装载器可以载入多个类

★ 使用已有类装载器

1        Office off = new Office();
2        ClassLoader loader = off.getClass().getClassLoader();
3        Class c = loader.loadClass(args[0]);
4        Object o = c.newInstance();

注意：loadClass方法加载类时不会自动调用静态初始化块(static块)，必须等到第一次实体化该类时，才会调用。这与forName时传入第二个参数为false的效果相同。

下面是上述代码的另一种写法：

1        Class cb = Office.class;
2        ClassLoader loader = cb.getClassLoader();
3        Class c = loader.loadClass(args[0]);
4        Object o = c.newInstance();

★ 自己建立类装载器来载入类

URLClassLoader

★ 类装载器的阶层体系

Java程序运行流程：

shur输入java ***.class，java.exe根据自己的搜索逻辑找到JRE，接着找到位于JRE中的jvm.dll（真正的java虚拟机）。最后载入这个动态链接库，激活java虚拟机。
      虚拟机一旦激活，会先做一些初始化操作，如获取系统参数。
     初始化完成后，产生第一个类装载器 Bootstrap Loader。然后做一些基本的初始化，然后它载入sun.misc命名空间底下的Launcher.java之中的ExtClassLoader，并设置其parent为null。然后Bootstrap Loader会继续载入sun.misc命名空间下的Launcher.java之中的AppClassLoader，并设置其parent为刚载入的ExtClassLoader实体。
      最后由AppClassLoader负责载入***.class。
      注意：上述三个类装载器搜索类的路径都是载入时读取的，分别是“sun.boot.class.path”、“java.ext.dirs”、“java.class.path”，而且在虚拟机中只保留一份。在系统运行过程中不可能动态改变，除非使用新的类装载器。

★ 委托模型

      类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入。如果Parent找不到，才由自己依照自己的搜索路径搜索类。

呆呆向前冲的blog 2005-07-19 00:57 发表评论

java.exe寻找JRE的顺序

呆呆向前冲的blog — Mon, 18 Jul 2005 16:48:00 GMT

java.exe按照如下的逻辑来寻找JRE:
1。自己目录下有没有JRE
2。父目录下的JRE子目录
3。查询注册表里指定的JRE路径

注意：一定要弄清自己运行的是哪个java.exe。一般java.exe的路径信息在系统path变量里设置

呆呆向前冲的blog 2005-07-19 00:48 发表评论

[需要注意] Java异常处理机制的理解

呆呆向前冲的blog — Sun, 17 Jul 2005 08:47:00 GMT

你觉得自己是一个Java专家吗？是否肯定自己已经全面掌握了Java的异常处理机制？在下面这段代码中，你能够迅速找出异常处理的六个问题吗？

　　1 OutputStreamWriter out = ...
　　2 java.sql.Connection conn = ...
　　3 try { // ⑸
　　4 Statement stat = conn.createStatement();
　　5 ResultSet rs = stat.executeQuery(
　　6 "select uid, name from user");
　　7 while (rs.next())
　　8 {
　　9 out.println("ID：" + rs.getString("uid") // ⑹
　　10 "，姓名：" + rs.getString("name"));
　　11 }
　　12 conn.close(); // ⑶
　　13 out.close();
　　14 }
　　15 catch(Exception ex) // ⑵
　　16 {
　　17 ex.printStackTrace(); // ⑴，⑷
　　18 }

　　作为一个Java程序员，你至少应该能够找出两个问题。但是，如果你不能找出全部六个问题，请继续阅读本文。

　　本文讨论的不是Java异常处理的一般性原则，因为这些原则已经被大多数人熟知。我们要做的是分析各种可称为“反例”（anti-pattern）的违背优秀编码规范的常见坏习惯，帮助读者熟悉这些典型的反面例子，从而能够在实际工作中敏锐地察觉和避免这些问题。

　　反例之一：丢弃异常

　　代码：15行-18行。

　　这段代码捕获了异常却不作任何处理，可以算得上Java编程中的杀手。从问题出现的频繁程度和祸害程度来看，它也许可以和C/C++程序的一个恶名远播的问题相提并论??不检查缓冲区是否已满。如果你看到了这种丢弃（而不是抛出）异常的情况，可以百分之九十九地肯定代码存在问题（在极少数情况下，这段代码有存在的理由，但最好加上完整的注释，以免引起别人误解）。

　　这段代码的错误在于，异常（几乎）总是意味着某些事情不对劲了，或者说至少发生了某些不寻常的事情，我们不应该对程序发出的求救信号保持沉默和无动于衷。调用一下printStackTrace算不上“处理异常”。不错，调用printStackTrace对调试程序有帮助，但程序调试阶段结束之后，printStackTrace就不应再在异常处理模块中担负主要责任了。

　　丢弃异常的情形非常普遍。打开JDK的ThreadDeath类的文档，可以看到下面这段说明：“特别地，虽然出现ThreadDeath是一种‘正常的情形’，但ThreadDeath类是Error而不是Exception的子类，因为许多应用会捕获所有的Exception然后丢弃它不再理睬。”这段话的意思是，虽然ThreadDeath代表的是一种普通的问题，但鉴于许多应用会试图捕获所有异常然后不予以适当的处理，所以JDK把ThreadDeath定义成了Error的子类，因为Error类代表的是一般的应用不应该去捕获的严重问题。可见，丢弃异常这一坏习惯是如此常见，它甚至已经影响到了Java本身的设计。

　　那么，应该怎样改正呢？主要有四个选择：

　　1、处理异常。针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。再次说明，调用printStackTrace算不上已经“处理好了异常”。
　　2、重新抛出异常。处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。
　　3、把该异常转换成另一种异常。大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常）。
　　4、不要捕获异常。

　　结论一：既然捕获了异常，就要对它进行适当的处理。不要捕获异常之后又把它丢弃，不予理睬。

　　反例之二：不指定具体的异常

　　代码：15行。

　　许多时候人们会被这样一种“美妙的”想法吸引：用一个catch语句捕获所有的异常。最常见的情形就是使用catch(Exception ex)语句。但实际上，在绝大多数情况下，这种做法不值得提倡。为什么呢？

　　要理解其原因，我们必须回顾一下catch语句的用途。catch语句表示我们预期会出现某种异常，而且希望能够处理该异常。异常类的作用就是告诉Java编译器我们想要处理的是哪一种异常。由于绝大多数异常都直接或间接从java.lang.Exception派生，catch(Exception ex)就相当于说我们想要处理几乎所有的异常。
　　再来看看前面的代码例子。我们真正想要捕获的异常是什么呢？最明显的一个是SQLException，这是JDBC操作中常见的异常。另一个可能的异常是IOException，因为它要操作OutputStreamWriter。显然，在同一个catch块中处理这两种截然不同的异常是不合适的。如果用两个catch块分别捕获SQLException和IOException就要好多了。这就是说，catch语句应当尽量指定具体的异常类型，而不应该指定涵盖范围太广的Exception类。

　　另一方面，除了这两个特定的异常，还有其他许多异常也可能出现。例如，如果由于某种原因，executeQuery返回了null，该怎么办？答案是让它们继续抛出，即不必捕获也不必处理。实际上，我们不能也不应该去捕获可能出现的所有异常，程序的其他地方还有捕获异常的机会??直至最后由JVM处理。

　　结论二：在catch语句中尽可能指定具体的异常类型，必要时使用多个catch。不要试图处理所有可能出现的异常。

　　反例之三：占用资源不释放

　　代码：3行-14行。

　　异常改变了程序正常的执行流程。这个道理虽然简单，却常常被人们忽视。如果程序用到了文件、Socket、JDBC连接之类的资源，即使遇到了异常，也要正确释放占用的资源。为此，Java提供了一个简化这类操作的关键词finally。

　　finally是样好东西：不管是否出现了异常，Finally保证在try/catch/finally块结束之前，执行清理任务的代码总是有机会执行。遗憾的是有些人却不习惯使用finally。

　　当然，编写finally块应当多加小心，特别是要注意在finally块之内抛出的异常??这是执行清理任务的最后机会，尽量不要再有难以处理的错误。

　　结论三：保证所有资源都被正确释放。充分运用finally关键词。

　　反例之四：不说明异常的详细信息

　　代码：3行-18行。

　　仔细观察这段代码：如果循环内部出现了异常，会发生什么事情？我们可以得到足够的信息判断循环内部出错的原因吗？不能。我们只能知道当前正在处理的类发生了某种错误，但却不能获得任何信息判断导致当前错误的原因。

　　printStackTrace的堆栈跟踪功能显示出程序运行到当前类的执行流程，但只提供了一些最基本的信息，未能说明实际导致错误的原因，同时也不易解读。

　　因此，在出现异常时，最好能够提供一些文字信息，例如当前正在执行的类、方法和其他状态信息，包括以一种更适合阅读的方式整理和组织printStackTrace提供的信息。

　　结论四：在异常处理模块中提供适量的错误原因信息，组织错误信息使其易于理解和阅读。

　　反例之五：过于庞大的try块

　　代码：3行-14行。

　　经常可以看到有人把大量的代码放入单个try块，实际上这不是好习惯。这种现象之所以常见，原因就在于有些人图省事，不愿花时间分析一大块代码中哪几行代码会抛出异常、异常的具体类型是什么。把大量的语句装入单个巨大的try块就象是出门旅游时把所有日常用品塞入一个大箱子，虽然东西是带上了，但要找出来可不容易。

　　一些新手常常把大量的代码放入单个try块，然后再在catch语句中声明Exception，而不是分离各个可能出现异常的段落并分别捕获其异常。这种做法为分析程序抛出异常的原因带来了困难，因为一大段代码中有太多的地方可能抛出Exception。

　　结论五：尽量减小try块的体积。

　　反例之六：输出数据不完整

　　代码：7行-11行。

　　不完整的数据是Java程序的隐形杀手。仔细观察这段代码，考虑一下如果循环的中间抛出了异常，会发生什么事情。循环的执行当然是要被打断的，其次，catch块会执行??就这些，再也没有其他动作了。已经输出的数据怎么办？使用这些数据的人或设备将收到一份不完整的（因而也是错误的）数据，却得不到任何有关这份数据是否完整的提示。对于有些系统来说，数据不完整可能比系统停止运行带来更大的损失。

　　较为理想的处置办法是向输出设备写一些信息，声明数据的不完整性；另一种可能有效的办法是，先缓冲要输出的数据，准备好全部数据之后再一次性输出。

　　结论六：全面考虑可能出现的异常以及这些异常对执行流程的影响。

　　改写后的代码

　　根据上面的讨论，下面给出改写后的代码。也许有人会说它稍微有点?嗦，但是它有了比较完备的异常处理机制。

　　OutputStreamWriter out = ...
　　java.sql.Connection conn = ...
　　try {
　　　Statement stat = conn.createStatement();
　　　ResultSet rs = stat.executeQuery("select uid, name from user");
　　　while (rs.next())
　　　{
　　　　out.println("ID：" + rs.getString("uid") + "，姓名: " + rs.getString("name"));
　　　}
　　}
　　catch(SQLException sqlex)
　　{
　　　out.println("警告：数据不完整");
　　　throw new ApplicationException("读取数据时出现SQL错误", sqlex);
　　}
　　catch(IOException ioex)
　　{
　　　throw new ApplicationException("写入数据时出现IO错误", ioex);
　　}
　　finally
　　{
　　　if (conn != null) {
　　　　try {
　　　　　conn.close();
　　　　}
　　　　catch(SQLException sqlex2)
　　　　{
　　　　　System.err(this.getClass().getName() + ".mymethod - 不能关闭数据库连接: " + sqlex2.toString());
　　　　}
　　　}
　　　if (out != null) {
　　　　try {
　　　　　out.close();
　　　　}
　　　　catch(IOException ioex2)
　　　　{
　　　　　System.err(this.getClass().getName() + ".mymethod - 不能关闭输出文件" + ioex2.toString());
　　　　}
　　　}
　　}

　　本文的结论不是放之四海皆准的教条，有时常识和经验才是最好的老师。如果你对自己的做法没有百分之百的信心，务必加上详细、全面的注释。
　　一方面，不要笑话这些错误，不妨问问你自己是否真地彻底摆脱了这些坏习惯。即使最有经验的程序员偶尔也会误入歧途，原因很简单，因为它们确确实实带来了“方便”。所有这些反例都可以看作Java编程世界的恶魔，它们美丽动人，无孔不入，时刻诱惑着你。也许有人会认为这些都属于鸡皮蒜毛的小事，不足挂齿，但请记住：勿以恶小而为之，勿以善小而不为。

呆呆向前冲的blog 2005-07-17 16:47 发表评论

JSTL

呆呆向前冲的blog — Wed, 13 Jul 2005 08:12:00 GMT

1 核心标签
1.1 表达式操作

1<c:set var="s1" value="45" />
2<c:catch var="error_message">
3<%
4 String eFormat = "wwx";
5 int i = Integer.parseInt(eFormat);
6%>
7c:catch>
8<c:out value="${error_message}"/>
9<c:set var="s2" value="2" />
10<c:remove var="s2"/>

      1.2 流程控制

1<c:if test="${ s1 == s2 }" var="condition" scope="page">
2<%="测试车"%>
3c:if>
4<c:out value="${condition}"/>
5<c:choose>
6  <c:when test="${s1 == 1}">
7    我是1
8  c:when>
9  <c:when test="${s1 == 2}">
10    我是2
11  c:when>
12  <c:otherwise>
13    都不对
14  c:otherwise>
15c:choose>

1.3 迭代操作

1<%
2    List list = new ArrayList();
3       list.add("张三");
4       list.add("李四");
5       list.add("王五");
6
7       request.setAttribute("members",list);
8%>
9<c:forEach var="member" items="${members}" varStatus="s">
10  <c:out value="${member}">
11  c:out>
12  <c:out value="${s.index}"/>
13  <c:out value="${s.count}"/>
14  <c:out value="${s.first}"/>
15  <c:out value="${s.last}"/>
16  c:out>
17c:forEach>

1.4 URL操作

1<c:import url="header.htm" var="cs" scope="request"/>
2<%
3 out.print(new String(request.getAttribute("cs").toString().getBytes("ISO-8859-1"),"GBK"));
4%>
5<c:out value="${cs}">

1//父页
2<c:set var="page" value="第一页" scope="request"/>
3<c:import url="include.jsp" charEncoding="GBK">
4 <c:param name="pageCount" value="共100页"/>
5c:import>
6
7//子页:include.jsp
8<c:out value="${param.pageCount}"/>

<% String eFormat = "wwx"; int i = Integer.parseInt(eFormat); %><% String eFormat = "wwx"; int i = Integer.parseInt(eFormat); %>

呆呆向前冲的blog 2005-07-13 16:12 发表评论

使用PL/SQL Developer的一个常见问题：TNS：无法处理服务名

呆呆向前冲的blog — Fri, 08 Jul 2005 09:38:00 GMT

配置一下Oracle客户端安装目录下的tnsnames.ora就可以了

呆呆向前冲的blog 2005-07-08 17:38 发表评论

定义并使用自定义标签库的步骤

呆呆向前冲的blog — Thu, 07 Jul 2005 07:05:00 GMT

1。编写标签处理类
2。编写标签库描述符
3。在web.xml中加入标签库描述符引用
4。在使用标签的页面用taglib指令引入标签库，定义前缀

呆呆向前冲的blog 2005-07-07 15:05 发表评论

日期格式化问题。从字符串构建Date对象，然后用SimpleDateFormat格式化成指定格式

呆呆向前冲的blog — Fri, 01 Jul 2005 07:11:00 GMT

1import java.text.*;
2import java.util.*;
3
4public class DateDemo {
5  public DateDemo() {
6  }
7  public static void main(String[] args){
8    String s = "2004-05-06 03:01:02";
9    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
10    try {
11      Date d = DateFormat.getDateTimeInstance().parse(s);
12      System.out.println(sdf.format(d));
13    }
14    catch (ParseException ex) {
15      ex.printStackTrace();
16    }
17
18  }
19}
20

呆呆向前冲的blog 2005-07-01 15:11 发表评论

JBuilder里Debug的一个问题

呆呆向前冲的blog — Fri, 01 Jul 2005 04:49:00 GMT

我在JBuilder的debug模式下运行的时候。修改了页面相关的一个类，然后make，但是在重新运行这个页面的时候好像就停在那运行不下去了，message消息窗口里显示等待重新部署修改的那个类的消息，就是不往下走了。

WebappClassLoader: Resource '/WEB-INF/classes/com/founder/cpm/publish/PublishPropertiesManager.class' was modified; Date is now: Fri Jul 01 12:49:10 CST 2005 Was: Fri Jul 01 12:42:52 CST 2005
StandardContext[/weblish3]: Reloading this Context has started
StandardWrapper[/weblish3:default]: Waiting for 2 instance(s) to be deallocated

呆呆向前冲的blog 2005-07-01 12:49 发表评论

Oracle对日期类型的处理

呆呆向前冲的blog — Fri, 01 Jul 2005 04:29:00 GMT

update app_publishlib set startdate = to_date('2005-01-09 00:00:00','yyyy-mm-dd hh24:mi:ss')

呆呆向前冲的blog 2005-07-01 12:29 发表评论

JBuilderX和JBuilder2005的字体光标问题

呆呆向前冲的blog — Thu, 30 Jun 2005 08:19:00 GMT

1. JBuilderX的光标不能对齐的问题源于Sun的JDK本身的问题，其实和Borland公司没有任何关系。解决的最好办法就是替换JBuilderX/jdk1.4/jre/lib目录下的font.properties.zh文件。这是一个关于字体的描述文件。只需要把这个文件替换如下内容，就可以了。

# @(#)font.properties.zh 1.10 02/03/07
#
# Copyright 2002 Sun Microsystems, Inc. All rights reserved.
#

# Component Font Mappings
#
dialog.plain.0=Tahoma,ANSI_CHARSET
dialog.plain.1=\u5b8b\u4f53,GB2312_CHARSET
dialog.plain.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialog.plain.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialog.bold.0=Tahoma Bold,ANSI_CHARSET
dialog.bold.1=\u5b8b\u4f53,GB2312_CHARSET
dialog.bold.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialog.bold.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialog.italic.0=Tahoma Italic,ANSI_CHARSET
dialog.italic.1=\u5b8b\u4f53,GB2312_CHARSET
dialog.italic.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialog.italic.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialog.bolditalic.0=Tahoma Bold Italic,ANSI_CHARSET
dialog.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
dialog.bolditalic.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialog.bolditalic.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialoginput.plain.0=Courier New,ANSI_CHARSET
dialoginput.plain.1=\u5b8b\u4f53,GB2312_CHARSET
dialoginput.plain.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialoginput.plain.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialoginput.bold.0=Courier New Bold,ANSI_CHARSET
dialoginput.bold.1=\u5b8b\u4f53,GB2312_CHARSET
dialoginput.bold.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialoginput.bold.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialoginput.italic.0=Courier New Italic,ANSI_CHARSET
dialoginput.italic.1=\u5b8b\u4f53,GB2312_CHARSET
dialoginput.italic.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialoginput.italic.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

dialoginput.bolditalic.0=Courier New Bold Italic,ANSI_CHARSET
dialoginput.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
dialoginput.bolditalic.2=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialoginput.bolditalic.3=Symbol,SYMBOL_CHARSET,NEED_CONVERTED

serif.plain.0=Tahoma,ANSI_CHARSET
serif.plain.1=\u5b8b\u4f53,GB2312_CHARSET
serif.plain.2=WingDings,SYMBOL_CHARSET
serif.plain.3=Symbol,SYMBOL_CHARSET

serif.bold.0=Tahoma Bold,ANSI_CHARSET
serif.bold.1=\u5b8b\u4f53,GB2312_CHARSET
serif.bold.2=WingDings,SYMBOL_CHARSET
serif.bold.3=Symbol,SYMBOL_CHARSET

serif.italic.0=Tahoma Italic,ANSI_CHARSET
serif.italic.1=\u5b8b\u4f53,GB2312_CHARSET
serif.italic.2=WingDings,SYMBOL_CHARSET
serif.italic.3=Symbol,SYMBOL_CHARSET

serif.bolditalic.0=Tahoma Bold Italic,ANSI_CHARSET
serif.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
serif.bolditalic.2=WingDings,SYMBOL_CHARSET
serif.bolditalic.3=Symbol,SYMBOL_CHARSET

#####################################

#serif.plain.0=Times New Roman,ANSI_CHARSET
#serif.plain.1=\u5b8b\u4f53,GB2312_CHARSET
#serif.plain.2=WingDings,SYMBOL_CHARSET
#serif.plain.3=Symbol,SYMBOL_CHARSET

#serif.bold.0=Times New Roman Bold,ANSI_CHARSET
#serif.bold.1=\u5b8b\u4f53,GB2312_CHARSET
#serif.bold.2=WingDings,SYMBOL_CHARSET
#serif.bold.3=Symbol,SYMBOL_CHARSET

#serif.italic.0=Times New Roman Italic,ANSI_CHARSET
#serif.italic.1=\u5b8b\u4f53,GB2312_CHARSET
#serif.italic.2=WingDings,SYMBOL_CHARSET
#serif.italic.3=Symbol,SYMBOL_CHARSET

#serif.bolditalic.0=Times New Roman Bold Italic,ANSI_CHARSET
#serif.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
#serif.bolditalic.2=WingDings,SYMBOL_CHARSET
#serif.bolditalic.3=Symbol,SYMBOL_CHARSET

#############################

sansserif.plain.0=Tahoma,ANSI_CHARSET
sansserif.plain.1=\u5b8b\u4f53,GB2312_CHARSET
sansserif.plain.2=WingDings,SYMBOL_CHARSET
sansserif.plain.3=Symbol,SYMBOL_CHARSET

sansserif.bold.0=Tahoma Bold,ANSI_CHARSET
sansserif.bold.1=\u5b8b\u4f53,GB2312_CHARSET
sansserif.bold.2=WingDings,SYMBOL_CHARSET
sansserif.bold.3=Symbol,SYMBOL_CHARSET

sansserif.italic.0=Tahoma Italic,ANSI_CHARSET
sansserif.italic.1=\u5b8b\u4f53,GB2312_CHARSET
sansserif.italic.2=WingDings,SYMBOL_CHARSET
sansserif.italic.3=Symbol,SYMBOL_CHARSET

sansserif.bolditalic.0=Tahoma Bold Italic,ANSI_CHARSET
sansserif.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
sansserif.bolditalic.2=WingDings,SYMBOL_CHARSET
sansserif.bolditalic.3=Symbol,SYMBOL_CHARSET

monospaced.plain.0=Courier New,GB2312_CHARSET
monospaced.plain.1=\u5b8b\u4f53,GB2312_CHARSET
monospaced.plain.2=WingDings,SYMBOL_CHARSET
monospaced.plain.3=Symbol,SYMBOL_CHARSET

monospaced.bold.0=Courier New Bold,GB2312_CHARSET
monospaced.bold.1=\u5b8b\u4f53,GB2312_CHARSET
monospaced.bold.2=WingDings,SYMBOL_CHARSET
monospaced.bold.3=Symbol,SYMBOL_CHARSET

monospaced.italic.0=Courier New Italic,GB2312_CHARSET
monospaced.italic.1=\u5b8b\u4f53,GB2312_CHARSET
monospaced.italic.2=WingDings,SYMBOL_CHARSET
monospaced.italic.3=Symbol,SYMBOL_CHARSET

monospaced.bolditalic.0=Courier New Bold Italic,GB2312_CHARSET
monospaced.bolditalic.1=\u5b8b\u4f53,GB2312_CHARSET
monospaced.bolditalic.2=WingDings,SYMBOL_CHARSET
monospaced.bolditalic.3=Symbol,SYMBOL_CHARSET

# name aliases
#alias.timesroman=serif
alias.helvetica=sansserif
alias.courier=monospaced

# Font File Names
#
filename.\u5b8b\u4f53=SIMSUN.TTC

filename.Tahoma=tahoma.ttf
filename.Tahoma_Italic=tahoma.ttf
filename.Tahoma_Bold=tahombd.ttf
filename.Tahoma_Bold_Italic=tahomabd.ttf

filename.Arial=ARIAL.TTF
filename.Arial_Bold=ARIALBD.TTF
filename.Arial_Italic=ARIALI.TTF
filename.Arial_Bold_Italic=ARIALBI.TTF

filename.Courier_New=COUR.TTF
filename.Courier_New_Bold=COURBD.TTF
filename.Courier_New_Italic=COURI.TTF
filename.Courier_New_Bold_Italic=COURBI.TTF

filename.Times_New_Roman=TIMES.TTF
filename.Times_New_Roman_Bold=TIMESBD.TTF
filename.Times_New_Roman_Italic=TIMESI.TTF
filename.Times_New_Roman_Bold_Italic=TIMESBI.TTF

filename.WingDings=WINGDING.TTF
filename.Symbol=SYMBOL.TTF

# Missing Glyph Character
#
default.char=2751

# Component Font Character Encodings
#
fontcharset.dialog.1=sun.io.CharToByteGBK
fontcharset.dialog.2=sun.awt.windows.CharToByteWingDings
fontcharset.dialog.3=sun.awt.CharToByteSymbol

fontcharset.dialoginput.1=sun.io.CharToByteGBK
fontcharset.dialoginput.2=sun.awt.windows.CharToByteWingDings
fontcharset.dialoginput.3=sun.awt.CharToByteSymbol

fontcharset.serif.1=sun.io.CharToByteGBK
fontcharset.serif.2=sun.awt.windows.CharToByteWingDings
fontcharset.serif.3=sun.awt.CharToByteSymbol

fontcharset.sansserif.1=sun.io.CharToByteGBK
fontcharset.sansserif.2=sun.awt.windows.CharToByteWingDings
fontcharset.sansserif.3=sun.awt.CharToByteSymbol

fontcharset.monospaced.0=sun.io.CharToByteGBK
fontcharset.monospaced.1=sun.io.CharToByteGBK
fontcharset.monospaced.2=sun.awt.windows.CharToByteWingDings
fontcharset.monospaced.3=sun.awt.CharToByteSymbol

# Exclusion Ranges
#
#exclusion.dialog.0=0100-20ab,20ad-f8ff
#exclusion.dialoginput.0=0100-20ab,20ad-f8ff
#exclusion.serif.0=0100-20ab,20ad-f8ff
#exclusion.sansserif.0=0100-20ab,20ad-f8ff
#exclusion.monospaced.0=0100-20ab,20ad-f8ff

exclusion.Tahoma.plain.0=00a0-f8ff
exclusion.Tahoma.italic.0=00a0-f8ff
exclusion.Tahoma.bold.0=00a0-f8ff
exclusion.Tahoma.bolditalic.0=00a0-f8ff

exclusion.dialog.plain.0=00a0-f8ff
exclusion.dialog.italic.0=00a0-f8ff
exclusion.dialog.bold.0=00a0-f8ff
exclusion.dialog.bolditalic.0=00a0-f8ff

exclusion.dialoginput.plain.0=00a0-f8ff
exclusion.dialoginput.italic.0=00a0-f8ff
exclusion.dialoginput.bold.0=00a0-f8ff
exclusion.dialoginput.bolditalic.0=00a0-f8ff

exclusion.serif.plain.0=00a0-f8ff
exclusion.serif.italic.0=00a0-f8ff
exclusion.serif.bold.0=00a0-f8ff
exclusion.serif.bolditalic.0=00a0-f8ff

exclusion.sansserif.plain.0=00a0-f8ff
exclusion.sansserif.italic.0=00a0-f8ff
exclusion.sansserif.bold.0=00a0-f8ff
exclusion.sansserif.bolditalic.0=00a0-f8ff

exclusion.monospaced.plain.0=00a0-f8ff
exclusion.monospaced.italic.0=00a0-f8ff
exclusion.monospaced.bold.0=00a0-f8ff
exclusion.monospaced.bolditalic.0=00a0-f8ff

# Text Input Character Set
#
inputtextcharset=GB2312_CHARSET

2. JBuilder 2005其实也有这种字体的问题。比如本来么有问题的文件，如果在Jbuilder里面保存一下，结果就会出现异常的编码字符出现。解决的办法也是将上面的font.properties.zh文件替换成如上的内容。同时，在Project->Project Properties->General->Encoding中选择”GB2312”的编码，然后关闭工程，重新打开即可。

JBUILDER的光标定位不准确的最佳解决方案是：

进入%JBUILDER_HOME%/bin目录下，用写字板编辑jbuilder.config，把下面的配置加进去：

vmparam -Dprimetime.editor.useVariableWidthFont=true

呆呆向前冲的blog 2005-06-30 16:19 发表评论

The collection Framework 全览

呆呆向前冲的blog — Wed, 29 Jun 2005 06:23:00 GMT

呆呆向前冲的blog 2005-06-29 14:23 发表评论

《Effective Java》笔记－15,16

呆呆向前冲的blog — Mon, 20 Jun 2005 08:30:00 GMT

第15条：要么专门为继承而设计，并给出文档说明，要么禁止继承

     » 为了允许继承，一个类必须遵守如下约定：
     » 构造函数一定不能调用可被改写的方法。

第16条：接口优于抽象类

     » 接口通常是定义具有多个实现的类型的最佳途径。
     » 例外情形是当演化的容易性被灵活性和功能更为重要的时候。这时应该使用抽象类来定义类型。
     » 如果导出了一个重要接口，应该考虑同时提供一个骨架实现类(skeletal implementation class）
     » 尽可能谨慎设计所有的公有接口，并编写多个实现来测试它们。

第17条：接口是用于定义类型的

     » 接口应该这是被用来定义类型的
     » 常量接口模式是对接口的不良使用
           如果需要导出常量，应该使用类型安全枚举类，如

                            public class PhysicalConstants{

                                    private PhysicalConstants(){}//注意：构造函数应该是私有的，避免子类化
                                    public static final AVOCADROS_NUMBER = .....；//注意，常量类型应该是static final的
                              }
第18条：优先考虑静态成员类

      » 嵌套类有四种：静态成员类，非静态成员类，匿名类，局部类
      » 非静态成员类的一种通用用法：允许外部类的一个实例被看做另一个不相关的类的实例。
         例如，诸如Set和List这样的集合接口的实现往往使用非静态成员类来实现他们的迭代器
                   public class MySet extends AbstractSet {
                             public Iterator iterator(){
                                    return new MyIterator();
                             }
                             public class MyIterator implements Iterator{
                                    ................
                              }
                   }
      » 如果声明的成员类不要求访问外围实例，那么使用static修饰符使它成为静态成员类。

呆呆向前冲的blog 2005-06-20 16:30 发表评论

xml笔记

呆呆向前冲的blog — Mon, 20 Jun 2005 04:03:00 GMT

一．XML整体结构

1．XML文件的基本构成：XML声明、处理指示、XML元素

2．其他一些逻辑要素：

注释:

CDATA:

]]>

3．CDATA：标识字符数据

二．XML文件物理结构

1．实体

XML文件归根结底是由一组实体组成。

（1）实体的种类：一般实体和参数实体

一般实体：实体名 “实体内容”>

实体名 SYSTEM “外部文件链接”>

参数实体：实体名 “实体内容”>

（3）实体的两种使用方式：实体声明和实体引用

实体声明：

文件根元素名 [
实体声明部分
]>
<文件根元素名>
具体数据内容
文件根元素名>

实体引用：引用一个在实体声明中已经声明过的实体

一般实体的引用－&实体名;

参数实体的引用－%实体名;

完整的例子：

联系人列表 [
公司地址 “北京市五街1234号”>
公司地址 “上海南京路9876号”〉
]>

<联系人列表>
    <联系人>
        <姓名>张三姓名>
        <公司>>A公司公司>>
        <地址>&A公司地址地址>
    联系人>
    <联系人>
        <姓名gt;李四姓名>
        <公司>B公司公司>
        <地址>&B公司地址〈/地址〉
    联系人>
    <联系人>
        <姓名>王五姓名>>
        <公司>B公司公司>
        <地址>&B公司地址〈/地址〉
    联系人>
联系人列表>

XML的精髓：基于信息描述，能够体现数据信息之间的逻辑。

XML大小写敏感

呆呆向前冲的blog 2005-06-20 12:03 发表评论