基于JBoss的J2EE应用

本文介绍的内容，大体上都适合JBoss各个版本。

下载完JBoss 3.2.1后，解压到一个没有空格的目录路径下面就可以运行JBoss，所以很方便，但前提是目标机器安装了Java 2 Standard Edition。一切就绪后，开始我们的旅程。

（假设JBoss 3.2.1安装在：C:/jboss-3.2.1_tomcat-4.1.24，本使用default配置）

　　一，相关配置文件的设置
为开发J2EE应用，操作数据库成了必不可少的内容；调节日志输出的详细程度成了调试J2EE应用的关键；EJB应用的调优过程是J2EE应用的核心。等等，这些内容都是我们需要知道的。

　　（1）数据源的配置：

在JBoss 3.2.1中，配置数据源的步骤很简单，JBoss 3.2.1本身带了主流数据库的配置实例，于目录下：C:/jboss-3.2.1_tomcat-4.1.24/docs/examples/jca。 具体使用那个配置文件取决于目标用户的数据库。如果是SQL Server 2000，则需要使用mssql-ds.xml文件（支持本地事务）或者mssql-xa-ds.xml文件（支持全局事务）；如果是Oracle 9i数据库，则需要使用oracle-ds.xml文件或者oracle-xa-ds.xml文件。等等。这里以SQL Server 2000为例。

首先将mssql-ds.xml文件拷贝到目录：C:/jboss-3.2.1_tomcat-4.1.24/server/default/deploy下。然后打开文件，并作如下修改：

　　< datasources >
　　　< local-tx-datasource >
　　　< jndi-name >VSSDB< /jndi-name >
　　　< connection-url >jdbc:microsoft:sqlserver://125.16.45.158:1433;DatabaseName=DDD< /connection-url >
　　　< driver-class >com.microsoft.jdbc.sqlserver.SQLServerDriver< /driver-class >
　　　< user-name >sa< /user-name >
　　　< password >sa< /password >
　　　< min-pool-size >50< /min-pool-size >
　　　< max-pool-size >200< /max-pool-size >
　　　< /local-tx-datasource >
　　< /datasources >

如果目标J2EE应用只需要本地事务，则上述过程已经完成了Datasource的配置，同时这个配置将用于JDBC以及EJB通过JNDI使用。如果要 实现EJB使用Datasource，则还需要修改位于目录：C:/jboss-3.2.1_tomcat-4.1.24/server/default /conf下的standardjbosscmp-jdbc.xml文件。比如，

< jbosscmp-jdbc >

< defaults >
< datasource >java:/VSSDB1< /datasource >
< datasource-mapping >MS SQLSERVER2000< /datasource-mapping >
< create-table >true< /create-table >
　　　< remove-table >false< /remove-table >
< read-only >false< /read-only >
< time-out >300< /time-out >
< pk-constraint >true< /pk-constraint >
< fk-constraint >false< /fk-constraint >
　　　。。。。。。。。

其中，< datasource >java:/VSSDB< /datasource >中的VSSDB就是mssql-ds.xml配置的数据源；而“java:/”前缀表明该命名空间只是对JBoss本身可见，即运行于JBoss 外的应用是不能够使用这里定义的数据源，这一点希望读者注意。

其次，< datasource-mapping >MS SQLSERVER2000< /datasource-mapping >中的MS SQLSERVER2000可以在该文件的其他地方找到。（如果是其他数据库，情况都是类似的，希望读者加以思考！）

　　（2）日志的输出详细程度配置：

由于JBoss 3.2.1开发采用了Log4j管理其日志信息（严格地讲，它扩展了Log4j），因此了解Log4j的机理，有助于理解JBoss 3.2.1管理日志的方式。

JBoss 3.2.1采用JMX架构的同时，且以.xml文件类型为配置文件，因此可以找到位于目录：C:/jboss-3.2.1_tomcat-4.1.24/ server/default/conf下的log4j.xml文件。比如，其中一段配置示例如下：

　　< appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender" >
　　　< param name="Target" value="System.out"/ >
　　　< param name="Threshold" value="INFO"/ >
　　　< layout class="org.apache.log4j.PatternLayout" >
　　　　< !-- The default pattern: Date Priority [Category] Message/n -- >
　　　　< param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/ >
　　　< /layout >
　　< /appender >

比如，为了调节JBoss 3.2.1控制台日志输出的详细程度（调整为DEBUG级别），我们需要修改value=”INFO”，将INFO改为DEBUG。

如果目标读者在开发Entity Beans，可以调节位于与log4j.xml文件同一目录下的standardjboss.xml文件（该文件主要是提供修改EJB相关的调试、运行、 调优、部署参数）。如果目标读者Entity Beans采用的< container-name >为Standard CMP 2.x EntityBean，则将其中的< call-logging >属性的取值改为true。

　　< container-configuration >
　　< container-name >Standard CMP 2.x EntityBean< /container-name >
　　< call-logging >false< /call-logging >
　　< invoker-proxy-binding-name >entity-rmi-invoker< /invoker-proxy-binding-name >
　　< sync-on-commit-only >false< /sync-on-commit-only >
　　。。。。。。。。。

完成上述两步后，读者在调试Entity Beans时通过控制台，可以看到Entity Beans发出的JDBC调用细节。

　　（3）Tomcat容器相关参数的配置：

如果目标读者使用JBoss 3.2.1与Tomcat 4.1.24的集成版本，则可以通过调节分别位于目录：C:/jboss-3.2.1_tomcat-4.1.24/server/default/ deploy/jbossweb-tomcat.sar下的web.xml和目录：C:/jboss-3.2.1_tomcat-4.1.24/ server/default/deploy/jbossweb-tomcat.sar/META-INF下的jboss-service.xml文件来 达到目标读者特定需求。

比如，如果想将HTTP服务端口改为80，则可以修改jboss-service.xml文件；如果想使目标J2EE应用处理更多的文件类型，可以修改web.xml文件。

　　（4）相关类库的放置：

如果您的应用涉及到第三方类库，比如JDBC Driver，则可以将这些JDBC Driver存放到目录下：C:/jboss-3.2.1_tomcat-4.1.24/server/default/lib。注意，不是目录：C:/ jboss-3.2.1_tomcat-4.1.24/lib下。

如果是与目标J2EE应用相关，则可以存放到目标.war（或者.ear）里面，或者xxx.war目录中的WEB-INFO/lib下。无论那种情形，都需要遵循J2EE规范。

当然，JBoss 3.2.1的配置文件有很多，比如提供邮件服务的mail-service.xml文件，等等。在这里只是给读者一些信息，如果您有相关问题，都可以试着本文介绍的一些内容解决您的问题。谢谢。

　　二，开发EJB应用

如果开发EJB应用，建议采用JBoss作为开发服务器，因为开发、调试、部署速度快。如果采用其他商用服务器，由于实现机理的不同，其编译的速度很慢。

如果采用Entity Beans技术，则您需要知道这么几点。第一，您目标系统的数据源有多少个操作入口，即是否存在Entity Beans之外的方式来操作数据库。如果有，则需要调节相应< container-name >的< commit-option >提交策略以及< locking-policy >策略。

比如，JBoss 3.2.1采用的< commit-option >方式有4种：A、B、C、D。当然，如果除了Entity Beans访问数据库外，别无它出，采用A是很理智的。如果有，则需要取决于具体的情况使用< commit-option >方式。同时，< commit-option >方式的选择与< locking-policy >策略有关系。

能够采用< read-only >的Entity Beans或Entity Beans Methods，则尽量采用，这样会减少或消除死锁发生的可能性。

尽量采用1:n的关系来操作n方的数据表结构，这样能够提高EJB Container的效率。

其中，本文重点给出EJB事务处理方面的探讨。

一般情况下，J2EE应用服务器支持JDBC事务、JTA事务、容器管理事务。同时，最好不要在程序中同时使用上述三种事务类型，比如在JTA事务中嵌套 JDBC事务；第二方面，事务要在尽可能短的时间内完成，不要在不同方法中实现事务的使用。比如，下面给出了回滚JDBC事务的代码示例：

　　public void processT(String orders) {
　　　Context initCtx = new InitialContext();
　　　javax.sql.DataSource ds = javax.sql.DataSource)initCtx.lookup("java:comp/env/jdbc/OrdersDB");
　　　java.sql.Connection conn = ds.getConnection();
　　　try{
　　　　conn.setAutoCommit( false ); // 更改JDBC事务的默认提交方式
　　　　orderNo = createOrder( orders );
　　　　updateOrderStatus(orderNo, "orders created");
　　　　conn.commit(); // 提交JDBC事务
　　　}catch( Exception e ){
　　　　try{
　　　　　conn.rollback(); // 回滚sJDBC事务
　　　　　throw new EJBException("事务回滚：" + e.getMessage());
　　　　}catch( SQLException sqle ){
　　　　　throw new EJBException("出现SQL操作错误：" + sqle.getMessage());
　　　　}
　　　}
　　}

　　(修改自，Transactions in J2EE(RedBooks).pdf中的一段Bean管理的JDBC事务)

　　下面给出了JTA事务代码示例：

　　public void processOrder(String orderMessage) {
　　　UserTransaction transaction = mySessionContext.getUserTransaction();// 获得JTA事务
　　　try{
　　　　transaction.begin(); // 开始JTA事务
　　　　orderNo = sendOrder(orderMessage);
　　　　updateOrderStatus(orderNo, "order sent");
　　　　transaction.commit(); // 提交JTA事务
　　　　}catch(Exception e){
　　　　　try{
　　　　　　transaction.rollback();// 回滚JTA事务
　　　　　}catch(SystemException se){
　　　　　　se.printStackTrace();
　　　　　}
　　　　throw new EJBException("事务回滚：" + e.getMessage());
　　　}
　　}

　　(修改自，Transactions in J2EE(RedBooks).pdf中的一段Bean管理的JTA事务)

同时，如果Session Bean采用JTA管理事务，一定不要通过JNDI获取JTA事务，否则结果不堪设想；而是采用类似，“mySessionContext.getUserTransaction()”的方法获取。

最后，可以使用容器管理事务（CMT）。在使用CMT过程中，如果声明让容器完成事务回滚，则目标EJB应用必须抛出系统级异常，否则容器是不会满足事务 的ACID。在包javax.ejb的异常类中，除了NoSuchEntityException和EJBException属于系统级异常外，其他的异 常全部是应用级异常。

上述3点内容，值得读者注意。可能有些读者在使用EJB CMT过程中，总是会遇到自己已经将事务声明为“Required”，但就是不能够保证事务的ACID。因此，希望读者注意J2EE应用中事务使用的不同 方式。详细情况，可以参考J2EE Tutorial一书中的事务处理章节。

　　另外，

　　1) 在开发Entity Beans过程中，能够使用CMP的地方尽量不要采用BMP的方式。如果拟采用BMP的方式，还不如采用Session Bean + JDBC，其中可以通过JTA控制事务（如果性能问题不是很重要的话）。
　　2) 能够通过容器实现的事务（即，通过声明）的地方尽量采用，提高开发效率，使得您可以更加专注于业务逻辑本身。
　　3)尽量采用J2EE规范采用的各项技术。如果目标系统需要移植，但使用了很多与JBoss特有的技术，其移植工作则很麻烦。

　　三，开发Web应用

一般情况下，开发Web应用最好采用一些Thirty-Part软件或者Framework。比如，Struts、Log4j、webMethods等等。其优势显而易见。

就目前而言，Struts的应用基本上成为了开发Web应用的标准。即将推出来的JSF很好的实现了与Struts的补充和集成。同时，JSF也将给快速开发JSP Web前端应用带来革命。另外，Struts也恰恰促进了JSF的发展。

开发JBoss 3.2.1下的Web应用的过程和其他应用服务器下都差不多。同时，JBuilder 8、9都已经支持Struts 1.1。