刘文涛

3、 Layouts

有时用户希望根据自己的喜好格式化自己的日志输出。Log4j可以在Appenders的后面附加Layouts来完成这个功能。Layouts提供了四种日志输出样式，如根据HTML样式、自由指定样式、包含日志级别与信息的样式和包含日志时间、线程、类别等信息的样式等等。

其语法表示为：

org.apache.log4j.HTMLLayout（以HTML表格形式布局），
org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）

配置时使用方式为：

log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
log4j.appender.appenderName.layout.option1 = value1
…
log4j.appender.appenderName.layout.option = valueN


3、 配置日志信息的格式，其语法为：
log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
这里上面三个步骤是对前面Log4j组件说明的一个简化；下面给出一个具体配置例子，在程序中可以参照执行：
log4j.rootLogger=INFO,A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=
%-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
这里需要说明的就是日志信息格式中几个符号所代表的含义：
－X号: X信息输出时左对齐；
%p: 日志信息级别
%d{}: 日志信息产生时间
%c: 日志信息所在地（类名）
%m: 产生的日志具体信息
%n: 输出日志信息换行

Acegi 安全框架
Acegi 是个基于spring的安全框架，早就听说过它的大名啦。上周日和科大的老同学谈起Ajax、DWR时，讨论到ajax的安全性，我就想起Acegi了，DWR提供了集成Acegi的方法。

据说它可以实现单点登录，也可以控制一个帐号同时只能登录一次。单点登录不是很难做，但是后一个就不好做啦。去年在科大做毕业课题时，老板就要我们这样做，要把用户帐号和IP、网卡MAC地址、CPU编号绑定，还要做心跳，为了保密还要用openSSL和数字证书，搞得极其复杂 :(

这是它的官方网站 http://acegisecurity.org/
这是个很好的文档 http://acegisecurity.org/docbook/acegi.html
DWR中集成Acegi http://iremia.univ-reunion.fr/intranet/wiki/Wiki.jsp?page=DWRandAcegi

我没有参与开发

一直在看源码,问题记录和wiki. 还有在论坛上看他们讨论. 自己也在开发论坛上和他们讨论问题,虽然自己英语很烂的说.

不过总算有点成果,说服去掉FreeMarkerServlet的deprecated.

在webwork 2.2里,我们可以在普通jsp页面和普通ftl里面直接使用i18n,不需要专门处理,不需要通过action.

为了使用这个特性,我和plightbo讨论了一下,最后他计划去掉这个"deprecated",当然最后还没有定局. 也许别人还会有不同的看法的.

总之一些特性我们使用webwork的开发人员也可以争取.

1.XWork升级到到1.1版本
增加了spring的支持.

2.大力支持FreeMarker
新增ftl模板,包括simple和xhtml,模板默认为freemarker的ftl了,当然还是可以配置为velocity的,在webwork.properties里面修改.


3.AJAX的大力支持
使用dojo,dwr等来做AJAX 支持,数据校验也可以使用AJAX.
好像增加了很多页面上的小饰件.


4.支持Spring的IOC
原来的SpringObjectFactoryListener等被放到了webwork项目里.其他相关的类也被放到XWork里.

5.Hibernate支持
不过看起来很简单的几个类,没有试

6.支持JAVA5的一些特性
没试过.

7.加入了portlet支持
胡鹏飞写的一个WWPortlet加入了webwork,虽然支持,但是对文档和代码质量有些担心.嘿嘿,能加入Webwork是个巨大的诱惑哦


8.Eclipse/Idea插件
不过没有看到代码,只看到一个空项目

另外还有很多新的特性,有时间在补充,没时间就不一一列举了.


我也简单浏览了一下webwork和xwork的cvs源代码，感觉改动是非常大的，值得关注的有几点：

xwork方面：

1、把原来在xwork-optional包中的spring集成的代码放进了xwork1.1中，这样就无需自己从cvs上面checkout xwork-optional源代码编译使用了。

2、xwork1.1的DTD增加了一种exception类型的支持，可以在action里面配置根据不同的异常执行不同的result，也支持global-exception。实现方式是通过增加一个interceptor。这个功能非常实用，你可以配置不同的应用异常转向到不同的反馈页面，非常棒的功能。

3、把i18ninterceptor增加进来了。

webwork方面：

1、废弃了ServletDispacher，改用FilterServlet了，附带增加了不少功能。

2、AJAX支持。这恐怕是webwork2.2最大的变动了，成熟性有待验证，不过集成AJAX也算是webwork想对比其他MVC框架的一大杀手锏了。

3、模版增加了FreeMarker支持，默认模版也改成了FreeMarker。

4、Portlet支持。这个我不懂，无法评论。


总体而言，webwork2.2是一个改动非常大的升级版本，新特性非常有用，值得升级使用。缺点就是文档非常缺，往往要看源代码，才能搞清楚怎么去用。

hibernate 3.1 release
－－－－－－－－－－－－－－－－－－－－－
你那个仅仅是3.1 rc3到3.1的changelog而已
sf.net早看到了

－－－－－－－－－－－－－－－－－－－－－
3.1里面中文版的reference已经没有了（好几个语言的版本都没有附带），不知道是什么原因……

Robbin他们打算再为3.1翻译一份？这个文档有变化了？
－－－－－－－－－－－－－－－－－－－－－
翻译是肯定要做的，不过要有个过程。

以下消息来自 WebWork中文站点
2006-01-12
OpenSymphony 和 WebWork 团队自豪的公告 WebWork 2.2 的发布 (download now). 这次发布对WebWork来说是最重要的发布,这么说的理由如下(full release notes):

对Java 5标注和泛型的全面支持
丰富的AJAX 支持，使用了 DWR 和 Dojo
新的 QuickStart 工具让开发比以前更容易
大量的文档，超过900页（PDF文档）!
使用AJAX或者普通的JavaScript进行客户端校验
Continuations 的内建支持
对几个流行Portlet服务器的 JSR168/Portlet 支持，包括 Pluto
丰富的界面模板框架，包括对JSP,FreeMarker,Velocity的本地支持
对 Spring 和 Pico IOC 容器的本地支持
更智能的错误报告
开发模式改进了错误报告使开发程序更加容易。
简单的标签语法
高级数据绑定框架可以和任何对象协作，包括 domain 对象
这次发布是WebWork历史上的一个重要的里程碑: 是最后一次使用WebWork和OpenSymphony名字的主要发布. 虽然小的发行版本还会继续进行（包括 2.2.x和2.1.x),但是所有主要的工作将转向 Struts Action Framework 2.0 版本. 你可以把 WebWork 2.2 当作一个Struts Action Framework 2.0 的早期预览版本使用, 但是你也期望很多其他的重大的改进被增加到新的版本中.

感谢整个的 WebWork team 的努力的工作, 特别是在最后几个星期里作出的令人惊异的工作( during these last few weeks as the final touches were put in place ).

开始使用

我们认为开始使用任何技术最好的方式就是立刻试用它. 这也就是为什么我们把WebWork做成一个非常容易开始进行WEB开发的平台的原因. 你可以使用 QuickStart 功能 (阅读 QuickStart 的文档来了解你如何在你的项目中使用这个重要的工具):

在Webwork的根目录下打开一个命令行窗口
使用 Java 5 JDK, 执行: java -jar webwork-2.2.jar quickstart:showcase
打开浏览器,访问: http://localhost:8080/showcase
自由编辑任何源码 (.java, .jsp, 等等) 位于目录: webapps/showcase
刷新浏览器可以看到立刻的改变

现在用WebWork2.2开发的软件，以后的维护工作是个问题。因为几个月过后，只能转向Struts 2.0。

闹心！

之前的举动分析，感觉上WW想并入Spring MVC未果。（估计是遭Rod拒绝了），所以一怒之下和Struts合并，想击败Spring阵营。

以上分析仅从商业出发，未考虑技术细节和人品问题。

有兴趣的可以看一看Struts Ti的项目介绍和进展状况：

http://wiki.apache.org/struts/StrutsTi
http://wiki.apache.org/struts/StrutsTi/StatusMatrix

从这里一项一项看下来，Struts Ti基本上就是在webwork2.2上面整合了Beehive的annotation和page flow，好像没有struts1.x的什么技术继承下来。恐怕唯一继承自struts的只有struts的用户群了。

大家可以看一下相关的Clarity的讨论：
http://opensource2.atlassian.com/confluence/oss/display/WAG/Clarity
一个企图统一Java Web框架的项目
http://opensource2.atlassian.com/confluence/oss/display/WAG/Home

从讨论来看，来自JSF阵营的人态度尚不明朗（我没有一个一个去看yahoo的mailist），来自MVC阵营的人态度已经比较明朗：Struts和Webwork最积极，已经宣布合并到Struts Ti里面，BeeHive也跟着加入进来了，现在就是Spring MVC明确表态考虑到客户的商业利益和合作伙伴（BEA）的合作关系，以及保护对Spring MVC和Spring WebFlow的已有投资，态度表现的相当冷淡。

然而仅以目前的进展来说，也是令人鼓舞的。Java MVC阵营未来比较主流的只剩下Struts Ti(webwork的架构，Struts的用户群体，BeeHive的PageFlow和annotation)和Spring MVC的竞争（也许两者也会融合）。

让我们拭目以待，看看接下来，还有没有什么更惊人的举动吧。

看到了这个消息以后感觉非常吃惊，所以跟踪相关的link仔细阅读了一下相关的网页，看完以后我认为对于webwork和struts来说这都是一个重大利好的消息。从整个事件来看，并不是单纯的webwork开发团队合并struts团队这么简单，事实上struts1.3和webwork2.2仍然按照原定roadmap继续发展，而两个团队核心开发人员发起一个新的项目Struts Ti，它的readmap是：

引用:
* Ti phase 1 = WebWork 2.2 + Struts 1.x compatibility library and migration tools
* Ti phase 2 = phase 1 + Commons Chain integration + Beehive's Page Flow + simplified annotations + quick development mode


从这个roadmap可以看出来，新项目Struts Ti是以webwork的整体架构为基础，辅以Struts的一些库，并且该项目的四个发起人联名的声明中这样说：

引用:
As some of you know, the underlying idea behind Ti was to use WebWork as the core of Struts Action Framework 2.x. Conceptually, WebWork and Struts 1.x are very similar. We've often said, without embarrassment, that WebWork does many things better than Struts 1.x. Meanwhile, WebWork has the ability to provide a layer of almost full backwards-compatibility for Struts 1.x, and we have already demonstrated we can integrate Beehive's (very cool) Page Flow with WebWork.


这段话明白无误的指明新框架是以webwork为core的，并且webwork可以提供一个抽象层，以完全向后兼容Struts1.x，并且struts还可以集成Apache Beehive的Page Flow。

因此，我想那些担心webwork从此消失的人可以打消顾虑了，消失的只是webwork这个名字，和com.opensymphony的package前缀，而webwork的程序架构却不会消失。

对于Struts的使用者来说，Struts虽然拥有一个庞大的使用群体，但是Struts在技术上已经非常落伍，再不进行重大的架构革新，势必要被淘汰。因此，这个事情是Struts开发团队的一次自救的革命，从Struts1.3到Struts Ti的改变如同EJB2到EJB3的改变，旧的Struts1.3的架构被完全抛弃，吸收了更加先进的开源软件和架构之后，推出的新东西。

对于Webwork的使用者来说，获得了更加广泛的用户群体和接受度。并且核心开发团队也得到了壮大，相信未来的新版本推出速度可以更快了，而不是现在这样，对webwork2.2都望穿秋水了。

另外非常值得注意的是，Struts Ti的目标可不止集成Webwork这么简单，看看它的phase 2，集成Beehive的Page Flow，JDK1.5的annotations，目标是Ruby on Rails般的快速开发模式，多么诱人的前景！

统一了有怎么样?统一就好吗?统一和垄断的界限是很不清楚的.

Pragmatic ： 注重实效的