下载“Spring in Production”白皮书
我们最近举办了一个关于“Spring in Production”主题的网络研讨会。我当时承诺将在我们的网站上提供网络研讨会的录音和配套幻灯片。不幸的是,为我们制作网络研讨会的工程师忘记设置“录制”标志,所以我需要重新录制该课程:(。我目前正在旅行,但我会尽快尝试完成并提供。
好消息是,您无需因此错过。我撰写了一篇关于“Spring in Production”主题的白皮书,其中涵盖了网络研讨会中的内容以及更多内容……
我们最近举办了一个关于“Spring in Production”主题的网络研讨会。我当时承诺将在我们的网站上提供网络研讨会的录音和配套幻灯片。不幸的是,为我们制作网络研讨会的工程师忘记设置“录制”标志,所以我需要重新录制该课程:(。我目前正在旅行,但我会尽快尝试完成并提供。
好消息是,您无需因此错过。我撰写了一篇关于“Spring in Production”主题的白皮书,其中涵盖了网络研讨会中的内容以及更多内容……
一些用户询问我们是否致力于Spring Java 配置,以及它与Spring 2.5中引入的注解配置选项的关系。答案是肯定的,我们致力于 Java 配置;这两种方法并不相互排斥。
这两种配置方法截然不同:@Autowired 注解在 Spring 框架中使用业务对象中的注解配置组件,而 Spring Java 配置则采用了一种独特的方法,将注解外部化到专用的配置类中。这两种方法都没有绝对正确……
正如你们中的一些人可能已经注意到的那样,Spring 2.5 RC1 最终在周一发布,并等待着您进行试用!Spring 2.5 在许多方面都是完成 Spring 2.0 任务的版本:为 Java 1.4 和 Java 5 提供最灵活、最全面的配置模型。Spring 2.5 特别侧重于对 Java 5 的全面支持,引入了各种其他注解选项。我想借此机会指出此版本背后的统一主题。
Spring 2.5 允许进行方便的外部化配置,同时尽可能保持简洁。这是建立在 Spring 2.0 对 XML 模式命名空间的支持基础上的,Spring 2.5 引入了新的“context”和“jms”配置命名空间。后者是 Spring 配置命名空间增值的一个很好的例子 - 如果您使用 Spring 2.0 样式的消息驱动对象,绝对值得采用!此外,Spring 还允许在不涉及任何 XML 的情况下进行编程引导……
您可能已经看到了一些关于 Interface21 与Tasktop 合作创建“Spring Tool Suite”的公告的报道报道报道报道。此套件将Spring IDE、AspectJ 开发工具 (AJDT)、AspectJ和Mylyn 集成在一起,为 Spring 驱动的企业应用程序的开发提供了一种以任务为中心的途径。我们希望在即将举行的The Spring Experience 大会上与您分享集成套件的预览,但与此同时,您将看到许多改进流入现有的 Spring IDE、AJDT、AspectJ 和 Mylyn 开放……
在上一月的 Gartner 开源大会上,分析师宣布开源已渗透到全球软件市场的重要部分。细节在最近的一篇Matt Asay 博客中得到强调,该博客引用了eWeek 文章。eWeek 写道:“开源产品在 2006 年占 927 亿美元软件市场的 13% 的份额,但在 2011 年预计将占市场的 27%,收入预计将达到 1692 亿美元。”
同时,Gartner 分析师 Massimo Pezzini 和 Yefim Natis 发布了一份报告,强调了当前中间件和事务处理市场正在发生的重要颠覆趋势。2007 年 9 月 24 日的报告题为“平台中间件趋势:颠覆即将到来,”强调了十多个趋势,这些趋势“将颠覆看似静态的应用程序服务器和事务处理市场”,并警告……
正如我之前发布的那样,Interface21 正在参与 Java EE 6 工作,包括我自己、Juergen Hoeller、Keith Donald 和 Rob Harrop 在内的多位同事将参与多个专家组。
这意味着我们总体上更多地参与了 JCP。我们尊重 JCP 的保密性和其他规定,因此我们不会讨论任何非公开的内容。但是,我想谈谈我们参与 JCP 的目标以及我们将采用的基本方法。当然,我们只是一家公司,在众多公司和个人中,我们只是……
Spring 2.5 提供了一个新的切入点指示符 - bean(),它允许选择与匹配名称模式的 bean 中的连接点。现在可以使用自动代理机制以及 Spring-AspectJ 集成来选择特定的 bean,即使存在多种类型的 bean 也是如此。早些时候,您可以使用BeanNameAutoProxyCreator来实现类似的结果;但是,该机制不适用于 Schema 样式或 @AspectJ 方面。
除了选择特定 bean 之外,如果您遵循适当的命名约定,此切入点指示符还提供两种有趣的选择 bean 的方法
图 1:使用 bean() 切入点根据 bean 名称选择水平和垂直切片
此切入点表示对 AspectJ 切入点表达式语言的 Spring 特定扩展,因此仅在基于 Spring 的应用程序中才有用。名称模式遵循 AspectJ 对名称模式的匹配规则,其中 '*' 是唯一允许的通配符。下表显示了一些示例切入点及其选择的 bean。切入点 | 在其中选择的连接点 |
---|---|
bean(accountRepository) | 名为“accountRepository”的 bean |
!bean(accountRepository) | 除“accountRepository”bean 之外的任何 bean |
bean(*) | 任何 bean |
bean(account*) | 名称以“account”开头的任何 bean |
bean(*Repository) | 名称以“Repository”结尾的任何 bean |
bean(accounting/showaccount) | 名为 accounting/showaccount 的 bean(例如,处理该 URL 的控制器) |
bean(accounting/*) | 名称以“accounting/”开头的任何 bean(例如,处理与会计相关的任何 URL 的控制器) |
bean(accounting/*/edit) | 名称以“accounting/”开头并以“/edit”结尾的任何 bean(例如,处理与会计相关的编辑操作功能的任何控制器) |
bean(*dataSource) || bean(*DataSource) | 名称以“dataSource”或“DataSource”结尾的任何 bean |
bean(service:name=monitoring) | 名为“service:name=monitoring”的 bean |
在题为关于 Interface21 的胡言乱语的文章中,一位 SourceLabs 员工不同意我的观点,即提交权限对于提供可靠的开源支持是必要的。
在我回复之前:我想再次明确说明我在上一篇博客中已经说过的事情,但似乎被一些人误解了:Interface21 不希望阻止其他人从 Spring 中获利。我们的往绩证明了这一点。我们欢迎其他人撰写有关 Spring 的文章并提供 Spring 服务。或者基于 Spring 创建产品,例如Matt Raible 的 AppFuse。我们祝他们成功。Spring 部分地获得了……
我几个月前关于开源业务模型的博客似乎引起了共鸣。我收到了许多积极的回复,并促使一个名为“How Software is Built”的网站提出采访请求。我的采访在这里。
最后,OpenLogic 的某位员工发表了一篇有趣的回复。Bryan Noll 在对我的博客的回复中留下了一些评论,值得我做出适当的回应。
首先,我认为你关于“当一些对特定项目没有真正投入的人为其提供支持时,对项目或开源社区来说是不健康的”的断言很有意思……我以前从未听过这样的说法。我认为这种说法有一定的道理,足以让像我们这样的公司考虑并真正审视我们对所支持的开源项目的责任。在我看来,这种审查的结果将是 OpenLogic 制定一项可证明的政策,以减轻你提出的潜在问题。我当然不知道那具体会是什么,所以现在就先笼统地说。不过,这很好地引出了我对你说法的一些疑问。我认为找到这样一项“可证明的政策”非常简单。OpenLogic 需要理解 Stormy 的帖子 中的开篇评论“从事开源软件开发的开发者通常都有薪水不错的日常工作……因此,他们免费从事开源软件工作,并在白天编写代码赚取大笔收入”在很大程度上是错误的,理解他们希望从中获利的开源软件的来源,建立合适的合作伙伴关系,并设定一个允许真正支持的价位。另一种选择是停止声称提供企业支持,并明确表示所提供的是一种随叫随到的开发协助,无法保证能够解决关键问题。这又回到了我为什么对 Stormy 的帖子感觉强烈到要对其进行分解。
我认为聚合模型就像超市的商业模式。当我在超市购物时,我希望他们从我购买的每件商品中抽取一小部分(作为佣金),作为处理众多供应商、将所有……
到目前为止,Spring 产品组合的 Maven 工件,尤其是快照版本,创建方式不一致,并且散布在各个位置。在过去的两周里,我们一直在努力使这些项目在创建和上传这些工件方面更加一致。
Spring 产品组合中对 Maven 支持最有用的改进之一是使用一致的仓库位置。根据你对代码的熟悉程度,有三个不同的仓库。
对于任何最终版本(Spring 2.5、Spring Web Flow 2.0 等),该版本的 Maven 工件将上传到 Maven 中央仓库 (http://repo1.maven.org/maven2)。使用此仓库无需你做任何操作,因为 Maven 会自动在此处查找工件。
此仓库中的工件确实遵循预期的仓库行为,并且不会(也无法)被删除。
对于任何里程碑版本(Spring 2.5-RC1、Spring Web Flow 2.0-M2 等),该版本的 Maven 工件将上传到 Spring 里程碑仓库 (http://s3.amazonaws.com/maven.springframework.org/milestone)。使用此仓库需要你在 POM 文件中的 <repositories/> 元素中添加一个条目。它应该如下所示
<repository>
<id>spring-milestone</id>
<name>Spring Portfolio Milestone Repository</name>
<url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
</repository>
此仓库中的工件不遵循预期的仓库行为,并且会定期删除。在最终版本(Spring 2.6、Spring Web Flow 2.1 等)发布后,将删除先前版本工件的所有里程碑版本。例如,当 Spring 2.6 发布时,Spring 2.5 的里程碑版本将被删除,而 Spring 2.6 的里程碑版本将被保留。
对于任何快照构建(Spring 2.5-SNAPSHOT、Spring Web Flow 2.0-SNAPSHOT 等),该构建的 Maven 工件将上传到 Spring 快照仓库 (http://s3.amazonaws.com/maven.springframework.org/snapshot)。使用此仓库需要你在 POM 文件中的 <repositories/> 元素中添加一个条目。它应该如下所示
<repository>
<id>spring-snapshot</id>
<name>Spring Portfolio Snapshot Repository</name>
<url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url>
</repository>
此仓库中的工件不遵循预期的仓库行为,并且会定期删除。对于给定工件,至少会保留最近 10 个快照构建。如果从分发版中删除了某个工件,则其快照构建将立即删除。在里程碑版本或最终版本发布时,将删除该工件的所有快照,并为下一个版本创建一个新的快照。
里程碑和快照仓库都托管在 Amazon 的 S3 服务上,因此目录结构对人类来说不可读。要以人类可读的格式查看仓库,请使用 S3Browse 实用程序。
仅将这些 URL 用于人类可读的查看。如果将它们用作 POM 文件的 URL,则会遇到错误。
另一个重要的改进是为所有版本添加了源代码工件。你会注意到,在里程碑仓库中,所有工件都部署了源代码。随着我们继续前进,所有最终版本也将如此。具体来说,从 Spring 2.5 版本开始,除了组合的 Spring 源代码外,每个模块也将有一个源代码工件。
最终的改进尚未完成;Spring 的每日快照。我很高兴地说,这项工作即将完成。我仍在解决与 Maven Ant 任务 相关的最终问题,但这最终将开始显示,并且我会在它出现时再次宣布。此外,你可以预期此功能最终将扩展到所有其他基于 ANT 的 Spring 产品组合项目,以便所有项目都将创建 Maven 快照以及里程碑版本。