Red Hat's JBoss division have a number of updates in the pipeline for the next couple of months, including major new releases of their web application framework Seam, and JSF component library RichFaces. InfoQ spoke to Pete Muir, a Principal Software Engineer at Red Hat, about what is coming, and his own move from the Seam team to the Infinispan data grid team.
InfoQ: Congratulations on your move over to the Infinispan team. What prompted the move?
Thanks. Most people I talk to, especially software engineers, have work cycles where they start off really enjoying the project they are on, and over time that enjoyment fades. I decided to seek a new challenge as I could feel I was reaching the end of my enjoyment cycle with Seam and Weld. Infinispan seemed like a natural choice, I had previously worked with data grids as part of my masters thesis, and, as Red Hat is increasing its investment in Infinispan, it fits well with the company goals.
InfoQ: What are your plans for Infinispan?
Personally, I will be starting off by looking at virtual nodes. Infinispan uses a consistent hash wheel to ensure deterministic, fast and low overhead lookup of data in a distributed environment. However even with a number of techniques to ensure an even distribution (such as using MurmurHash and a bit spreader), users were reporting that data grids with small numbers of nodes weren't showing a good distribution of data (leading to overloading of certain nodes, both with processing and data storage), however grids with larger numbers of nodes don't suffer from this problem. Virtual nodes help as they provide multiple nodes per physical node.There are a number of other exciting improvements in Infinispan 5, and I want to discuss a couple.
MapReduce, already available in Alpha 2 is the first. Infinispan offers essentially unlimited linear in-memory data scaling, however having such a data grid without an ability to execute large scale computation on it is like having a Ferrari without a driver's licence. We listened to the criticism regarding the lack of direction in Big Data field and the complexity of existing distributed execution frameworks; our focus was primarily on simplicity without sacrificing power and a rich feature set. You can read more about Infinispan's MapReduce at Vladimir's blog.
We're also working on Hibernate OGM (object-grid mapper). Hibernate OGM reuses the Hibernate Core engine but stores your entities in Infinispan (and eventually any key/value store) rather than a relational database. You map and manipulate your entities like you do in JPA / Hibernate (same mapping, same APIs). Hibernate OGM as it stands supports CRUD operations and most JPA mappings. We are also working on query support which will start with a subset of JP-QL and grow over time. This project is still in its early stages but the long term goal is to support most if not all of JPA functionalities. You can check out more details at http://community.jboss.org/wiki/HibernateOGMGeneralInformations. If you are interested in getting your hands dirty then get in contact with Emmanuel or Sanne via the forums.
InfoQ: I understand that you will be EG lead for CDI 1.1? What are your plans for CDI 1.1?
I will be leading the EG for CDI 1.1 - in fact I've just finished the first draft of the JSR proposal and am collecting feedback before it is made public. We feel that CDI 1.0 has had a very positive reception in the community, and that in general people are able to achieve what they need with the current functionality. However, there are a few minor rough spots; these fall into two categories - there are those that we knew about when we released CDI 1.0, but because we didn't have time to explore the correct solution left for a later date, and, of course, some unexpected issues. CDI 1.1 aims to address these rough spots, as well as to standardize a few of the most popular extensions the community has built. We don't plan to add any major new areas of functionality. A few of the things you can expect include:
- Global ordering of interceptors and decorators, as well as global enablement of alternatives
- An API for managing built in contexts, allowing the built in implementation of the conversation context to be used outside of JSF
- An embedded mode allowing startup outside of a Java EE container
- Bean declaration at constructor level
- Static injection
- Inclusion of @Unwraps from Seam Solder
- Numerous minor enhancements to the Portable Extensions SPI
- Client controlled contexts
- Better support for CDI in libraries when used in the Java EE platform
- Send CDI events for Servlet events
- Application lifecycle events
InfoQ: There were a number of comments on Twitter and the blogs (for example here) towards the end of last year concerning memory issues and performance problems in Weld, the reference implementation for JSR-299 (CDI). I know you said at the time you were looking to improve the situation. How much progress has been made?
I'm glad to say we made a lot of progress! We saw improvements in memory usage, boot time and runtime performance. Our measurements showed a two fold improvement in boot time with just a few beans in the deployment, but with many beans, we were showing more than a 10 fold improvement. Memory usage had a consistent 4 fold improvement, regardless of the number of beans deployed. There was a 40% improvement in runtime performance, and we saw that Weld performs as well as, or better than other CDI implementations available, as well as other solutions in the DI space.These improvements are all included in Weld 1.1.0 (which is included in JBoss AS 6 and GlassFish 3.1), and we do plan further improvements, especially around memory usage, with Weld 1.2 (which will be included in JBoss AS 7). The eventual aim is for Weld to use around 1k per bean.
InfoQ: I know a number of teams are waiting for Seam 3 and RichFaces 4 before moving to JSF 2. RichFaces 4 is expected in March I believe but do you know when Seam 3 is likely to be available? Are there any plans to add JSF 2/Facelets 2 support for Seam 2 in the interim?
We're also aiming to complete Seam 3 by March. Beta 1 is available now and contains all the modules that will make up Seam 3 such as:
- Seam Security, which adds enhanced authentication and authorization features beyond those provided by the Java EE specification, plus federated identity features for seamless integration with OpenID and SAML
- XML Configuration, providing a way to configure your CDI-based application via XML
- Seam Faces, adding to the features of JSF 2 and providing important JSF integration points to other Seam modules
- Seam Catch, which provides developers with a unified and robust exception handling process
- Seam Wicket, integrating the CDI component model and other Seam modules with Apache Wicket
- Seam International, providing localized services to your CDI-based application
- Seam Remoting, an Ajax-based framework for invoking your CDI beans directly from a web page
... and many more!We just released Seam 2.2.1 which had as a primary target good support for Seam 2 on JBoss AS 6 running JSF 1.2. We've long been debating expending effort on adding JSF 2 support to Seam 2 (which would slow down work on Seam 3) or sticking with JSF 1.2 support. We are currently planning a Seam 2.3 release which will provide full support for JSF 2. In the meantime, various community members have stepped up to the plate, and provided a fork of Seam 2.2 which does work with JSF 2 such as https://github.com/heyoulin/seam2jsf2 for which we are very grateful!
InfoQ: What can we expect to see in RichFaces 4?
RichFaces 4 is our release of RichFaces targeted at the new Ajax features from JSF 2. In brief:
- Full JSF 2.0 support and extensions
- True client-side validation integrated with both Bean Validation (JSR-303), or the standard JSF validators
- Large set of redesigned, and optimized components
- Client push integration with Atmosphere
- Consolidated dataTable design provides flexibility and ease of use
- Google App Engine support
- Advanced queueing of Ajax requests
- Dynamic resource support
InfoQ: I was interested that JBoss AS 6 has been certified against the Java EE 6 Web Profile only. Why are you not supporting the full Java EE 6 spec? What does the move tell us about the EE 6 market?
The goal for AS 6 was to pass the Web Profile TCK as quickly as possible so we could promote some of the new and exciting technologies (like CDI) with a full JBoss run-time as soon as possible. Because AS 6 was built on the AS 5 code-base (which is a full EE 5 implementation), AS 6 does include additional JSRs as well.People shouldn't read too much into this - we're not turning our back on EE, we're simply trying to move as fast as we can because we see a lot of excitement around Java EE 6 - getting a JBoss Web Profile server out is an important milestone and you'll see us building on that for full EE 6 certification as part of the community roadmap for AS 7 and then a fully supported Red Hat product later this year.
