I'm pleased to announce the release of PicketLink 2.5.0.Beta3. This release is actually the successor to 3.0.0.Beta2 - we've changed the version number to help avoid confusion going forward, if you want the nitty gritty details about this decision then you can find out more below.

In case you don't know what it is, PicketLink is a security framework for Java EE applications. If you are already familiar with Seam Security, then you might consider PicketLink to be its spiritual successor. For more info about its features check out this overview.

As always, here's the direct links to the various resources for this release:

PicketLink 2.5.0.Beta3 Distribution Zip

Reference Documentation

API Documentation

Source on GitHub

Report Issues

Mailing List

Mailing List Archives

Forums

For those of you that use Maven, we've made a slight change to the artifact ids - from now on a typical application will only need to declare the following dependencies:

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-api</artifactId>
  <version>2.5.0.Beta3</version>
</dependency>

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-impl</artifactId>
  <version>2.5.0.Beta3</version>
  <scope>runtime</scope>
</dependency>

<!-- Optional database schema when using Identity Management with JPA based Identity Store -->
<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-idm-schema</artifactId>
  <version>2.5.0.Beta3</version>
  <scope>runtime</scope>
</dependency>

For this release, the reference documentation has received some special attention and so should be significantly more informative than previous betas. With that being said, the team is constantly improving the docs and will continue to add more content right up to the final release. There are also numerous quickstarts planned to help you get up and running quickly with the many security features provided by PicketLink - I'll be posting some more info about some of these shortly so keep an eye on this space.

There have also been a substantial number of bug fixes, new features and improvements made since the last beta release, the details of which you'll find in the release notes below.

As always, the PicketLink team is available to chat with at various times of the day on the #picketlink IRC channel at freenode.net; also feel free to drop them a line at the PicketLink Forums if you need help using PicketLink in your own application.

Version Change

If you've been following any PicketLink-related news lately, you'll know that the PicketLink team has been working hard towards releasing PicketLink 3 in the very near future. It has recently come to the team's attention though that there is some confusion surrounding the versioning of PicketLink, which is due to a couple of reasons; firstly, there is an existing committment to support PicketLink Federation 2.1 in EAP (the supported version of JBoss Application Server, recently renamed to WildFly). Secondly, there was never an actual 2.x release of PicketLink IDM (it was only ever officially released as version 1.x). Because of this, and since the PicketLink Federation that was planned to be released as 3.0 is actually backwards compatible with 2.1, the team has decided to rename the 3.0 release to 2.5. So what does this mean exactly? Well, besides the change in version number, not much at all really - PicketLink 2.5 will still include all of the next generation security features that the PicketLink team have been working on over the past months. We apologise for any inconvenience that this change might have caused, however the team felt it was best to resolve this confusion now, before the final release.

Release Notes

Bug

• PLINK-116 - Change scope for JBoss Logging dependency in picketlink-common module to provided
• PLINK-119 - DefaultIdentity is considering the User.id when comparing with the DefaultLoginCredentials.userId
• PLINK-131 - Signed logout request does not contain the "Destination" attribute
• PLINK-132 - PicketLink based SP's need to support different login and logout URLs
• PLINK-136 - The IDM subsystem is always initialized even when a custom Authenticator is provided
• PLINK-137 - Change the scope for CDI dependencies in picketlink-api and picketlink-impl to provided

Enhancement

• PLINK-126 - Introduce individual annotations for JPA schema entities and properties
• PLINK-135 - Add type parameters to CredentialHandler

Feature Request

• PLINK-113 - Users should be able to use a IdentityManager for any of the configured realms.
• PLINK-117 - The API documentation should aggregate the javadocs for the modules
• PLINK-118 - Update documentation with the File and LDAP stores configuration
• PLINK-120 - Login logic is not considering when the user is disabled/locked
• PLINK-121 - Throw a specific exception when the user tries to authenticate twice using the same credentials
• PLINK-124 - Add credential storage retrieval methods to IdentityManager
• PLINK-127 - CredentialHandler implementations should check if the Agent is disabled
• PLINK-128 - Refactor the Configuration API to provide a Fluent API using the build pattern
• PLINK-142 - Provide more examples about how to mix identity stores

Task

• PLINK-92 - Container Bindings Project
• PLINK-122 - Provide test cases for the base module
• PLINK-125 - Umbrella task for 2.5.0.Beta3 documentation issues
• PLINK-129 - Import the container bindings modules from PicketLink v2
• PLINK-133 - Use getAgent() instead of getUser() throughout authentication API
• PLINK-138 - Change project version from 3.0.0 to 2.5.0

I recently had the pleasure of attending Red Hat's first JUDCon event in APAC, JUDCon India. The conference was hosted by Saltmarch Media in the Nimhans Convention Centre in Bangalore, and ran for 2 days. The sessions were organized into 3 separate tracks:

• JBoss Application Server 7
• OpenShift and Cloud
• Rules, Workflow , SOA and EAI

It was a great opportunity to be able to interact with so many other JBoss developers and users, and with an attendance of around 800 people it was the biggest JUDCon ever. There was a high level of energy in the atmosphere, and most sessions were packed full of people, some with standing room only. It was also great to see so much interest in JBoss technologies - the sessions I attended (and presented) all received a substantial number of questions at their conclusion, sometimes even running into the next session. On the first evening of the conference we held an open Q&A session, allowing the audience to ask whichever questions they liked to a panel of JBoss project leads and experts.

All in all, it was an awesome event. If you are interested in attending a JUDCon, then don't worry, you'll get another chance! The next one will be held in Boston - If you are able to attend, I highly recommend you do as you won't get a better chance to network with the core developers at JBoss.

We'll also be making the videos of the sessions available online, so keep an eye out for them soon!

I'm pleased to announce the immediate availability of Seam 3.1 Final.

Links:

Download Seam 3.1.0.Final bundled distribution

Reference Documentation

API Documentation

Report issues

Maven users, please update your project to include the following:

<dependencyManagement>
   <dependencies>
      <dependency>
         <groupId>org.jboss.seam</groupId>
	 <artifactId>seam-bom</artifactId>
         <version>3.1.0.Final</version>
         <scope>import</scope>
         <type>pom</type>
       </dependency>
    </dependencies>
</dependencyManagement>

What's changed since Seam 3.0?

Existing modules

Solder

The Solder module now incorporates an exception handling framework (formerly Seam Catch), XML-based configuration (formerly Seam Config) and Servlet integration (formerly Seam Servlet). The integration of these core features into Solder means they will now be available without having to declare an explicit dependency on them.

Seam Transaction

Previously part of the Seam Persistence module, Seam Transaction is a new module that provides transaction-related features for your POJO-based beans.

New modules

Seam Social

The Seam Social module provides various useful integrations with social networks such as Twitter, Facebook and LinkedIn.

Seam Reports

Seam Reports integrates with a number of reporting engines to provide report generation features from your Seam application.

Seam JCR

The Seam JCR module allows easy interaction with a JCR (Java Content Repository) repository, and currently supports both Apache Jackrabbit and Modeshape implementations.

Seam Spring

The Seam Spring module allows you to integrate your Spring application with CDI, allowing injection of Spring beans into your CDI bean, and the injection of your CDI beans from a Spring application context.

Seam JMS

The Seam JMS module allows you to inject JMS resources, such as Connections, Topics, Queues and more directly into your beans, and also provides a bidirectional bridge between the JMS message bus and CDI, allowing JMS events to be propagated to the CDI event bus, and vice versa.

Seam Mail

Seam Mail provides a number of features that makes working with JavaMail easier, and comes with a pluggable template engine for the composition of mail content, and simple mail server configuration options.

Fixed Issues

In additional to the new modules listed above, we've also resolved 249 issues identified with the Seam 3.0 release as well as numerous documentation and example improvements.

Enjoy!

I'm happy to announce the immediate availability of the first candidate release for Seam 3.1. Here's the usual links:

Download Seam 3.1.0.CR1 bundled distribution

Reference Documentation

API Documentation

Report issues

Maven users, please update your project to include the following:

<dependencyManagement>
   <dependencies>
      <dependency>
         <groupId>org.jboss.seam</groupId>
         <artifactId>seam-bom</artifactId>
         <version>3.1.0.CR1</version>
         <scope>import</scope>
         <type>pom</type>
       </dependency>
    </dependencies>
</dependencyManagement>

This release is now feature complete - we will only be working on bug fixes and quality issues leading up to the 3.1 final release, which can be expected in mid December. I encourage everyone to try it out, and let us know if you experience any issues with it by using the Report issues link above.

Note - the version of Solder that was included in the seam-bom of this release is incorrect, however this should not have any adverse effects.

I’m very happy to announce the details for the first phase of our Seam.Next plan. I’d like to thank everyone for waiting patiently while we worked on this, and for providing feedback either directly via e-mail or IRC, or through the Seam forums. I’d also like to thank the module leads, key community members and other people that were involved in helping to shape this plan, it was very much a collaborative effort and we are very excited about the ideas and goals that were discussed and direction going forward.

Before I get into the nitty gritty of the details, I’d first like to describe the motivations for wanting to make such significant changes, and talk about the overall goals that drive us. I think the best starting point for describing this is Seam 2.

Seam 2

Looking back at how we did things in Seam 2, I think it’s safe to say that many of the aspects of the framework were quite successful. I think that one of the most defining factors of its success was the integration - Seam 2 provided the core framework features (Dependency Injection, Contexts, Events, etc) and enough useful features built on top of that core framework to make application development quite a productive activity.

It also provided integration with a number of third party technologies, such as Drools, jBPM, Wicket, Spring and others. On top of that, it provided excellent documentation that tied the whole lot together, and did a pretty good job of bringing new developers up to speed, and not to mention decent tooling in the form of seam-gen and JBoss Tools.

All in all, Seam 2 has proven to be a mature, well rounded framework that solved many of the problems that developers face when building modern web applications.

Along Came CDI

CDI changed everything. By standardizing many of the core framework features of Seam and making them part of the Java EE platform, with an added focus on type-safety and extensibility, there is no longer a requirement to BYO framework - any compliant Java EE 6 container provides a comprehensive programming model out of the box, without having to supplement it with additional libraries to provide core services.

This was a great step forward - writing your application against a standard is a good thing. It helps you to avoid vendor lock-in, and means that as a developer your knowledge is portable. It also puts you into a great position for tapping into a growing ecosystem of extensions and tooling.

CDI Everywhere

Since CDI was released, one of the principles underlying all our work is that of CDI Everywhere. By enabling CDI support in as many places as possible, our goal is to make developer productivity stronger than ever. To that end, we have been encouraging and assisting other project teams to provide CDI integration directly from their own projects. We believe this is one of the key ingredients in strengthening the CDI ecosystem, and providing an environment where the developer can concentrate more on solving business problems and less on fighting with his tools.

This of course means that you no longer require an integration framework like Seam to provide support for a number of CDI-enabled technologies, such as Drools and jBPM (CDI support coming soon), GWT, Wicket and many others. Furthermore, since the tooling we provided for Seam 2 (i.e. seam-gen and JBoss Tools) was based on its proprietary core framework, any new tooling going forward should naturally be focused on the now standards-based component model provided by CDI. This is the reason why Forge is now a standalone, top level project in its own right, with a focus on building Java EE applications.

Seam 3

Looking at the previous diagram, we can now see that as a result of standardization, quite a few of the bits that made up Seam have moved outside the scope of the original project. This has meant a change in focus for Seam. Instead of providing a fully integrated framework stack, Seam 3 has taken the remaining bits and turned them into a collection of portable extensions for CDI. Essentially, what we did was implement many of the most useful features that were present in Seam 2, as well as adding a number of new features, in a modular structure so that Java EE developers can easily add support for these features to their application by simply dropping a jar file into their project.

At this point, in hindsight we think we made a poor choice here by calling this new project Seam 3, seeing as the nature of the project has changed so drastically from the previous version. While it is most definitely a worthwhile goal to create a set of useful extensions for CDI, Seam 3 by itself is no longer the fully integrated framework stack that Seam 2 was. As a direct result of this change in focus many of you have been disappointed with the documentation and getting started experience for new users.

What do users want?

The feedback we received from the community covered a broad spectrum of concerns, however there were some common areas such as:

• Documentation
• Getting Started Experience
• Tooling
• Lack of Drools/jBPM support
• Lack of certain features, e.g. entity framework
• Lack of migration guide

Underlying these, we also noticed two strong messages:

• Some developers are interested mainly in portability. They don’t want their application locked into any particular container implementation, and it’s important to them that they have the freedom to use the framework in different environments.

• Many developers just want an end-to-end framework that works, without having to piece together all the bits themselves and work out how to integrate them. They don’t want to have to read multiple sets of documentation from different projects, and their primary requirement for an application framework is productivity, i.e. getting the job done quickly and efficiently.

So the question is, how can we return to the fully integrated framework stack and productivity that Seam 2 provided, and also provide a set of portable extensions, optionally consumed a la carte, that will run in any environment where CDI is present? We’ve been working with community leaders and module leads, and have come up with a proposal that we think will rise to the challenge of addressing these concerns.

The first step we will take is to create a community-owned set of portable CDI extensions; a de-facto set of features that developers can take and use within their own applications, in whichever container they wish to deploy to. One of the major goals of this project is to grow and unify the Java EE community. By joining forces with other CDI extension developers, such as the Apache MyFaces CODI team and the CDISource team, as well as other key members of the Java EE community, we are creating a community that is stronger than the sum of its separate parts.

This must be a real community project, without any corporate affiliation to ensure that the project remains neutral. We’ve identified Apache as being a great place to host this project, as they are a non-profit organization with no corporate agenda, and have a strong reputation in the community for producing successful open source projects. So without further ado, let me introduce the Apache DeltaSpike project.

Apache DeltaSpike

By the time you’re reading this the proposal for Apache DeltaSpike has been submitted to the Apache Incubator and begun the process toward becoming a top level Apache project. DeltaSpike is a set of portable CDI extensions, built collaboratively by the Java EE community. It will be seeded by code contributed from various Java EE open source vendors, and provide a number of essential features for building enterprise applications. Portability will be the main principal of this project, satisfying the need of many developers for a framework that will run in a number of different environments.

After its initial release, the existing Seam development team (consisting of both full time and volunteer contributors), along with the MyFaces CODI team, CDISource team and other members of the greater Java EE community will carry out ongoing development on DeltaSpike - this includes the creation of new features and innovations, bug fixes and other enhancements. While it is not my place to talk about the release schedule for DeltaSpike (this is decided by the Apache DeltaSpike Podling Project Management Committee (PPMC)), I am 100% confident that it will be a lively, active project that receives the attention and contributions that it deserves, and produce many ongoing releases.

The first release of Apache DeltaSpike will consist of a common core, a set of extensions that will provide the base on which to build other extensions. It will be tested extensively across multiple Java EE containers to ensure portability, and provide a solid foundation for the development of other features. Eventually the plan is for Apache DeltaSpike to incorporate many of the features that you can find today in Seam.

An Integrated Framework

We have also mentioned that we’d like to address the needs for developers that require an end-to-end development stack. While we’re still working out the details for this, I’d like to reassure everyone that it is a high priority for us to provide a fully integrated framework in the spirit of Seam 2 but with even better productivity. We have some great ideas in motion to provide a full integrated framework for your needs. We know you’ll be excited as we are about what’s in store, so please watch this space over the coming months for more details.

What about Seam?

For those developers who have already invested heavily in Seam, don’t worry, we’re looking after you also. We’ll be continuing development on Seam 3 for the foreseeable future, in fact Seam 3.1 which is due for release shortly contains a number of exciting new modules and other improvements. We’d like to also reiterate that we are fully committed to the Seam Community - the initiatives that we’ve described above are all for the benefit of you guys, to give you the most productive framework and tools for building your applications that run the world. We ask that you be patient with us as we roll out this vision over the coming months, and thank you for your continued support.