Java同步文件到Jboss虚拟目录

Session Bean除了可以使用注释来发布外，也可以使用相应的配置文件来发布。在这种情况下，就不需要在接口和Session Bean中使用注释了。在JBoss中需要两个文件对Session bean进行配置。这两个文件是ejb-jar.xml和jboss.xml.这两个文件应该META-INF目录中，该目录应该放在jar文件的根目录。ejb-jar.xml文件负责配置session bean，下面是一个典型的配置代码：

<?xml version="1.0" encoding="ASCII"?> <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0">   <display-name>MyEJB</display-name>      <enterprise-beans>       <session>          <ejb-name>Greeter</ejb-name>          <business-local>service.GreeterBeanLocal</business-local>          <business-remote>service.GreeterBeanRemote</business-remote>          <ejb-class>service.GreeterBean</ejb-class>          <session-type>Stateless</session-type>          <transaction-type>Container</transaction-type>       </session>    </enterprise-beans> </ejb-jar>

    其中<ejb-name>元素就是一个表示，表示当前配置的session bean的名称。<business-local>和<bussiness-remote>分别用来指定本地接口和远程接口。<ejb-class>用来指定session bean的java类

    jboss.xml文件主要用来指定jndi，如下面的代码所示：

<?xml version="1.0"?>   <jboss xmlns:xs="http://www.jboss.org/j2ee/schema"        xs:schemaLocation="http://www.jboss.org/j2ee/schema jboss_5_0.xsd"              version="5.0">     <enterprise-beans>       <session>          <ejb-name>Greeter</ejb-name>          <jndi-name>mygreeter</jndi-name>          <local-jndi-name>mygreeter_local</local-jndi-name>       </session>    </enterprise-beans> </jboss>

    上面的代码中的<ejb-name>元素的值和要ejb-jar.xml中的<ejb-name>元素的值相同。<jndi-name>用来指定远程的jndi名称。<local-jndi-name>用来指定本地jndi的名称。如果访问远程的session bean，可以使用下面代码：

Properties prop = new Properties();   InitialContext ctx = new InitialContext();   System.out.println(((service.Greeter)ctx.lookup("mygreeter")).greet("bill"));

    从上面代码可看出，lookup方法通过“mygreeter”来查找服务端的session bean.

• JBoss 订阅（JBoss Subscription）－包括缺陷修正、问题支持以及开发人员协助（例如进行配置和性能优化），此外还包括补偿以及访问 JBoss ON 和客户支持网站。
• 培训服务－包括在全球主要城市提供的公共培训课程和在企业办公地点提供的专门培训课程。
• 咨询－通常由知识渊博的 JBoss 咨询人员提供的短期（3~5天）服务。

• JBoss 应用服务器（JBoss AS）是目前市场上使用最广泛的 Java 应用服务器，它具有预计在 J2EE 1.4 认证平台中推出的所有功能。JBoss 应用服务器建立在以即插即用方式提供所有 J2EE 1.4 服务（包括实现集群、缓存和持久性的 EJB、JSP/Servlets 和 Web服务以及扩展的企业服务）的SOA 微核之上。此外，利用 JBoss 应用服务器，您还可以自由选择开发模式：J2EE1.4 标准方法以及大大简化的 EJB 3.0 模式。最新的 EJB 3.0 编程模式允许使用简单的 Java 注解向标准的 Java 对象应用企业服务和行为－不再需要大量的样板文件代码（boilerplate code）和冗长的 XML 描述符。
• Hibernate 是使用最广泛的适用于 Java 环境的对象关系映射（ORM）解决方案，它赋予了企业将对象模型的数据表示法映射到关系型数据模型及相关数据库模式的能力，可以直接解决 ORM 的复杂性问题。Hibernate 的目标是：消除开发人员需要使用 SQL 和 JDBC 手动处理数据的需求，将他们与通用数据持久性相关的编程工作量减少 95%。
  若欲了解更多Hibernate信息，请点击这里。
• Apache Tomcat 是使用最广泛的 JSP/Servlet Web 应用容器，是 J2EE 1.4 JSP/ Servlet 的一个参考实施方案。Tomcat 可单独用于为 web 应用提供动力，也可作为 JBoss 应用服务器的一部分使用，为可扩展的更复杂企业应用提供动力。Tomcat 的 web 服务器连接器（Web Server Connectors）还使主流的 web 服务器实现了无缝集成，如 Apache HTTP 服务器以及由 JBoss 应用服务器 和 Tomcat 提供动力的企业级 web 应用。
• JBoss Cache 是一个复制的事务缓存，它可以通过处理 HTTP 会话复制来改善应用性能，并可以对某一本地进程或分布式进程中访问频率最高的 Java 对象进行管理。通过对检索或创建成本都较高的 Java 对象的本地复制（local copies）进行管理，JBoss Cache 大大提高了应用的性能。数据库访问的优化不但降低了网络流量，改善了应用的可扩展性，还提高了应用的性能。
• JBoss Transactions 是一个业内业已证明的产品，可以简化分布式事务的处理过程以及提供符合业内标准的互用性。事务处理可以确保绝对准确完成业务流程，在打造可靠、复杂的业务应用方面发挥着重要的作用。JBoss Transactions 完全采用了 Java 技术，是一个适用于 Java EE 的分布式交易系统实施方案。它符合业内主要标准，在确保业务事务整体性的基础上可以使您的企业高枕无忧。JBoss Transactions 支持 WS-Transactions，因此，无论是您现在使用的 web 服务应用，还是将来采用的 web 服务应用，都可具有最大的互用性。
• JBoss Portal 提供了一个符合标准的环境，可以用其托管某一门户网站的 web 界面，发布内容并对这些内容加以管理以及实现量身定制的客户体验。作为与公司信息交互的唯一途径，企业门户网站（Enterprise Portals）大大简化了信息的访问过程。利用 JBoss Portal，企业具有了将公司员工、合作伙伴和客户与其所需信息联系起来的能力－从而提高了业务效率并降低了成本。此外，由于 JBoss Portal 部署在 JBoss 应用服务器之上，不但访问动态信息非常容易，而且系统的性能和可扩展性也有一定的保障。
• JBoss jBPM 是一个功能强大的工作流和业务配置（orchestration）平台，它可以使完全不同的应用和服务互相协作。JBoss jBPM 将工作流应用的快速开发与一个灵活、可扩展的流程引擎实现了完美组合，因此可以轻松迅速地实施和部署具有互用性的应用。通过提供了一个可以创建、协调和监控业务流程的既灵活又强大的框架，JBoss jBPM 使更改复杂的业务流程变得空前简单，这大大提升了业务的灵活性。
• JBoss Rules 具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则，从而检验是否已编码的规则执行了所需的业务规则。JBoss Rules 还支持各种各样的语言和决策表输入，因此要想通过快速修改业务规则来迎接新的商机变得非常简单。
• JBoss Messaging 是一个将企业级消息传输服务带到大众市场的开源消息传输平台，符合业界标准。由于它支持 Java EE Java Message Service (JMS) 规范，因此，利用这一平台，可以开发事务驱动的便携式消息应用。JBoss Messaging 采用了一个高性能的消息传输内核，在设计上可以同时满足简单和复杂的异步消息传递需求。凭借其模块化的即插即用式架构，可以轻松将 JBoss Messaging 与其它 JEMS 产品共同使用。
• JBoss Eclipse IDE 使用一系列有助于程序员开发、部署、测试和调试 JEMS 应用的工具对 Eclipse 这一使用最广泛的综合开发环境框架进行了扩展。JBoss Eclipse IDE 提供了各种各样可以快速开发 J2EE 和 EJB3.0 应用以及 Hibernate 和 JBoss jBPM 应用的向导和功能。利用 JBoss Eclipse IDE，开发人员可以简化应用开发过程并用更短的时间提供更大的价值。

1.1.2.1 客户端拦截器

图 1.2. 集群中的客户端拦截 (代理) 体系结构

 http://blog.51cto.com/viewpic.php?refimg=http://xudayu.blog.51cto.com/attachment/200803/200803091205049907109.jpg

1.1.2.2负载平衡系统

。
http://blog.51cto.com/viewpic.php?refimg=http://xudayu.blog.51cto.com/attachment/200803/200803091205050005890.jpg

• 适用于会话 Beans（Session Beans）、消息驱动 Beans（Message Driven Beans）和实体 Beans（Entity Beans）的简化的 EJB API
• Java 注解（Java Annotations）
• 依赖注入（Dependency Injection）
• 可选的回调机制（Optional Callback）
• 实体管理器 API（Entity Manager API）
• 简化的持久性和改善的查询功能
• 具有 EJB 3.0 规范最新功能演示的 JBoss TrailBlazer 指南及演示系统

• 嵌入式的 Apache Tomcat 5 JSP 容器支持业内领先的 2.0/Servlet 2.4 规范
• Tomcat 与其它 JBoss 应用服务器服务的集成大大提高了系统的可靠性、可扩展性和可用性
• 通过 mod_jk 与Apache Web 服务器集成提供了市场上最佳的 Web 服务器、Web 容器以及应用服务器组合。

• 集群、故障切换、负载均衡和分布式部署功能为部署功能强大、可扩展的大型应用提供了方法。主要功能包括：

• 节点自动恢复
• 在整个集群范围内（Cluster-wide）复制 JNDI 上下文
• 适用于 JNDI、RMI 和所有 EJB 类型的故障切换和负载均衡
• 状态会话 bean（Stateful session bean）状态复制
• HTTP 会话复制
• 高可用性 JMS
• JBoss 应用服务器组件的 Farming/分布式部署；在一个节点上部署即可完成对所有节点的部署。

• 嵌入式 JBoss Cache 具有一个面向事务的复制树状结构高速缓冲存储器，因此在 JBoss 应用服务器网格之上可以轻松实现数据集群。JBoss Cache：

• 通过本地访问数据大大提高了性能
• 允许复制会话数据，因此可在网格上提供一个始终可用的高可用性高速缓冲存储器。
• 可以对 POJO 进行精确的复制－业内首创！

• EJB 3.0 Entity Manager 和 Java Persistence API
• 对临时数据、历史数据、区域数据和权限数据（permissioned data）进行虚拟过滤
• 灵活的对象关系映射
• 单一对象到多表映射
• 用手写的 SQL 覆盖生成的 SQL 的能力
• 不需要字节码处理就可以实现透明的持久性
• 可以通过 XDoclet 生成的可读的对象关系映射定义
• 可将数据作为XML和Java对象进行交替表示的XML绑定
• 采用了由事件驱动的设计，确保了可以通过创建和注册自定义事件来审核情况或级联行为语言（cascaded behavior semantics）
• 用类似于 SQL 语言表示的功能强大的面向对象查询语言
• 通过查询进行批量更新和删除
• 超高性能（UHP）

• 有状态和无状态会话 Beans
• BMP（Bean管理的持久性）实体 Beans
• CMP（容器管理的持久性）实体 Beans
• 消息驱动的 beans （MDB）
• 使用 RMI-IIOP 或 JAXRPC 的互用性
• 将无状态会话 beans 和 MDB 作为 Web 服务显示的能力
• 支持通过 Web 服务（Web Services）发送和接收消息
• 基于 EJB 和 JMX 的 web 服务的轻松配置和热部署
• 从外部 CORBA 对象访问 EJB

• EJB 2.1 和 CORBA 对象间的互用性
• 完全支持 CORBA 2.3
• 可移植对象适配器（POA）
• 异步方法调用（AMI）
• 可移植拦截器（Portable interceptor）
• 动态调用接口（DII）、动态框架接口（Dynamic Skeleton Interface）和 DynAny
• 支持内置的命名和目录接口（JNDI）
• 支持两阶段提交事务（two-phase commit）的内置 JTA

• 支持连接的 J2EE 连接器架构（JCA）1.5 规范。
• 支持对任何符合 JCA 规范的资源适配器（包括数据库、传统系统和 JMS 服务器）进行池、事务和安全上下文传播（context propagation）的 JDBC 3.0 规范。
• 支持用可选的服务质量参数（如持久性、有保障传输和事务）在分布式系统中异步传输消息的 JMS 1.1。该规范还支持队列和主题消息形式，并具有支持在集群环境中部署 JMS 应用的高可用性功能。

• 查看用户定义的域和 MBeans
• 获得 Servlets 的管理统计数据、EJB 和部署描述符视图
• 动态绘制数值型 JMX 属性
• 监控 JMX 属性
• 根据特定的阈值接收邮件警告通知
• 记录不同时间下 JMX 属性的快照
• 查看微核，并显示所有注册的和现用的 MBean 服务
• 显示 JNDI 树
• 生成 thread dump
• 对部署扫描器（deployment scanner）进行管理
• 停止 JBoss 应用服务器

• 基于 Eclipse 3 的一流开发环境
• EJB 3.0 项目向导
• 对 JBoss AOP 和开发的全面支持以及方面（aspects）的使用
• 可进行全面的 HQL 查询和浏览结果集的 Hibernate 控制台
• Hibernate XML 映射文件编辑器
• 适用于逆向工程数据库模式（database schema）的 Hibernate 向导
• JBoss jBPM 图形流程设计（graphical process designer）
• 对 JBoss 服务器的全面调试和监控以及对其生命周期的控制
• 档案打包规划（打包的或展开的）的简单配置
• 向 JBoss 应用服务器简单部署打包的和/或展开的档案（exploded archive）
• 几个可以简化 J2EE 开发过程的 J2EE 向导
• 可突出显示句法的 JSP、HTML 和 XML 编辑器
• 对 XDoclet 提供的舒适、复杂的支持
• 将 XDoclet、打包和部署与 Eclipse Job API 实现了集成

• JBoss 订阅（JBoss Subscription）将帮助您解决所有与 JBoss 应用服务器相关的问题，其中包括故障和补丁管理、生产支持以及总体开发和部署协助。JBoss 目前共推出了三种不同级别的支持服务，其中包括在 48 小时内响应的 8*5 支持服务以及在 2 个小时内响应的全天候服务。所有 JBoss 专业支持服务都包含不限制登陆时间或呼叫次数的无限制支持。

• 每个金级（Gold）和白金级（Platinum）JBoss 应用服务器订阅合同都包括对 JBoss Operations Network（JBoss ON）的访问。利用 JBoss ON，您可以更好地了解和控制您的 JEMS 应用，这包括库存、管理、控制和对 JBoss 环境进行监控的主要功能。

• 培训服务包括在全球主要城市提供的公共培训课程和在企业办公地点提供的专门培训课程。目前我们主要提供如下有关 JBoss 应用服务器的培训课程：

• 适用于 Java 开发人员的 JBoss 和 EJB3
• 适用于 Web 开发人员的 JBoss
• 适用于高级 J2EE 开发人员的 JBoss
• 面向管理员的 JBoss
• JBoss 集群

• 咨询服务包括在您需要深入了解产品知识时由训练有素的 JBoss 应用服务器咨询人员提供的现场和远程咨询服务。我们的咨询服务将从源头直接为您提供体贴的服务，这对确保您及时使用 JBoss 应用服务器至关重要。

• JDK 1.4 或更高版本（建议使用1.4.2）
• 在使用 EJB 3.0 时需要使用 JDK 5 或更高版本
• 512 MB RAM
• 100 MB 硬盘空间
• 400 MHz CPU

• EJB 3.0 规范草案
• EJB 2.1
• JSP 2.0 和 Servlets 2.4
• JavaServer Faces
• Java Management Extension (JMX) 1.2
• Java Messaging Service (JMS) 1.1
• Java Transaction API (JTA) 1.0.1B
• CORBA 2.3.1
• JDBC 3.0
• J2EE Connector Architecture (JCA) 1.5
• J2EE Management API 1.0
• J2EE Deployment API 1.1
• Java API for XML Processing (JAXP) 1.2
• Java API for XML based RPC (JAXRPC) 1.1
• SOAP with Attachments API for Java (SAAJ) 1.2
• Java API for XML Registries (JAXR) 1.0
• Web Services 1.1
• Java Naming and Directory Interface (JNDI) 1.2.1
• Java Authentication and Authorization Service (JAAS) 1.0
• JavaBeans Activation Framework (JAF) 1.0
• JavaMail 1.3
• Java Authorization Service Provider Contract for Containers (JACC) 1.0

Trigger是一个抽象类，Quartz提供了两个比较常用的触发器SimpleTrigger和CronTrigger。它们都是Trigger的子类

SimpleTrigger

这是一个简单的触发器，通过它我们可以定义触发的时间，并选择性的设定重复的次数和间隔时间。它有以下常用的属性

CronTrigger

这个触发器的功能非常强大，而且非常灵活，但需要掌握有关的Cron表达式知识

触发器规则表达式配置： 

格式:

[秒] [分] [小时] [日] [月] [周] [年]

格式说明：

 通配符说明：

SimpleJob.java

package com.test.job;

import org.quartz.Job;

import org.quartz.JobExecutionContext;

import org.quartz.JobExecutionException;

public class SimpleJob implements Job{

    public void execute(JobExecutionContext context)

           throws JobExecutionException {

       // your business logic

       // ...

       System.out.println("simpleJob running ....");

    }

}

TestSimpleJob.java

package com.test.job;

import java.text.ParseException;

import org.quartz.CronExpression;

import org.quartz.CronTrigger;

import org.quartz.JobDetail;

import org.quartz.Scheduler;

import org.quartz.SchedulerException;

import org.quartz.SimpleTrigger;

import org.quartz.impl.StdSchedulerFactory;

public class TestSimpleJob {

    public static void main(String[] args){

       try {

           Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();

           String jobName = "simpleJob";

           String groupName = "DEFAULT";

           //删除作业

           if(scheduler.getJobDetail(jobName,groupName) != null){

              scheduler.deleteJob(jobName, groupName);

           }

           //作业的详细信息

           //任务名称，任务组名称，任务实现类

           JobDetail jobDetail = new JobDetail(jobName,groupName,SimpleJob.class);

           //创建简单触发器

           SimpleTrigger simpleTrigger = new SimpleTrigger("simpleTrigger",null);

           simpleTrigger.setRepeatCount(100); // 调用100次

           simpleTrigger.setRepeatInterval(5*1000); //每5秒钟调用一次

           //注册作业

           scheduler.scheduleJob(jobDetail, simpleTrigger);

           CronTrigger cronTrigger = new CronTrigger("cronTrigger",null);

           CronExpression cronExpression = null;

           try {

              cronExpression = new CronExpression("0 0 12 * * ?"); //每天12点运行

              cronTrigger.setCronExpression(cronExpression);

              //注册作业

              scheduler.scheduleJob(jobDetail, cronTrigger);

              if(! scheduler.isShutdown()){

                  scheduler.start();

              }

           } catch (ParseException e) {

              e.printStackTrace();

           }

       } catch (SchedulerException e) {

           e.printStackTrace();

       }

    }

}

Quartz的核心概念 :调度器、触发器、作业 

调度器(Scheduler)

Scheduler负责管理Quartz的运行环境，Quartz它是基于多线程架构的，它启动的时候会初始化一套线程，这套线程会用来执行一些预置的作业。

要创建一个作业并能够被触发调用，必须在Scheduler上面注册一个JobDetail和Trigger。

Scheduler提携了所有Trigger和JobDetail，使它们协调工作。这些Trigger和JobDetail通过自身的name和group属性区分。

       Scheduler 由SchedulerFactory产生，我们可以通过以下方式获取Scheduler的实例：

     //从ServletContext上下文中查找SchedulerFactory

     SchedulerFactory   factory = (SchedulerFactory)

ServletActionContext.getServletContext().getAttribute("org.quartz.impl.StdSchedulerFactory.KEY");

   //获取Scheduler对象

   Scheduler defScheduler = factory.getScheduler();

作业

Job

任务，其实就是一个接口。要创建一个任务，必须得实现这个接口。该接口只有一个execute方法，任务每次被调用的时候都会执行这个execute方法的逻辑。

public class TestJob impletemens org.quartz.Job{

         @Override

         public void execute(JobExecutionContext context) throws JobExecutionException{

                   // you business logic

                   // …

                 System.out.println("########### this is testJob running ############");

     }

}

JobDetail

JobDetail 用来保存我们作业的详细信息。一个JobDetail可以有多个Trigger，但是一个Trigger只能对应一个JobDetail。下面是JobDetail的一些常用的属性和含义

JobDataMap

这是一个给作业提供数据支持的数据结构，使用方法和java.util.Map一样，非常方便。当一个作业被分配给调度器时，JobDataMap实例就随之生成。

Job有一个StatefulJob子接口，代表有状态的任务，该接口是一个没有方法的标签接口，其目的是让Quartz知道任务的类型，以便采用不同的执行方案。无状态任务在执行时拥有自己的JobDataMap拷贝，对JobDataMap的更改不会影响下次的执行。而有状态任务共享共享同一个JobDataMap实例，每次任务执行对JobDataMap所做的更改会保存下来，后面的执行可以看到这个更改，也即每次执行任务后都会对后面的执行发生影响。

正因为这个原因，无状态的Job可以并发执行，而有状态的StatefulJob不能并发执行，这意味着如果前次的StatefulJob还没有执行完毕，下一次的任务将阻塞等待，直到前次任务执行完毕。有状态任务比无状态任务需要考虑更多的因素，程序往往拥有更高的复杂度，因此除非必要，应该尽量使用无状态的Job。

如果Quartz使用了数据库持久化任务调度信息，无状态的JobDataMap仅会在Scheduler注册任务时保持一次，而有状态任务对应的JobDataMap在每次执行任务后都会进行保存。

JobDataMap实例也可以与一个触发器相关联。这种情况下，对于同一作业的不同触发器，我们可以在JobDataMap中添加不同的数据，以便作业在不同时间执行时能够提供更为灵活的数据支持（学校上午放眼保健操录音第一版，下午放第二版）。

不管是有状态还是无状态的任务，在任务执行期间对Trigger的JobDataMap所做的更改都不会进行持久，也即不会对下次的执行产生影响。

Quartz作业存储方式

Quartz提供两种基本作业存储类型。第一种类型叫做RAMJobStore，第二种类型叫做JDBC作业存储。

一、对比

二、配置

1、以下是配置是内存存储

#============================================================================
# Configure RAMJobStore 
#============================================================================
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

2、以下配置是数据库存储

#============================================================================
# Configure JobStore 
#============================================================================

#===========================
#Configure JDBC-JobStoreTX
#===========================
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.dataSource = myDS
org.quartz.jobStore.useProperties = false

#============================
# Configure DataSource
#============================
org.quartz.dataSource.myDS.driver = oracle.jdbc.OracleDriver
org.quartz.dataSource.myDS.URL = jdbc:oracle:thin:@localhost:1521:test
org.quartz.dataSource.myDS.user = user
org.quartz.dataSource.myDS.password = password
org.quartz.dataSource.myDS.maxConnections = 10

Xml代码  

1. <?xml version="1.0" encoding="UTF-8"?>  
2. <datasources>  
3.    <local-tx-datasource>  
4.      <!-- jndi名字 -->  
5.      <jndi-name>MySqlDS</jndi-name>  
6.      <!--URL地址 -->    
7.      <use-java-context>false</use-java-context>  
8.      <connection-url>jdbc:mysql://10.16.175.137:3306/test</connection-url>  
9.      <!-- 驱动 -->    
10.      <driver-class>com.mysql.jdbc.Driver</driver-class>  
11.       <!-- 用户名 -->    
12.      <user-name>root</user-name>  
13.       <!-- 密码 -->    
14.     <password>123456</password>  
15.     <exception-sorter-class-name> org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter </exception-sorter-class-name>    
16.      <metadata>    
17.         <type-mapping>mySQL</type-mapping>    
18.      </metadata>  
19.    </local-tx-datasource>  
20. </datasources>  

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
   <local-tx-datasource>
     <!-- jndi名字 -->
     <jndi-name>MySqlDS</jndi-name>
     <!--URL地址 --> 
     <use-java-context>false</use-java-context>
     <connection-url>jdbc:mysql://10.16.175.137:3306/test</connection-url>
     <!-- 驱动 --> 
     <driver-class>com.mysql.jdbc.Driver</driver-class>
      <!-- 用户名 --> 
     <user-name>root</user-name>
      <!-- 密码 --> 
    <password>123456</password>
    <exception-sorter-class-name> org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter </exception-sorter-class-name> 
     <metadata> 
        <type-mapping>mySQL</type-mapping> 
     </metadata>
   </local-tx-datasource>
</datasources>

看一下这个文件,里面用户名与密码都是以明文方式存储的,这样子对系统的安全而言带来了极大的威协。所以我们要为我们这个明文的密码加一下密,这就是本文的目的.

2.说到密码加密，这里我们用到了JBoss下的一个类org.jboss.resource.security.SedureIdentityLoginModule,看看我们该如何用它来帮我们的密码加密。
先看个配置数据源的例子(mysql-ds.xml)

Xml代码  

1. <?xml version="1.0" encoding="UTF-8"?>  
2. <datasources>  
3. <local-tx-datasource>  
4. <jndi-name>MySqlDS</jndi-name>  
5. <use-java-context>false</use-java-context>  
6. <connection-url>jdbc:mysql://192.168.1.91:3306/atteam</connection-url>  
7. <driver-class>com.mysql.jdbc.Driver</driver-class>  
8.  <!--这里不用写上你的用户名与密码了，我们可以在login-config.xml里做点手脚，就OK了 -->  
9. <security-domain>EncryptDBPassword</security-domain>  
10. <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>  
11. <metadata>  
12. <type-mapping>mySQL</type-mapping>  
13. </metadata>    
14. </local-tx-datasource>  
15. </datasources>  

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>MySqlDS</jndi-name>
<use-java-context>false</use-java-context>
<connection-url>jdbc:mysql://192.168.1.91:3306/atteam</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
 <!--这里不用写上你的用户名与密码了，我们可以在login-config.xml里做点手脚，就OK了 -->
<security-domain>EncryptDBPassword</security-domain>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
<metadata>
<type-mapping>mySQL</type-mapping>
</metadata> 
</local-tx-datasource>
</datasources>

 
接着我们修改server\default\conf\login-config.xml文件,加上下面这一段配置文件

Xml代码  

1. <application-policy name="EncryptDBPassword">  
2. <!--这里的name应该是你在配置数据源时写的security-domain里的字符串-->  
3. <authentication>  
4. <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">  
5. <!-- 数据库的用户名 -->  
6. <module-option name="username">test</module-option>    
7. <!--数据库的密码，不过是加密过的了 -->  
8. <module-option name="password">64c5fd2979a86168</module-option>  
9. <!-- 注意name等于你的数据源的jndi-name,这里是MySqlDS -->  
10. <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=MySqlDS</module-option>  
11. </login-module>  
12. </authentication>  
13. </application-policy>  

<application-policy name="EncryptDBPassword">
<!--这里的name应该是你在配置数据源时写的security-domain里的字符串-->
<authentication>
<login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">
<!-- 数据库的用户名 -->
<module-option name="username">test</module-option> 
<!--数据库的密码，不过是加密过的了 -->
<module-option name="password">64c5fd2979a86168</module-option>
<!-- 注意name等于你的数据源的jndi-name,这里是MySqlDS -->
<module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=MySqlDS</module-option>
</login-module>
</authentication>
</application-policy>

 3.补充一下，这个加密的密码是哪来的

Html代码  

1. java -cp "D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\lib\jboss-jmx.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\lib\jboss-common.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\server\default\lib\jboss-jca.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\server\default\lib\jbosssx.jar" org.jboss.resource.security.SecureIdentityLoginModule 123456 Encoded password: 64c5fd2979a86168  

java -cp "D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\lib\jboss-jmx.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\lib\jboss-common.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\server\default\lib\jboss-jca.jar;D:\TDdownload\jboss-4.2.0.CR1\jboss-4.2.0.CR1\server\default\lib\jbosssx.jar" org.jboss.resource.security.SecureIdentityLoginModule 123456 Encoded password: 64c5fd2979a86168

写上你自己的路径和你要加密的密码就行了,我这里要加密的密码是123456,加密过之后就是64c5fd2979a86168

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，
它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
这种错误常见在web服务器对JSP进行pre compile的时候。

改正方法，在 run.bat 中加入：-Xms512m -Xmx1024m -XX:MaxNewSize=256m -XX:MaxPermSize=256m

因为项目中引用了很多的 jar 包，而这些 jar 包中的 class 信息会被 JBoss 的 class loader 加载到 PermGen space 区域，在 JVM 默认的情况下，该部分空间的大小只有 4M，在 jar 包非常多的情况下，显然是不够用的，所以通过 -XX:MaxPermSize=256m 指定最大值后即可解决问题。

而当出现出现java.lang.OutOfMemoryError: Java heap space 这个异常时，通过调节-Xms512m -Xmx1024m这个就可以解决。

另外，这个两个参数 -XX:+UseParallelGC -XX:+UseParallelOldGC 让服务并行回收内存空间。但是，这两个参数配置上去以后，也会占用一定的内存空间。

本文转自博客 http://www.blogjava.net/fiele/archive/2009/07/27/288609.html

本文转自http://xudayu.blog.51cto.com

 瘦身（一）

当不使用mail-service服务的时候 (J2EE 标准的 JavaMail 客户端)

l 移除server/slim/deploy/mail-service.xml

l 移除server/slim/lib/mail* (mail-plugin.jar, mail.jar - JavaMail stuff)

l 移除server/slim/lib/activation.jar (JavaMail使用的Java 活动框架【Java Activation Framework】)

当不使用缓存失效服务的时候 (一般在集群配置里作为CMP选择一个beans用与失效缓存)

l 移除 server/slim/deloy/cache-invalidation-service.xml

当不使用J2EE客户端部署服务的时候(这不是一个很有益的J2EE规格必须服务，对于EAR application-client.xml描述符)

l 移除 server/slim/deploy/client-deployer-service.xml

当不使用集成HAR部署和Hibernate会话管理服务的时候

l 移除server/slim/deploy/hibernate-deployer-service.xml (HAR support)

l 移除server/slim/lib/jboss-hibernate.jar (HAR support)

l 移除server/slim/lib/hibernate2.jar (Hibernate itself)

l 移除server/slim/lib/cglib-full-2.0.1.jar (used by Hibernate to create proxies of POJOs)

l 移除server/slim/lib/odmg-3.0.jar (由hibernate使用的一些傻瓜试的对象－关系映射行为是从一些傻瓜式的委员会来的[goofy committee]http://www.service-architecture.com/database/articles/odmg_3_0.html

不使用 Hypersonic的时候 (在生产环境里你可能不使用这个)

注意在默认配置里 JBossMQ使用 DefaultDS名字同样被部署，用于为Hypersonic映射. 在配置上对于其他选择的更多信息，见 JBoss MQ Persistence Wiki pages .

l 移除server/slim/deploy/hsqldb-ds.xml

l 移除server/slim/lib/hsqldb-plugin.jar

l 移除server/slim/lib/hsqldb.jar

不使用 JBossMQ 的时候(我们的 JMS 服务器)

l 移除the entire server/slim/deploy/jms directory

l 移除server/slim/lib/jbossmq.jar

不使用 HTTPInvoker的时候 (从RMI到HTTP的隧道)

l 移除the entire server/slim/deploy/http-invoker.sar 文件夹

不使用 XA 数据源的使用 (分布式 and/or 可恢复的事务)

l 移除server/slim/deploy/jboss-xa-jdbc.rar

如果你不需要JMX-Console 然后删除它

l 移除server/slim/deploy/jmx-console.war 或者使用别的方法 使它安全

如果你不需要制造JMX调用RMI (警告the shutdown.sh 是否这样做)

l 移除server/slim/deploy/jmx-invoker-adaptor-server.sar

l 移除server/slim/deploy/jmx-adaptor-plugin.jar 或者你可能想正好想用安全的 the JMX invoker-adaptor顶替

如果你不需要web-console

l 移除server/slim/deploy/management/web-console.war

如果你不需要JMX的JSR-77扩充

l 移除server/slim/deploy/management/console-mgr.sar

如果你需要web-console 或者 jsr-77 扩充的其中之一

l 移除server/slim/deploy/management directory entirely

如果你不使用控制台/email监控警报

l 移除server/slim/deploy/monitoring-service.xml

l 移除server/slim/lib/jboss-monitoring.jar

如果你不通过Properties Service使用富资源编辑器(JMX)或者装载properties到系统properties 里。

l 移除server/slim/deploy/properties-service.xml

l 移除server/slim/lib/properties-plugin.jar

此scheduler-service.xml是一个例子，除非你在它的里面放入自己的东西

l 移除server/slim/deploy/scheduler-service.xml

如果你不适用JBoss调度管理 (允许你安排请求依赖MBeans)

l 移除server/slim/deploy/schedule-manager-service.xml

l 移除server/slim/lib/scheduler-plugin* (scheduler-plugin.jar, scheduler-plugin-example.jar)

如果你不需要供应商特定的sql异常援助[handing] (just leave it, really)

l 移除server/slim/deploy/sqlexception-service.xml

如果你既没有使用客户端事务管理，也没有缓存连接(我们缓存连接来代替池，例如就JAAS->DB User 来说—－使用这个意味着你是个坏人，需要被拍击[using this means you are a bad person and need to be smacked]) .

l 移除server/slim/deploy/user-service.xml

如果你不使用JBoss的UUID key生成 (大多情况下用于CMP主键生成，但是我们的数据库也同样支持的很好)

l 移除server/slim/deploy/uuid-key-generator.sar

l 移除server/slim/lib/autonumber-plugin.jar

user-service.xml 是一个例子 – 除非你在它里面做一些事情 (你自己的mbeans)，你可以移除它.

l 移除server/slim/deploy/user-service.xml

前言

这个建议主要是如果对JBossAS进行调优和瘦身的. 这个概念在多数情况是交叉的。当通过瘦身减少闲置服务线程并不能带来大的性能影响的时候，允许你使用较少的内存和资源对其他性能方便进行调整。当然它可以缩短启动时间。而且，作为一般的安全观念――移除你不使用的服务。我们将分开两个种类: 瘦身和调优. 首先我们使用默认的配置并从那里开始瘦身(对于clustering的话题，将在以后的wiki页面进行讨论 ;-) ). 这个建议不牵扯开发者和管理角色交叉调优的区域开发者和管理角色 (应用程序调优象cache大小一样). 这主要是对于管理调优的建议.

这建议将做技术上非J2EE平台兼容(3.2.6无论如何不顺从)的JBoss实例的有关的那些注意，象除去J2EE关键 服务的那样将导致JBoss 失败TCK。多数性能调优/管理任务工作，在现实世界结构里，在技术上属于这个类别。

假设你已经复制server/default 文件夹并将它重新命名为server/slim.

调优

Java Virtual Machine Java虚拟机

l 对于你的机器和内存大小来调整VM垃圾收集或者调整 JDK 5 的垃圾收集

l 使用64位的机器和64位的VM，以便你能使用大的heap(堆)大小，通常比2－4GB的大。64位支持在所有最新的SPARC/Solaris 寄存器运行Solaris 9 或者以后的版本是有效的, Itanium 使用 JDK 1.4, 或者在Linux x64 上使用JDK 5.

l 如果你不使用上面的最大32位heap空间(2-4 GB 的heap)，不要使用 –d64. 使用64位地址需要更多的内存来做同样的工作量，并且对于应用程序不需要如此多的内存来说并不能提供更大优势。

l 除了避免额外小的heaps外还要避免额外大的heaps. (我们不能告诉你具备什么资格，因为它取决于你正做什么). 这影响generational 垃圾收集和扫描heap的总的时间. 有效的调整一个小heap是困难的 (即使你的应用程序仅仅需要使用200MB，如果你使用并行垃圾收集＋CMS，然后你将需要远高于512MB). 特大号的heaps为垃圾收集花费不必要的时间扫描内存。

l 避开 Sun 1.4 VM. JDK 5 主要是在垃圾收集方面非常的好.

l 使用 -server 参数除了使用其他-XX:ThreadStackSize=128k (Solaris) 或者 -Xss128k (其他任何平台). 在Solaris 上 -Xss128k 什么也没有做 (你只可以设置较大的线程栈大小). 这允许你每个线程通过使用较少的内存达到创建更多线程的目的。but might result in blown stacks with extremely recursive code. 然而, 128k 栈 is still nothing to shake a stick at.

l 你真的需要明白恰当的generational 垃圾收集调整和你真的已经进行了负载测试 (OpenSTA?, JMeter, 等等) 确认是有把握的.

l 你确实将使用一个超过2个处理器的多核心机器，及使用不同的平行和并行垃圾收集选择 (我们谈及这先进的JBoss训练暗示伏笔) 对于最大性能和高拉机回收吞吐量. 不过,你确实需要理解怎么调整才能使得垃圾收集很好的工作。JDK 5大部分是自我调整.

l JDK 1.4的默认 NewSize? 不是好的猜想. 坏的经验法则: < 20% 是一个好的 NewSize?. 20%以上的消费是危险的，这是JDK令人讨厌的一个，能导致它psychotically运行所有满垃圾回收和从未 unsuspend 或者释放出 足够多的内存. JDK 5 似乎没有展示出这个bug，并且似乎已回升更理智的默认值。

JBoss/Java on Linux

如果你正在运行JBoss AS在Linux服务器上，你应该看看这篇文章的作者： Andrew Oliver, Jboss事业部, Red Hat公司, 顾问 ，在 在Linux服务器上怎么优化Jboss/Java  

Tomcat

l 编辑你的server/slim/jbossweb-tomcat5?.sar/server.xml 文件

l 检查你正在使用的连接器的XML文档. 例如, HTTP 连接器:

<Connector port="8080" address="${jboss.bind.address}" 
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
enableLookups="false" redirectPort="8443" acceptCount="100" 
connectionTimeout="20000" disableUploadTimeout="true"/>

l 你应该有多于你最大预期25％(经验法则)的线程(maxThreads)来处理负载(将来一次性的并发访问)

l 你应该有minSpareThreads 等于恰好比你正常负载多一点

l 你应该有maxSpareThreads等于恰好比你峰值负载多一点

l minSpareThreads 意思是 "启动准备就绪, 总是保持至少这些线程来等待处理"

l maxSpareThreads means "如果我们总是超过minSpareThreads那么总是保持 maxSpareThreads 来等待处理"

l 移除任何不需要的值和日志。如果你不用JBoss的安全，移除这个安全值 (见下面).

l Precompile(预编译) JSPs. (这个内置的编译器非常的会，它可能对于小型站点不值得做.)

l 在你的sever/slim/jbossweb-tomcat50.sar/conf/web.xml 里关闭开发（"development"）模式

RMI的远程调用

默认情况下, JBoss为进来的每个RMI请求创建一个新线程. 在一个大系统中这一般不是高效率的. 其次,它允许无限制的连接在性能或者通信峰值或者run-away 连接方面创建客户端可能是危险的。为了补救这个你应该考虑转向被集中的池请求.

       编辑 server/slim/conf/standardjboss.xml

       通过改变每个XML分段读数把所有代理绑定改变成被集中的池请求：

<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>

到

<invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>

JBoss也有大部分无文件证明的PooledInvokerHA你可以试试。

Log4j

日志在性能方面也有重要的影响. 改变日志级别跟踪能给JBossAS 带来蠕虫一样的速度。改变级别为 ERROR (或者WARN) 能引人注目的提升速度。

l 默认情况下, JBoss的日志被打印到控制台和server.log文件里并且它默认使用的日志级别是 "INFO".

l 考虑不记录到System.out (你也能仍旧想改变方向以抓取JVM 错误)

l 考虑改变日志的级别为ERROR. 观察JBoss的log4j配置文件的变化，你可以在其运行的时候改变这个配置。

l 给你的java class层次增加一个类别过滤器.

关掉打印到控制台的日志（console logging）:

l 编辑 server/slim/conf/log4j.xml

l 改变下面的XML 片段:

<root> 
 <appender-ref ref=CONSOLE"/> 
 <appender-ref ref="FILE"/> 
</root>

修改成

<root> 
 <appender-ref ref="FILE"/> 
</root>

l 然后你可以删除此片段:

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> 
 <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
 <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>

改变日志的级别:

l 编辑 server/slim/conf/log4j.xml

l 移除/注释 这些XML 片段:

<category name="org.apache"> 
 <priority value="INFO"/> 
</category> 
 
<!—极限 org.jgroups 类别为INFO --> 
<category name="org.jgroups"> 
 <priority value="INFO"/> 
</category>

l 改变这个XML片段以改变root类别:

<root> 
 <appender-ref ref="CONSOLE"/> <!—你可能在前面已经移除这个--> 
 <appender-ref ref="FILE"/> 
</root>

看上去像这样

<root> 
 <priority value="ERROR" /> 
 <appender-ref ref="CONSOLE"/> <!--你可能在前面已经移除这个--> 
 <appender-ref ref="FILE"/> 
</root>

另外，如果你使用了hibernate的话：

l 编辑 server/slim/conf/log4j.xml

l 增加如下XML 片段

<category name="org.hibernate" >
    <priority value="INFO" />
</category>

最后, 在log4j中也许是最重要的事情，在你拥有的 class 结构上确保你的极限的日志级别. 假设你正在使用的log4j打算不向System.out打印任何东西. 这将大大的降低log4j的额外开销，并且允许你完全享受益处，像如果调用(log.isDebugEnabled())....如果你那么做，那么你的代码中的所有日志都将通过appender进行格式化, 这个threshold 在appender将被从日志消息中去除出去. 它能产生大量的垃圾信息。假设你的java package 以“a.b”开始的话, 在log4j.xml增加一些像这样的信息:

<!--极限a.b 类别为INFO --> 
<category name="a.b"> 
<priority value="INFO"/> 
</category>

这个可以增加到你在org.apache 和 org.jboss (见上文)中找到过滤类别的同一区域.

部署扫描器（Deployment Scanner ）

l 部署扫描器每隔5秒扫描一次，在比较慢的文件系统上尤其吃周期 (*cough* NTFS *cough*).

l 见下面的瘦身stuff on ，怎么调整秒数以至于它发生的不那么频繁或者不全部发生。

无状态会话Beans（Stateless Session Beans ）

l EJB 1.x-2.x 无状态会话beans operate with an ill-advised pooling model (required by the specification). 如果你find你需要考虑设置比默认（10）实例要多的最小线程池的大小:

编辑 server/slim/conf/standardjboss.xml, 向下滚动:

<container-configuration> 
<container-name>Standard Stateless SessionBean</container-name> 
<call-logging>false</call-logging> 
<invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name> 
<container-interceptors>

并找到:

<container-pool-conf> 
<MaximumSize>100</MaximumSize> 
</container-pool-conf>  
</container-configuration>

改变它为:

<container-pool-conf> 
<MinimumSize>100</MinimumSize> 
<MaximumSize>100</MaximumSize> 
<strictMaximumSize/>
<strictTimeout>30000</strictTimeout> 
</container-pool-conf> 
</container-configuration>

在很大程度上一种服务器环境中不希望这些池增长和缩减(因为它导致内存碎片，不如潜在的堆使用). 从性能上来说, nuber要足够的大以提供保证你的所有请求不阻塞的服务。

CMP 调整

l 读这个链接: [url]http://www.artima.com/forums/flat.jsp?forum=141&thread=24532[/url]

l 和这个链接: [url]http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html[/url]

l 现在ditch CMP 和使用JBossHibernate 代替

连接池（Connection Pools）

l 不要使用XA版本，除非你真的知道你需要使用它. XA连接的性能不好.

l  与其在可用的地方利用数据库特定的"ping"支持"check-connection"(检查连接)，或者利用数据库特定驱动的fail-over支持倒不如从不checking connections. (记住并非所有的优化选项都适合你的环境，我们正在讨论的是最佳情况) 。