例：
在当前Windows系统下装了一个VMware工具，在这个VMware下装了一个Linux,名字为Centos46，Linux虚拟机的IP地址是：192.168.2.101。
需求:在Windows这边通过IE浏览器来访问Linux端Oracle的OEM。
首先，进入Oracle用户，看一下控制台启动没有：
emctl status dbconsole
如果没启动
emctl start dbconsole
看看端口信息：
cat $ORACLE_HOME/install/portlist.ini
最后就可以访问了。http://192.168.2.101:1158/em/
注：必须用IP，用计算机名不行，比如Linux的计算机名是Centos46，这个在Windows端不认。
————————————
解决oracle10g安装后的中文显示乱码
1. 改变$ORACLE_HOME/jdk目录下的jre的默认字体
cd $ORACLE_HOME/jdk/jre/lib/
ls font*zh_CN*
font.properties是默认使用的字体
还可以看到font.properties.zh_CN.Redhat8.0和其它的字体
cp font.properties font.properties.bak
cp font.properties.zh_CN.Redhat8.0 font.properties
2. 改变$ORACLE_HOME/jre下的默认字体
cd $ORACLE_HOME/jre/1.4.2/lib/
ls font*zh_CN*
font.properties是默认使用的字体
还可以看到font.properties.zh_CN.Redhat8.0和其它的字体
cp font.properties font.properties.bak
cp font.properties.zh_CN.Redhat8.0 font.properties
3.删除Cache下的gif文件(em页面中用到),注意不要删错目录
cd $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/cabo/images/cache/zhs/
ls *.gif
rm -f *.gif
4. 重新启动EM服务
cd $ORACLE_HOME/bin/
./emctl stop dbconsole
./emctl start dbconsole
好可以进入em web页面看看是否中文不再是 "□□"字样的乱码了
PMD 包含 16 个规则集，涵盖了 Java 的各种常见问题，其中一些规则要比其他规则更有争议：
基本（rulesets/basic.xml）—— 规则的一个基本合集，可能大多数开发人员都不认同它： catch 块不该为空，无论何时重写 equals()，都要重写 hashCode()，等等。
命名（rulesets/naming.xml）—— 对标准 Java 命令规范的测试：变量名称不应太短；方法名称不应过长；类名称应当以小写字母开头；方法和字段名应当以小写字母开头，等等。
未使用的代码（rulesets/unusedcode.xml）—— 查找从未使用的私有字段和本地变量、执行不到的语句、从未调用的私有方法，等等。
设计（rulesets/design.xml）—— 检查各种设计良好的原则，例如： switch 语句应当有 default 块，应当避免深度嵌套的 if 块，不应当给参数重新赋值，不应该对 double 值进行相等比较。
导入语句（rulesets/imports.xml）—— 检查 import 语句的问题，比如同一个类被导入两次或者被导入 java.lang 的类中。
JUnit 测试（rulesets/junit.xml）—— 查找测试用例和测试方法的特定问题，例如方法名称的正确拼写，以及 suite() 方法是不是 static 和 public。
字符串（rulesets/string.xml）—— 找出处理字符串时遇到的常见问题，例如重复的字符串标量，调用 String 构造函数，对 String 变量调用 toString() 方法。
括号（rulesets/braces.xml）—— 检查 for、 if、 while 和 else 语句是否使用了括号。
代码尺寸（rulesets/codesize.xml）—— 测试过长的方法、有太多方法的类以及重构方面的类似问题。
Javabean（rulesets/javabeans.xml）—— 查看 JavaBean 组件是否违反 JavaBean 编码规范，比如没有序列化的 bean 类。
终结函数（finalizer）—— 因为在Java语言中，finalize()方法不是那么普遍（我上次编写这个代码也经是好多年前的事了），所以它们的使用规则虽然很详细，但是人们对它们相对不是很熟悉。这类检查查找 finalize() 方法的各种问题，例如空的终结函数，调用其他方法的 finalize() 方法，对 finalize() 的显式调用，等等。
克隆（rulesets/clone.xml）—— 用于 clone() 方法的新规则。凡是重写 clone() 方法的类都必须实现Cloneable，clone()方法应该调用super.clone()，而 clone()方法应该声明抛出 CloneNotSupportedException 异常，即使实际上没有抛出异常，也要如此。
耦合（rulesets/coupling.xml）—— 查找类之间过度耦合的迹象，比如导入内容太多；在超类型或接口就已经够用的时候使用子类的类型；类中的字段、变量和返回类型过多等。
严格的异常（rulesets/strictexception.xml）—— 针对异常的测试：不应该声明该方法而抛出 java.lang.Exception异常，不应当将异常用于流控制，不应该捕获 Throwable，等等。
有争议的（rulesets/controversial.xml）—— PMD 的有些规则是有能力的Java程序员可以接受的。但还是有一些争议。这个规则集包含一些更有问题的检验，其中包括把null赋值给变量、方法中有多个返回点，以及从 sun 包导入等。
日志（rulesets/logging-java.xml）—— 查找 java.util.logging.Logger 的不当使用，包括非终状态（nonfinal）、非静态的记录器，以及在一个类中有多个记录器。
1，查看当前过程和函数的对象名，创建时间和状态。
select object_name,created,status from user_objects where object_type in ('PROCEDURE','FUNCTION');
2，列出子程序源代码。
select text from user_source where name = 'RAISE_SALARY';
3，列出子程序编译错误。
1）使用SHOW ERRORS命令查错:
show errors procedure raise_salary
2）使用数据字典视图USER_ERRORS确定错误原因和位置：
select line ||'/'||position as "LINE/COL",text error from user_errors where name = 'RAISE_SALARY';
4，列出对象依赖关系。
1）使用user_dependencies确定直接依赖关系。
select name,type from user_dependencies where referenced_name = 'EMP';
2）使用工具视图DEPTREE和IDEPTREE确定直接依赖和间接依赖关系。
运行系统SQL脚本。
SQL>@%oracle_home%\rdbms\admin\utldtree
SQL>exec deptree_fill('TABLE','SCOTT','EMP')
SQL>select nested_level,name,type from deptree;
5，从新编译子程序。
当修改了被引用对象的结构时，就会将相关依赖对象转变为无效。
SQL> alter table emp add remark varchar2(100);
SQL> select object_name,object_type from user_objects where status = 'INVALID';
为了避免子程序的运行错误，因该重新编译这些存储对象。
SQL> ALTER PROCEDURE add_employee COMPILE;
SQL> ALTER VIEW dept10 COMPILE;
SQL> ALTER FUNCTION get_info COMPILE;
/**Action类
Struts1要求Action类继承一个抽象类，Struts1使用抽象类编程而不是接口
Struts2可以实现Action接口也可以不实现，Struts2提供一个ActionSuport基类去实现常用接口。Action接口不是必须的，任何有execute的标识的POJO都有可能成为struts2的Action的对象
/**线程模式
Struts1的Action是单例模式并且是线程安全的，仅有Action一个实例来处理所有请求。单策略模式限制了Struts1 Action能做的事。比且在开发时要注意Action资源必须是线程安全比且是同步的。
Struts2的Action对象为每个请求产生一个实例，因此没有线程安全问题。
/**Servlet依赖
Struts1 Action依赖与Servlet API，因为当一个Action被调用时HttpServletRequest和HttpServletResponse被传递给execute方法。
Struts2 Action不依赖与容器，允许Action脱离容器被单独测试。如果需要，struts2依然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServletRequest和HttpServletResponse的必要性。
/**可测性：
测试Struts1 Action的一个主要问题是execute方法暴漏了Servlet API（这使得测试要依赖于容器）。一个第三方扩展--Struts TestCase--提供了一套Struts1的模拟对象（来进行测试）
struts2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。
/**捕获输入：
struts1使用ActionForm对象捕获输入。所有ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的基类不或输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述（创建）已经存在的JavaBean（仍然会导致有沉余的JavaBean）。
Struts2直接使用Acrtion属性作为输入属性，消除了对第二个输入对象的请求。输入属性可能是有自己（子）属性的Rich对象类型。Action属性能过通过web页面上的Taglibs访问。struts2也支持ActionForm模式。Richard对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven特性简化了Taglib对POJO输入对象的引用。
/**表达式语言
Struts1整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很脆弱。
Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言--“object graph Notation Language”（OGNL）
/**绑定值到页面（view）
Struts1使用标准JSP机制吧对象绑定到页面中来访问。
struts2使用ValueStack技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重同页面（view）
/**类型转换
Struts1 ActionForm属性通常都是String类型。struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。
struts2 使用OGNL进行类型转换，提供基本和常用对象的转换器。
/**效验
Struts1支持在ActionForm的validate方法中手动效验，或者通过Commons Validator的扩展来效验。同一个类可以有不同的效验内容，但不能效验子对象。
Struts2支持通过validate方法和XWork效验框架进行效验。XWork效验框架使用为属性类类型定义的效验和内容效验，来支持Chain效验子属性。
/**Action执行的控制
Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。
struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不能的生命周期。堆栈能够根据需要和不同的Action一起使用。
