I'm pleased to announce the immediate availability of Seam 3.1 Final.
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>
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.
Previously part of the Seam Persistence module, Seam Transaction is a new module that provides transaction-related features for your POJO-based beans.
The Seam Social module provides various useful integrations with social networks such as Twitter, Facebook and LinkedIn.
Seam Reports integrates with a number of reporting engines to provide report generation features from your Seam application.
The Seam JCR module allows easy interaction with a JCR (Java Content Repository) repository, and currently supports both Apache Jackrabbit and Modeshape implementations.
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.
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 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.
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.
In my previous blog about Brian Leathem becoming the RichFaces project lead, I mentioned that the release of RichFaces 4.1 is imminent. It is not longer imminent, but upon us!
I'm very happy to say that today Brian announced the release of RichFaces 4.1.0.Final!! This is a great release for RichFace and JSF, please take a look at Brian's blog for all the details, and keep an eye out for some follow up blogs highlighting the new features!
The release of RichFaces 4.1 is imminent and with it brings some great advancements to the project and JSF! Among the most notable are additional mobile support, push upgrades, new components, and more.
Recently however, I’ve been focusing on more general mobile and HTML5 initiatives. You can see some of what I’ve been up to in the webinar I had Wednesday Dec. 7th on getting started with HTML5/Mobile development with JBoss (recording will be available soon).
This has meant that I’ve not had the time to dedicate to RichFaces that it deserves, and so I’m thrilled that we have an engineer and leader like Brian Leathem who has agreed to lead the project into the future!! He is already the seam-faces project lead, and has been a critical member of the RichFaces for some time!
Brian and the rest of the RichFaces team have not only done a great job on RichFaces 4.1, but also have some great plans for the future of RichFaces. Brian has started to outline these to start the discussions. This is only going to pick up steam once 4.1 is out!!
I’m not just going to disappear though, mobile and HTML5 are certainly an integral part of RichFaces! Keep an eye out in this space for more from me and JBoss about all aspects of mobile application development including mobile web, hybrid, and native techniques.
I wanted to take a moment and thank the RichFaces team and community! I’m could not be more proud of the people that use and develop RichFaces. Through our forums, weekly meetings, and now github we’ve seen a huge increase in contributors, users, and colleagues. To all of you:
For those of you tracking Seam 3 releases and bug fixes, you might have seen SEAM-99 was fixed with Seam 3.1.0.CR1 we released last week. I just discovered a small gotcha when using non-JTA transactions. If you are, your EntityManager must not be scoped @ConversationScoped or it will fail on every request.
We prefer JTA and hope the majority of our users do as well, but some may choose to simply use transactions from the EntityManager, which is fine too. Just be aware of that little gotcha if you are not using JTA.
I'm happy to announce the immediate availability of the first candidate release for Seam 3.1. Here's the usual links:
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.
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.
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.
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.
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.
The feedback we received from the community covered a broad spectrum of concerns, however there were some common areas such as:
- Getting Started Experience
- 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.
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.
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.
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.
I'm happy to announce the release of Seam 3.1.0.Beta5. This will be the last beta release for Seam 3.1, the next release will be CR1 and our plan is to have it available by the end of this month. We had planned to have a quickened release cycle leading up to CR1, however in the interest of including new modules in this release (namely Seam Spring - see Marius' announcement here) we had to extend the release timetable, so we thank you for your patience.
As usual, here's the links for the download and documentation:
It took a while to release it (due to other work that needed to be completed first), and it took me a couple of weeks to announce it (i.e. until now), but my bit of news for today is this: the first release of our CDI Spring bridge, aka Seam Spring 3.1.0.Alpha1 is out.
This first release provides:
- facilities to bootstrap Spring contexts or access outstanding Spring contexts (e.g. web contexts bootstrapped by the ContextLoaderListener)
- facilities to import Spring beans as CDI beans (thus making them available for standard CDI injection)
- facilities to import CDI beans an Spring beans (thus making them available for Spring injection), including dedicated namespace support
As this is an Alpha, I am looking forward for feedback, new feature suggestions (even suggestions on prioritizing certain items that we have on the roadmap). Please use it extensively, and file bug reports(they're inevitable, and the sooner, the better).
Usage examples can be found for now in the Arquillian tests of the project source code, and I will follow up with a post describing a detailed example pretty soon.
As per usual, let's get the links out of the way first:
For Maven users, there is a new version of the Seam Bill of Materials:
<dependency> <groupId>org.jboss.seam</groupId> <artifactId>seam-bom</artifactId> <version>3.1.0.Beta4</version> <type>pom</type> <scope>import</scope> </dependency>
I know that we promised a CR1 release for Seam 3.1 at about this time, however the Seam QA team have done their jobs a little too well and identified a number of issues with the Beta3 release which we wanted to get fixed before we go to a candidate release. The great news for this release is that we've fixed 68 issues - you can view the issue list here:
Included in this release is a number of new features, improved documentation and a brand new Arquillian-based structure for our test suites to make it easier to test each module on multiple containers. We've also squashed a great deal of bugs, improved stability, plus made a number of other minor improvements.
As we still have quite a few open issues remaining for the Seam 3.1 release, we will likely release another beta in the next couple of weeks. We want this release to be rock solid, so please try out the beta and let us know if you find any problems.
I'm very pleased to announce the release of Seam 3.1.0.Beta3. Let's get all the links out of the way first before we get into the details of the release:
Maven users - please update your seam-bom version:
<dependency> <groupId>org.jboss.seam</groupId> <artifactId>seam-bom</artifactId> <version>3.1.0.Beta3</version> <type>pom</type> <scope>import</scope> </dependency>
The biggest changes we have made are around the Solder module. Since this library is so integral to CDI extension development we've decided to make it a top level project at JBoss. Besides a package name change though (from org.jboss.seam.solder to just org.jboss.solder), this change doesn't affect how Solder will be used within Seam -it will still be distributed as part of the Seam project and continue to be a responsibility of the Seam team.
We also reviewed our existing modules and decided that the Seam Catch, Config and Servlet modules were integral to nearly all application development and so have merged their features with the Solder module. This move is a win-win for everyone, because it means that you the developer have a few less dependencies to worry about (just add Solder to your project and you get all these additional features for free), and it's also good for Seam development team because we have 3 less modules that we need to maintain infrastructure for.IMPORTANT! Please remember to remove the Seam Catch, Seam Config and Seam Servlet modules from your project before upgrading to 3.1.0.Beta3.
The logging API has also undergone some substantial improvements, thanks to Ken Finnigan. Since it is part of the Solder module you will need to update your imports if you want to use typesafe logging in your application. To use it in your own project, simply import the Logger class:
Then inject the logger into your bean:
@Inject Logger log;
It's as easy as that!
One of the things we delivered in the Seam 3.0 release was combined jars - jar library files that bundled both the API and implementation jars of a module into a single jar file. We've come to realise that while the API/implementation split was a good idea, the combined/shaded jars were causing problems for some people. We've since removed the combined jars from all of the modules, and now simply provide separate API and implementation jars. To maintain backwards compatibility, we've renamed the implementation jars to correspond with the previous naming of the combined jars. A little confused about this? Let's look at an example to make it clearer; in the 3.0 release we provided the following jar files for Seam Persistence:
The first two jars listed here contained the interfaces and classes for the API and implementation for the Seam Persistence module. The third jar is simply a repackaging of the first two jars - seam-persistence.jar just contains everything that's packaged in seam-persistence-api.jar and seam-persistence-impl.jar. This was done for convenience, so that you would only need to add a single dependency for your project if you wanted to use Seam Persistence - here's what it would look like in your Maven pom.xml:
<dependency> <groupId>org.jboss.seam.persistence</groupId> <artifactId>seam-persistence</artifactId> </dependency>
Contrast that to what we have in the latest release:
The first jar file, seam-persistence-api.jar remains unchanged. The second jar file, seam-persistence.jar is actually now the implementation (which was previously called seam-persistence-impl), and the third jar file (which was called seam-persistence.jar) has now gone away. This means that if you have an existing dependency on seam-persistence, it will now be a dependency on the implementation itself, not on the (previously) combined jar. Since the implementation has a transitive dependency on the API, it gets pulled in automatically. I hope that makes sense, if you're still confused please let us know in the comments!
I'm very excited to announce the addition of a number of new modules for this release.
Seam JCR is a portable extension for CDI that allows you to work more easily with JCR (Java Content Repository) repositories. It currently supports Modeshape and Apache Jackrabbit.
Seam JMS makes JMS (Java Messaging Service) much easier to use in a CDI environment, and allows bridging between JMS endpoints (such as topics and queues) and the CDI event bus.
Social networking comes to Seam! Seam Social provides a number of integrations with Facebook, Twitter and LinkedIn to allow you to easily interact with these services directly from your CDI-based application.
The long awaited Seam Mail module is making a comeback from Seam 2. This module allows you to generate and send e-mail from your CDI application, and unlike in Seam 2 the mail templating is no longer based on JSF but on Freemarker or Velocity instead, meaning you can use it in your non-JSF application. We're still working on the docs for this module, so we ask that you're patient while we get them ready in time for the CR1 release.
We're going to have a relatively short cycle between Beta3 and the CR1 release, with a release date of 18 October as the target for CR1. We welcome any feedback from our users and we encourage you to try out Beta3 and let us know of any issues you find.