Spring Security 2.0.1 发布

发布 | Ben Alex | 2008 年 5 月 2 日 | ...

Spring Security 2.0.1 现已可用。

下载 | 变更日志 | 公告 | 网站

Spring Security 2.0.1 为最近发布的 2.0.0 版本提供了一些修复。它还在 OSGi 支持、扩展命名空间配置和加密强度令牌生成方面提供了一些进一步的改进。它完全向后兼容 2.0.0,并且可以作为 JAR 替代品直接使用。

完善全貌:Spring、OSGi 和 SpringSource 应用平台

工程 | Adrian Colyer | 2008年5月1日 | ...

** 5月2日更新,包含案例研究:- 详见此帖子底部 ** 我相信阅读本博客的大多数人昨天都看到了 SpringSource 应用平台的发布公告。如果没有,请务必查看 Rob 的博客文章,其中描述了一些动机、编程模型和路线图。

有一些常见的疑问,我想在这篇文章中直接解决。之后,我将描述另外两个激动人心的公告,它们补充了 SpringSource 应用平台本身,但昨天没有登上头条:……

介绍SpringSource Application Platform

工程 | Rob Harrop | 2008 年 4 月 30 日 | ...

经过数月紧张的编码,我很高兴地宣布 SpringSource Application Platform 1.0 的 beta 版本发布。

2007 年初,我们开始讨论替代单体式、重量级应用程序服务器的可能方案,企业 Java 已与这些服务器形影不离。客户正在寻找一个轻量级、模块化且足够灵活的平台,以满足其开发和部署需求。

Spring 和 Tomcat 的组合表明,开发人员和运维人员可以在生产环境中成功使用一个轻量级的平台。尽管这种组合取得了成功,但缺乏模块化和对非 Web 应用程序的显式支持限制了其适用性和灵活性。

我们着手构建 SpringSource Application Platform 以满足这些需求并消除这些限制。

Platform 的核心是 Dynamic Module Kernel (DMK)。DMK 是一个基于 OSGi 的内核,充分利用了 OSGi 平台的模块化和版本控制功能。DMK 基于 Equinox 并扩展了其在配置和库管理方面的功能,同时为 Platform 提供了核心功能。

SpringSource Application Platform Architecture

为了保持最小的运行时占用空间,OSGi bundle 由 DMK 配置子系统按需安装。这使得应用程序可以安装到运行中的 Platform 中,并且其依赖项可以从外部存储库中满足。这不仅消除了手动安装所有应用程序依赖项的繁琐工作,而且最大限度地减少了内存使用。

DMK 本身需要一套最小的 bundle 来运行,并通过一个 **profile** 进行配置,以精确控制加载的附加模块集。例如,DMK 不需要 Tomcat,但默认的 Platform profile 包含 Tomcat 以允许部署 Web 应用程序。如果您想在没有 Tomcat 的情况下运行 Platform,只需编辑 profile 即可,它就不会被安装。(如果您尝试这样做,请记住,删除 Web 支持意味着 Web 模块将不再部署,因此请删除 pickup 目录中的内容,以免 Platform 在启动时尝试安装 Admin 和 splash 屏幕应用程序。)默认的 Platform 配置(安装了管理控制台)仅占用 15MB 内存。

我对企业 Java 的一个长期不满是,应用程序经常被塞进牵强的孤岛,并且缺乏对不同应用程序类型的显式支持。考虑一个在线商店的应用程序。该应用程序有一个 Web 前端、一个消息驱动的订单处理模块、一个批处理驱动的库存重新排序模块和一个 B2B Web 服务模块。如今,许多此类应用程序将被打包成 WAR 或 EAR,并且模块将非常相似,对模块类型差异的支持很少。有趣的是,许多人会将此称为 Web 应用程序,而不是带有 Web 模块的应用程序。

在 SpringSource Application Platform 中,应用程序是模块化的,每个模块都有一个 **personality**,用于描述它是什么类型的模块:Web、批处理、Web 服务等。Platform 以特定于 personality 的方式部署每个 personality 的模块。例如,Web 模块在 Tomcat 中使用 Web 上下文进行配置。应用程序中的每个模块都可以独立于其他模块进行更新,同时保持作为大型应用程序一部分的身份。无论您构建哪种类型的应用程序,编程模型仍然是标准的 Spring 和 Spring DM。

在 1.0 Platform 版本中,我们支持 **web** 和 **bundle** personality,这使您能够构建复杂的 Web 应用程序。未来的版本将根据后续详述包含对更多 personality 的支持。

构建应用程序

Platform 支持三种形式的应用程序打包

  1. Java EE WAR
  2. 原始 OSGi bundle
  3. 平台归档 (PAR)

Platform 直接支持标准的 WAR 文件。在部署时,WAR 文件将被转换为 OSGi bundle 并安装到 Tomcat 中。所有标准的 WAR 合约都得到遵守,您现有的 WAR 文件应该可以直接部署而无需更改。

任何符合 OSGi 标准的 bundle 都可以直接部署到 Platform 中,并可以充分利用对 `Import-Package` 和 `Require-Bundle` 所引用的任何依赖项进行的即时配置。

PAR 格式是为 Platform 打包和部署应用程序的推荐方法。PAR 只是一个 OSGi bundle(模块)的集合,这些 bundle 被分组到一个标准的 JAR 文件中,并带有一个唯一标识应用程序的名称和版本。PAR 文件作为单个单元部署到 Platform。Platform 将提取 PAR 中的所有模块并进行安装。第三方依赖项将根据需要即时安装。

与直接将 bundle 部署到 Platform 相比,PAR 格式有三个主要优势。首先,它更简单。一个中等规模的企业应用程序可能包含 12 个以上的 bundle - 手动部署这些 bundle 将非常繁琐。其次,PAR 文件为应用程序中的所有 bundle 形成了一个显式的范围,防止使用重叠类型或服务的应用程序之间发生冲突。此范围还用于一些高级功能,例如加载时织入,以确保一个应用程序的织入不会干扰另一个应用程序的织入。最后,PAR 形成了一个逻辑分组,用于定义哪些模块是应用程序的一部分以及应用程序有哪些第三方依赖项。此分组由管理工具用于提供应用程序的详细视图。典型的 PAR 应用程序如下所示:

PAR File Structure

应用程序中模块之间的依赖关系通常使用 Import-PackageExport-Package 来表示。对第三方库的依赖也可以通过相同的方式表达,但对于许多库而言,这可能会耗时且容易出错。在使用 Hibernate 等库时,通常需要导入比预期更多的包。为了解决这个问题,您可以使用 Require-Bundle,但这存在一些语义上的不足之处,例如拆分包(split packages),即一个逻辑包被拆分到两个或多个类加载器中,导致运行时出现问题。Platform 引入了两种新的机制来引用第三方依赖:Import-BundleImport-LibaryImport-Bundle 类似于 Require-Bundle,但它避免了拆分包以及 Require-Bundle 的其他问题。Import-Library 提供了一种机制,可以用一个声明来引用一组包(例如 Spring Framework 中的所有包)导出的所有包

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

在这里,我有一个依赖于 Commons DBCP bundle 和 Spring Framework 库的模块 bundle。Spring Framework 库包含使用 Spring 在应用程序中所需的所有 bundle。

`Import-Library` 和 `Import-Bundle` 在后台会展开为 `Import-Package`,因此与标准的 OSGi 语义一致。

Platform 理解模块的 personality,并能从中推断出如何配置模块的执行环境。在部署 Web 模块时,典型的 Spring MVC 应用程序所需的所有 Servlet 基础设施都会自动创建,从而无需在应用程序中重新创建这些样板代码。在 1.0 最终发布版中,将为 Web 模块 personality 添加更多智能功能,以支持 Spring Web Flow 等其他技术。

无论您选择哪种打包格式,编程模型都只是 Spring Framework 和 Spring Dynamic Modules,其他 Spring Portfolio 产品运行在其之上。

可服务性

可服务性是整个工程团队的关键考虑因素。我们花费了大量时间来研究日志消息的格式和堆栈跟踪的大小,以确保诊断应用程序问题尽可能容易。每当发现一项重复且耗时的任务时,我们都会寻找一种方法来自动化它或完全消除它。

为了帮助诊断问题,Platform 在日志和跟踪消息之间进行了严格的划分。日志消息旨在供最终用户使用,让您无需筛选大量跟踪内容即可获取最重要的失败信息。所有应用程序故障都会显示并编码在日志输出中 - 代码可方便地用于访问知识库或支持内容。为了理解这一点为何如此有用,请考虑以下 Platform 启动输出:

[2008-04-29 12:12:01.124] main                     <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main                     <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main                     <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1            <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm…

Web 应用程序和 OSGi

工程 | Costin Leau | 2008 年 4 月 29 日 | ...

自 Spring Dynamic Modules 的第一个里程碑以来,运行 OSGi 中 Web 应用程序的请求开始涌入。这可能是最受欢迎的功能之一,而且毫不奇怪,一旦 1.0 最终版发布,Web 支持就一直是 1.1 分支的主要关注点。我很高兴地报告,随着刚刚发布的 M2,正如 Juergen 已经暗示的那样,Spring-DM 不仅支持标准的 war(自 1.1.0 M1 起可用),还支持在 OSGi 中运行的 Spring-MVC 应用程序。在本文中,我想简要讨论典型的 OSGi Web 场景和 Spring-DM 的方法。但首先,

为什么要在 OSGi 中部署 WAR?

简单问题:OSGi *原生* 提供版本控制、包连接和热重加载。想象一下在您的应用程序中利用这些功能:您可以停止将库嵌入WEB-INF/lib并将它们在 Web 应用程序之间共享,避免 taglibs 重复(同时保持多个版本运行),并实时更新应用程序的特定部分。这尤其有用,因为 Web 应用程序往往是分层的,因此在其生命周期中会经历大量更改。

为什么 OSGi 中的 Web 应用程序存在问题?

Servlet 规范围绕着一个*Web 容器*的概念:一个为 Web 组件提供运行时环境的运行时环境,该环境提供标准服务,如生命周期管理(对象创建和处置、线程分配)、并发、HTTP 请求处理等。另一方面,OSGi 平台也作为具有服务注册表、包连接和版本控制(仅举几例)的托管环境。为了解决这个问题,OSGi 委员会设计了 compendium 规范的一部分,即 Http Service

如今,可移植性比以往任何时候都更重要

工程 | Juergen Hoeller | 2008 年 4 月 29 日 | ...

昨天,我写了一篇关于Spring 如何帮助最大化应用程序可移植性的博客。尽管可移植性问题一直是企业 Java 领域的一个持续性话题,但这篇博客非常及时。今天,Oracle 宣布其以 67 亿美元收购 BEA Systems 的交易已完成。两家公司产品集存在大量重叠,因此这必将为 WebLogic 和 OC4J 的客户群带来不确定性。WebLogic 和 OC4J 可能都属于“J2EE 服务器”类别,但它们是截然不同的产品,具有截然不同的特性。

由于许多企业…

框架层面的可移植性

工程 | Juergen Hoeller | 2008 年 4 月 28 日 | ...

可移植性是 Spring 生态系统中的一个关键因素。我们坚信框架级别的可移植性:应用程序组件是针对特定框架(或框架版本)编写的,例如 Spring 2.5;然后,框架负责适配任何底层托管环境。然而,特定的应用程序框架独立于托管环境。一个新的框架版本可以部署到已建立的托管平台版本上,只要环境的基本功能足够。这种方法…

会议季仍在继续

工程 | Rod Johnson | 2008年4月24日 | ...

昨天,我在德国威斯巴登举行的 JAX 会议 上发表了开幕主题演讲。JAX 是欧洲最大的 Java 会议之一,有超过 2000 名与会者。主题是企业 Java 的未来,我详细阐述了我 最近一篇关于预测的博文 中的主题,并深入探讨了 Java EE 6 的影响 以及应用程序服务器的未来。
我已 上传了幻灯片,其中包括对企业 Java 演进过程中一段有趣时期的 8 项预测。这是我第一次在同一场演讲中提及约瑟夫·斯大林、莫妮卡·莱温斯基和蒙提·派森。

Spring Security 2.0 正式发布:告别“死去的仙女”

工程 | Rod Johnson | 2008年4月17日 | ...

Spring Security 2.0 已发布。这是 Spring 产品组合向前迈出的重要一步。Spring (Acegi) Security 已是 Java 平台最广泛使用的企业安全框架,在 SourceForge 上下载量超过 250,000 次,每次发布下载量超过 20,000 次。通过大幅简化使用方法,本次发布无疑将把采用率提升到一个新的水平。

我特别高兴看到这次发布,原因如下:

  • 这对 Spring 社区来说是一件大事。它(更加)易于使用,同时也更强大。它使许多更多用户能够使用最强大的企业 Java 安全解决方案,几乎消除了采用的障碍。请参阅这篇 教程,了解它如何让保护典型的 Web 应用程序变得更加容易。XML Bean 定义的泛滥已成为过去。
  • 这是 Spring 2.x 工作的一种延续,通过应用自定义 XML 命名空间的力量来实现激进的默认设置,同时仍然允许定制。
  • 与 Spring 2.5 一样,它也体现了当前 Spring 产品组合朝着“大幅减少对 XML 的需求”这一趋势发展。
  • 这是 SpringSource 商业模式价值的证明。我们的收入模式使我们能够比以往任何时候都投入更多资源来创建开源软件。如果没有能力同时聘用 Acegi/Spring Security 的创建者 Ben Alex 和另一位主要贡献者 Luke Taylor,这次发布要么不会发生,要么会大打折扣。
  • 这对 仙境 来说是件好事。

Acegi/Spring Security 的创建者 Ben Alex 和 Luke Taylor 做得非常出色。Ben 将在下个月的 Java One 大会上就 Spring Security 发表讲话。如果…

Spring Security 2.0.0 发布!

发布 | Ben Alex | 2008年4月15日 | ...

Spring Security 2.0.0 现已发布。

下载 | 更新日志 | 公告 | 网站

经过近两年的开发,Spring Security 2.0.0 现已可供下载。此重要新版本取代了 Acegi Security,成为 Spring 应用程序的官方安全模块。它提供了显著简化的配置,以及无数其他新功能,包括 OpenID、NTLM、JSR 250 注释、AspectJ 切点支持、领域 ACL 增强、RESTful URI 授权、组、分层角色、用户管理 API、基于数据库的“记住我”、portlet 认证、其他语言、Web Flow 2.0 支持、Spring IDE 可视化和自动完成、通过 Spring Web Services 1.5 增强的 WSS 支持等等。

Spring Web Flow 2.0.0.RC1 发布

发布 | Keith Donald | 2008 年 4 月 14 日 | ...

亲爱的Spring社区,

我们很高兴地宣布 Spring Web Flow 2.0.0.RC1 现已发布。 下载 | 文档

2.0.0.RC1 引入了多项新功能,并修复了先前里程碑版本报告的所有已知问题。

我们建议您从先前的 Web Flow 2 里程碑版本 升级到 2.0.0.RC1。我们也建议 Web Flow 1 用户此时开始评估升级到 Web Flow 2,因为 RC1 引入了全面的 2.0 版本文档,以及一个用于自动化转换 1.0 版本流到 2.0 版本语法的工具。

开始使用 Web Flow 2 的最佳方法是评估分发包中包含的 参考应用程序,并结合 参考指南。 Spring Web Flow 2 需要 Spring Framework 2.5.3 和 Java 1.4 或更高版本。

请参阅下面的 2.0.0 RC1 版本中新增和值得关注的内容

2.0.0.RC1 新增和值得关注的内容

  • 引入了 Web Flow 2 参考指南,提供 PDF 和 HTML 格式。新指南采用“快速参考”风格编写,并包含可运行的代码示例。您可以在线上阅读,或下载可打印的PDF
  • 增加了从 Web Flow 1 升级到 2 的支持。此分发包中包含一个WebFlowUpgrader工具,能够将流从 1.0 版本语法转换为 2.0 版本语法。请参阅参考指南了解如何使用此工具的说明。
  • 增加了流定义继承的支持。通过此功能,一个流可以扩展一个或多个流。一个流状态也可以扩展另一个状态。此功能用于促进共享通用结构的流和状态之间的重用。
  • 引入了 Spring Portlet MVC 支持。请参阅参考指南的 Portlet 部分以及 booking-mvc-portlet 和 booking-faces-portlet 示例应用程序以获取示例。
  • 正式引入了新的“Spring Javascript”模块,包含在 spring-js-2.0.0.RC1.jar 中。该模块提供了一个 Javascript 抽象框架,用于以一致的方式应用客户端行为,例如表单验证和 Ajax。它还捆绑了一个 ResourceServlet,用于从 jar 文件(包括 CSS 框架)提供 Javascript 和 CSS。该框架构建的默认 UI 工具包是 Dojo 1。Spring 的 JSF 集成模块称为“Spring Faces”,它构建在 spring-js 之上,提供了一个轻量级的 JSF 组件库,用于表单验证和 Ajax。
  • 增加了 Spring Faces 与 RichFaces JSF 组件库的集成。Rich Faces 可以与 Spring Faces 组件库一起使用,也可以独立使用。我们JIRA 系统提供了一个说明此集成的示例应用程序。
  • 添加了一个“jsf-booking”参考应用程序,该应用程序提供了传统 JSF Web 应用程序与使用 JSF 作为 UI 组件模型的 Spring Web 应用程序之间的比较。将 jsf-booking 与 booking-faces 进行比较,以了解架构方法和实现上的差异。此比较对于有兴趣了解更多关于 Spring 的 JSF 开发人员尤其重要。
  • 引入了对 Spring MVC 自动模型绑定和验证的支持。此支持提供了传统手动 FormAction setupForm 和 bindAndValidate 调用的简洁替代方案。此支持还允许应用程序范围内注册数据输入 Formatters,在许多情况下减少了在视图之间手动注册 PropertyEditors 的需要。提供了用于在事件(如取消按钮点击)时抑制数据绑定的支持。提供了按约定调用验证器的支持。请参阅 booking-mvc 示例。
  • 引入了视图作用域。视图作用域在视图状态进入时分配,在视图状态退出时销毁。此作用域对于在一系列 Ajax 请求中更新特定于单个视图的模型很有用。它也是用于管理 JSF 组件状态的作用域。
  • 增加了对流消息包的支持。在流的工作目录中为需要支持的 Locale 创建一个 messages.properties 文件即可开始使用。
  • 引入了可配置的视图状态历史策略。视图状态可以保留其历史记录以支持回溯,丢弃其历史记录以防止回溯,并使所有先前历史记录失效以在不可返回点后禁止回溯。请参阅视图状态元素上的新 'history' 属性。
  • 改进了流执行快照过程。这些改进会在回发时捕获视图状态表单值,以支持在回溯时恢复这些值。这会在使用浏览器回退按钮通过流作用域中存储的数据进行回退时保留编辑。
  • 通过允许您跳转到任何状态来开始测试用例,简化了流执行测试。请参阅 booking-mvc 和 booking-faces 了解流测试用例的示例。
  • 改进了 booking-mvc 作为显示 @Controllers 和 Flow 的参考应用程序。新的 FlowHandler 概念在 Controller 和 Flow 之间提供了清晰的桥梁,允许这两种类型的处理程序以结构化的方式进行交互。还改进了参考应用程序 Spring 配置的组织,以说明最佳实践。
2.0.0 Final 即将到来!尽情享受!

获取 Spring 新闻通讯

通过 Spring 新闻通讯保持联系

订阅

领先一步

VMware 提供培训和认证,助您加速进步。

了解更多

获得支持

Tanzu Spring 提供 OpenJDK™、Spring 和 Apache Tomcat® 的支持和二进制文件,只需一份简单的订阅。

了解更多

即将举行的活动

查看 Spring 社区所有即将举行的活动。

查看所有