关于

Hibernate Tools 3.1.0.beta5（http://tools.hibernate.org）现已提供。

至少我个人欢迎我们的新企鹅统治者。

最近，Simon Brown 组合了一套需求，用于比较一个非常简单的博客应用程序，该应用程序可以用来比较 Java Web 框架。我对他所制定的实际需求有所保留（特别是没有表单提交！），但既然其他框架 作者 已经尝试过，我也将这个示例移植到了 Seam。我要对这个帖子提出一个重大警告：Seam 完全不是为像博客或 Web 论坛这样的应用程序设计的；使用像 PHP 或 Ruby on Rails 这样的东西来解决这类问题非常容易，而且没有真正充分的理由使用 Java 来解决这类问题（除非 Java 是你唯一知道的）。我们这里有一套要求，没有 /会话/ 和 /业务流程/，所以 Seam 所有复杂的状态管理机制都是多余的。尽管如此，框架需要让简单的事情变得容易，你将看到我们用 Seam 解决这个简单问题需要编写多少 Java 代码。

使用 Criteria API 的人要么透明地要么有意识地使用了 ResultTransformer。ResultTransformer 是一个简单且易于使用的接口，允许您转换任何 Criteria 结果元素。例如，您可以将任何 Criteria 结果返回为 java.util.Map 或非实体 Bean。

将 Hibernate 源代码移动到我们新的 Subversion 主机已完成。已设置开发人员和匿名访问。目前，仅通过 Apache 模块提供 Web 访问，这并不理想。我们被告知，Fisheye 或 ViewCVS 将很快通过 Subversion 仓库进行设置。

最近在Hibernate的JIRA中提交了一个关于Hibernate错误处理死锁场景的报告。报告的基础是《Pro Hibernate 3》一书中的例子（第9章）。对于那些可能不熟悉“死锁”这个术语的人，基本概念是两个进程各自持有其他进程完成处理所需的资源锁。虽然这种现象并不仅限于数据库，但在数据库术语中，其基本思想是第一个进程（P1）对给定行（R1）持有写锁，而第二个进程（P2）对另一行（R2）持有写锁。现在，为了完成其处理，P1需要获取R2的写锁，但无法这样做，因为P2已经持有其写锁。相反，P2需要获取R1的写锁以完成其处理，但无法做到，因为P1已经持有其写锁。因此，P1和P2都无法完成其处理，因为它们都在无限期地等待对方释放所需的锁，而这双方都无法做到，直到其处理完成。在这种情况下，两个进程被称为死锁。

我将于3月21日在EclipseCon上展示Hibernate Tools 。详情请点击这里。

Thomas发布了一段视频，演示了如何使用Hibernate Tools（JBoss IDE的一部分）从现有数据库逆向工程一个完整的可运行Seam应用程序。

Seam 1.0 beta 2已发布

我已经厌倦了Velocity 在模板中忽略甚至隐藏在Hibernate Tools 中发生的错误和异常的能力。