I wanted to follow up all the great content from Dan Allen on JSFSummit with some of my own, but from a component libraries point of view. One of the really nice things about speaking at a conference like JSFSummit is that you know the attendees are going to be knowledgeable and are likely already using JSF. This meant that speakers could really talk about the details of their topics. For example my talk on RichFace Component Toolbox was able to show users some of the advanced components and features of RichFaces including code examples and a demo (cruel demo gods aside). Something else that JSFSummit and NFJS get right is the length of the sessions, with 90 minutes we could really cover a lot.
There was a very strong showing at JSFSummit, and this included the leads from several of the top JSF component libraries. There was Andy Schwartz from ADF Faces, Ted Goddard from ICEFaces, Cagatay Civici from PrimeFaces, and Me representing RichFaces All represented in this rare picture!. You might think that because technically we all have competing projects that this could be testy. I'm very happy to say that is not the case.
All of us, and the rest of the JSR-314 (JSF 2.0 ) expert group had many productive and enlightening discussions. Some of these were late night at the previously mentioned Thirsty Fish at the conference hotel, other were at lunch, in meeting rooms, or even during some of the talks. As Dan said there was no barrier between speakers and attendees and many times we would attend each others talks. This would sometimes spark conversations that started to sound more like a expert group meeting than a presentation. This would usually involve how to work XYZ feature or behavior into the next version of the spec. The great thing about this was that everyone participated, and voiced their opinions.
One of the large discussions involving the various component libraries involved proving one of the tenants and goals of JSF 2.0. That was interoperability, between component libraries so that developers could combine component libraries when ever needed. I am very keen on this topic, and pushed for the different libraries to collaborate on a combined example application. Perhaps we pull a data table from RichFaces, a tree from IceFaces, a menu from ADF, and a collapsing panel from PrimeFaces. This type of application would really do several things. For one it would provide proof and an example to developers that JSF 2.0 component libraries really can work together. For another it will help us all to shake out the lumps and issues developers will run into with the specification.
This second point should not be underestimated. RichFaces in its development of 4.0 has already found some items that need to be
worked out. These items represent areas of implementation that could cause component libraries to not function together, or could also point out areas in the spec that need more definition. To see a listing of some of these items check out our wiki page. I'll give you an example of one of these issues just so you can get a taste:
JSF 2.0 now has build in Ajax support that is supposed to act as a core Ajax bridge that component libraries are supposed to use. This implementation has a very simple queue associated with it. RichFaces has its own advanced queue functionality from 3.3.X that we want to bring forward to RichFaces 4.0. How do we do this without overwriting the core queue, and stepping on other component libraries toes? A few options have been discussed such as allowing developers to choose a single queue implementation that follows a defined contract so that users can switch implementations as they wish. This would be similar to JSF 1.2 where you could plug in your own view handler, a.k.a. Facelets. Another option that was discussed was to have one core implementation, but when it was a requests turn in the queue it would have full control of its behavior.
Needless to say this was not completely resolved, but gives you a taste of the efforts that will be required to make this all meld. As I said above though, what struck me was the willingness of everyone from component libraries leads, EG members, and Jim Driscoll from the RI team to work together on a solution. In the end this is going to result in a better JSF, and component libraries to go with it
Obviously one of the hot topics was JSF 2.0 support, and more specifically how users can migrate from earlier versions to new versions. This came up at literally every talk that I either gave or went to that discussed JSF 2. Users need a solid path for migration in order to leverage their efforts from the past, while moving forward with the technology. There was even a talk dedicated to migration that Kito Mann gave called Upgrading to JSF 2.
Something that surprised some developers was that although JSF 2.0 is backwards compatible, most of the component libraries could not support JSF 2.0 without some modifications. For RichFaces this is because in order to accomplish some of advanced features with JSF 1.2 we needed to interact with some of the core APIs and internals of JSF. This meant that when JSF 2.0 came along and some of those APIs changed it caused problems. The RichFaces team has been working on a solution to this, and migration strategy for our users.
We are current developing the RichFaces 3.3.3 release which will bring JSF 2.0 compatibly to the 3.3.X release branch. We should be releasing a BETA of this release very soon, and hope to have a final release of this by early next year. With this release users can begin to migrate their applications to JSF 2.0 containers, and environments. Update their own code and begin playing with JSF 2.0. It is important to note that this release is more about compatibility. You'll be able to run your existing applications with JSF 2.0, but the release will not take advantage of JSF 2.0 new features and abilities. This will need to wait for RichFaces 4.0.
RichFaces 4.0 is in parallel development, and we have already had a 4.0.0.ALPHA1 Release. This is the release that will really leverage and push the functionality of JSF 2.0. This will include new behaviors, events, and components, as well as an easy to use Component Development Kit. We hope to continue to push the bounds of the standard and begin prototyping the features that someday will be standardized in another version of JSF. We are currently planning to release 4.0.0 in early summer, but will have lots of interim releases between now and then.
So you might be asking yourself, how do I upgrade from RichFaces 3.3.3 to 4.0.0? We are working on the details of that, but rest assured we'll make it as easy as possible. This will certainly include a migration guide with step by step instructions. We'll likely also have a compatibility bridge of some type that will make migration even easier.
I left JSFSummit feeling very good about a great many things. For one thing Orlando is a nice place to visit in December when you live in New York. More importantly I left feeling very positive about the JSF technology and community. I think JSF 2.0 is a great release that combined with component libraries like RichFaces, and other features in EE6 like CDI and Bean Validation really make an application stack that is hard to compete with. I'm also very excited about RichFaces future, and the great community and developers that we have.
Thanks to everyone that attended, and all the speakers and expert group members that were there!!
As I'm sure you've all seen, Java EE 6 has gone final. You can now download the Final Release of the Contexts and Dependency Injection, Bean Validation, Java Persistence API 2 and Java Servlet 3 specifications from jcp.org, and read the linked javadoc for the entire platform. It's also a good chance to check out the Java API for RESTful Web Services specification, which now includes CDI integration, if you havn't already.
It's just fantastic to finally see the fruits of all that work :-)
Emmanuel and I sat down with Pete and Dan at Devoxx to talk about CDI and Weld.
Dan and Pete present what is CDI and what is Weld.
We discuss how CDI portable extensions allows you to extend and build on top instead of around the standard platform.
And of course you get to hear how Dan and Pete ended up working within the JBoss Community.
Get it all and more from Episode 6 at The Asylum.
Personalizing the experience. That's the primary motif of the NFJS conference series, the brand behind JSF Summit--a conference event focused exclusively on the JSF ecosystem. It's hard to imagine a more personalized experience than the 2009 JSF Summit delivered, held at the Loews Portofino Bay Resort in Orlando, FL. Conversations between speakers and attendees occurred during talks and between talks. Interchanges began at breakfast, continued through lunch and dinner, and carried on until last call at the bar. While most of the time the dialogs were about JSF and related Java EE technology, they also ventured into topics such as religion, relaxation, tastes, travel and writing.
To view the conference from the perspective of an attendee, check out this review by Steven Boscarine, one of our valued community members.
The two major themes of the 2009 JSF Summit were JSF 2 and Java EE 6, and for good reason. On the first day of the conference, the announcement was made that Java EE 6, along with the remainder of its pedigree specifications, were ratified. JSF 2, which touched down more than a half year earlier, was finally joined with its platform; a platform backed by a robust programming model that boasts type-safe dependency injection, contextual lifecycle management and an event notification facility, features introduced by JSR-299. Combined with the countless improvements in JSF 2, the total change and value in Java EE 6 is simply astonishing. The week also saw the release of JBoss AS 6.0.0 M1, a milestone release which implements the Java EE 6 Web Profile and includes many of the technologies in the full Java EE 6 profile.
Ed Burns began the conference by taking us on a journey to some of the places JSF is used in production his keynote JSF Around the World. He replayed interviews that covered how JSF has helped developer productivity and how well it fairs in production. The common message was that JSF makes it easy put applications together and that it scales remarkably well. Most of the customers Ed spoke with either use JSF with Seam or are already putting JSF 2 to use. Tooling was cited as one of the most vital resources for development, with at least one shout-out for auto-completion of Facelets views in JBoss Tools.
The next morning, the conference sessions kicked off with a presentation by myself and Andy Schwartz titled JSF 2: Keeping progress coming. This talk turned out to be a great candidate for the first slot because it gave attendees a broad overview of the new features of JSF 2, helped them select which talks to attend later in the conference to get a deeper dive on a topic, set the stage for participation and placed an emphasis on how forward looking we are, ready to embrace ideas for #jsf2next that are already circulating.
As part of an initiative by the JSF EG to engage the community, the
Keeping progress coming talk concluded with an announcement about the new JSF community site, www.javaserverfaces.org. The goals of this site are to:
- establish a definitive starting point for users to get involved with JSF,
- provide information about JSF, the spec, how to get started, key documentation, how to get involved and other resources to help engage the community and encourage participation, and
- promote JSF as a competitive, inviting solution in the Java web framework community, both at the corporate and developer level
At last, JSF has a home!
Aside from my own talks, I can't comment much on what happened the remainder of the day on Wednesday since I presented in all but one of the time slots. (Keep an eye out for companion posts). In fact, I kept so busy the entire week that I never got to see either of the two pools at the resort or the water slide. (My wife enjoyed them on my behalf).
In the next slot I presented on the Seam and RESTEasy integration with Lincoln Baxter III, who did a fantastic job of laying out the architecture principals of REST. We then blew the audience away by showing them how to leverage Seam's CRUD framework to setup a full-blown REST service with 2-3 lines of XML. We also demoed an Android client that Lincoln put together to get people excited about the possibilities (and data) that REST can open up.
Over lunch, the JSF EG got up on stage for a panel discussion moderated by Kito Mann. On the panel, from left to right, was Jay Balunas, Lincoln Baxter, Dan Allen, Ted Goddard, Jeremey Grelle, David Geary, Ed Burns, Andy Schwartz and Kito Mann. We talked about our favorite new features in JSF 2 and what challenges we want to see solved next. There was some healthy debate about making Facelets templates based on XML rather than XHTML. Once again, the underlying theme was about looking ahead and keeping progress coming.
My next talk was on Seam Security. I always enjoy giving my Seam Security talk because the demo of that technology also blows away the audience. With 90 minutes, I was able to present how Seam Security works and then spend a whole half hour on the demo. The impact is made when ACLs and rules are cross-bred to allow users to grant context-relative permissions at runtime.
With three talks down, I was at the top of my game when I got to my presentation on CDI (JSR-299), Weld and the future of Seam. I started out by clarifying the differences between CDI, Weld and Seam. With that foundation set, I explained CDI's significance, how well it integrates and supports the Java EE platform, recommended using it over JSF managed beans, then launched into my rendition of the CDI tutorial. It all led up to the introduction of Seam 3, the first set of portable extensions for Java EE and how they are going to completely change the game. The monolithic middleware framework is dead and innovation will be driven by modularity and portability. I regret not recording that session, because I'm not sure if I'll be able to explain this stack as clearly as I did that day.
After the first day of sessions, the JSR-314 Expert Group (EG) decided to get together for a face-to-face meeting following dinner. We met in the Donatello Board Room, 1,990 square feet of business class. The plush seating and a large conference table definitely made this meeting feel official. In attendance (going around the room) was Ed Burns, Kito Mann, David Geary, Jeremey Grelle, Ted Goddard, Jim Driscoll, Lincoln Baxter, III, Andy Schwartz, Matt Drees, Martin Marinschek and Jay Balunas. On the phone were Roger Kitain and Stephen Kenna. If you weren't in attendance, don't feel left out. This meeting did not happen
behind closed doors. Both the agenda and an audio transcript of the meeting can be found the JSF Summit 09 meeting page on jcp.org. (This is the first time an audio transcript of a JSR-314 EG meeting has been open to the public). Please tune in if you are interested in the JSF community and/or specification.
The main focus of the meeting was community. We discussed future plans for the mailinglists and how the community can use them to participate. Currently, the mailinglists are undergoing migration to the jcp.org infrastructure. The plan is to have three lists:
The first list is actually a public forum, jsr-314-public, that the community can use to discuss the spec and future of JSF. Access will be open to the public for reading and writing (a free jcp.org account may be required to post, we haven't decided whether that restriction will remain). The second list, jsr-314-observers, is the main design list. Access will be open to the public for reading and members of the extended EG (the EG plus invited guests that work on implementations, component libraries or extensions) will be allowed to post. Finally, there is an internal EG list, jsr-314-eg, for
offline discussions, typically involving licensing or legal matters. No discussions involving design will take place on that list.
Lincoln then announced the JavaServer Faces community site initiative, introduced above. There was a lot of discussion about how important it is to get the word out on JSF 2, engage the community so that they can get their voices heard and ultimately so that JSF can continue to thrive and progress. The relationship with JSFCentral was clarified and Kito shared his plans for JSFCentral 2.0, which will be based on Liferay portal and offer social networking features. We also talked about the importance of creating a logo for JSF so that people can better identify with the technology (stay tuned for details).
Turning our attention to technical matters, we began discussing Ajax interop between component libraries (RichFaces, ICEFaces, ADF Faces, etc). That quickly led to a discussion of plans for JSF 2.next. Ed ensured the group that there would be a maintenance release of JSF 2.0 in the near future (~January) to correct spec errors and other minor corrections. A formalized release would be further out. Naturally, the Sun-Oracle deal is complicating matters, but the EG is dedicated to keeping progress on JSF moving.
Other matters were also discussed, such as establishing a performance baseline to help us make informed decisions about introducing new features and to allow us to focus our attention on areas of JSF were performance might be a problem. We deferred the post-mortem analysis of the JSR-314 process and how to improve it for a future meeting. But that didn't mean that we stopped talking. After an hour and a half, we were getting a lot thirsty and decided to call it a night and head towards the Thirsty Fish for drinks and social (yet undeniably technical) hour.
I was a little slow getting up the next morning (I did 4 1.5 hour talks and participated in the panel discussion on EG meeting after all; it wasn't just the drinks) and spent much of the day either chatting with people or attending sessions on topics I didn't know much about. I caught Micha Kiener's talk on the Edoras framework, a comprehensive extension to JSF covering much of the same ground as Seam, but from a slightly different angle.
The last talk of the day was the one I had anticipated all week, a presentation by Lincoln Baxter III about his project PrettyFaces. PrettyFaces is an Open Source extension for JSF 1.2 and JSF 2.0, which enables creation of bookmarkable, pretty URLs. Several of the EG members really wanted to get pretty URLs into JSF 2.0, but it was clear that we didn't have a solid proposal at the time, partly because we weren't 100% sure about the goals. This talk will likely go down as a major turning point. Lincoln spoke in front of an audience that included 8 JSF EG members, myself included. Lincoln did an excellent job presenting the topic and I think we came away with a clear understanding of the problem that needs to be solved. I'm certain we can get pretty URLs into the next revision of the specification.
I separated from the crowd during dinner to prepare for my keynote on Java EE 6 that followed, titled
Java EE 6: Here and Now (slides). Once again, the timing was perfect. In the keynote I talked about the significance of the week in Java EE history. Only a day earlier, Java EE 6 was ratified. I emphasized that while there were technology improvements, this revision of the spec was marked by extensive collaboration and integration between sibling specifications. The combination of JSF and CDI is going to make developing applications tremendously pleasant and productive. And the creation of the web profile should close the gap between servlet containers and application servers, hitting the happy medium where developers can be productive and have all the key technologies that they need to create enterprise web applications. Most importantly, the future is upon us. Java EE 6 is available today, either in GlassFish V3 or JBoss AS 6 (a Web profile impl). I walked away from the podium feeling a tremendous sense of pride in the platform, as did the audience.
Following the keynote, we spent another long night at the Thirsty Fish sharing stories, ideas and just getting to know each other better. The next morning I caught Stan Silvert's talk on JSFSpy and WARlets, but I heard I missed a tremendous presentation by Cagatay Civici, creator of PrimeFaces, so be sure to check out that project. A couple of BOFs brought the conference to a close. In the Seam BOF, I explained the modularity of Seam 3, our plans to move the repository to Git (or Mercurial) and encouraged everyone to get involved.
We are a pretty accommodating bunch. This collaboration will lead to better components and interoperability between these component sets. In the end, this is all going to be very good for the users, and the technology.
One of the unique parts of this conference is that there is no division between conference attendees, speakers and EG members. Speakers sat with attendees, attendees participated in sessions, speakers filled seats in sessions, EG members sat on both sides of the
expert panel, community members joined the EG meeting and everyone shared their experiences in real time on twitter. I attribute this level of interaction to a mutual respect and willingness to put ego aside in the spirit of collaboration and progress. That's how I want people to think of JSF 2.
How do you follow the fantastic news of the week with the Java EE6 platform and CDI getting final approval ? How about a JBoss AS release that includes support for three key EE6 features: CDI, Bean Validation, and JSF 2?
For those that aren't familiar with these technologies, each offers significant improvements to EE application development.
CDI (or Contexts and Dependency Injection) brings real context management and DI to the EE platform, and simplifies the integration of EE services with your application. Not only does it have innovative features that make life easier, but everything it does is completely type-safe, and easily extensible. Check out Gavin's interview with DZone for more information. Also check out the Weld page (our implementation and also the RI for CDI).
Bean Validation solves one of the biggest problems developers face daily, ensuring their data model is validated consistently and correctly as it progresses through each layer of an application. Instead of the common current
cut-and-paste practice that is difficult to maintain and error prone, Bean Validation allows you to put all of your validation rules where they belong, the data model itself. Since JSF 2 and JPA 2 integrate with Bean Validation, all layers of your application will enforce those rules. This reduces errors, simplifies development, and saves time (and your
V keys). For more information see Emmanuel's blog on Hibernate Validator 4 (our implementation of Bean Validation). Stay tuned for more info on how to integrate Bean Validation in your EE applications.
For those of you running in high availability environments, we have also included a brand new intelligent load balancing module called mod_cluster. You can read all about that in Brian's blog.
Note that in this release we are switching to a milestone based versioning scheme. The primary reason for this change is to provide a way to get completed features to the community as soon as they are ready. This is quite a bit different from a normal Alpha/Beta scheme which typically results in many incomplete capabilities in raw fashion, that slowly become complete towards the end of the release lifespan. The milestone model instead focuses on time constrained releases that each provide a small set of completed features. As an example, the M1 release actually includes Weld 1.0.0, which is a stable final release of Weld. If you are thinking of targeting your application on AS 6.0.0, you will be able to start with M1, and progress to future milestones as we add features and improvements.
As always, have a great open source day!
The Java EE 6 platform, along with Contexts and Dependency Injection, Bean Validation, EJB 3.1, JPA 2 and Servlet 3 have just been approved by the JCP EC. This completely changes the landscape for people developing web and enterprise applications in Java. There's just so much to digest here, and so many problems that are finally solved. EE 6 is something of a new start, and the beginning of a whole new ecosystem. Congratulations!
Thanks to everyone who participated in the Weld logo feedback :-)
We had around 130 responses to the poll, and there was a strong consensus (75%) that we are following the correct path, with r3v3 and r4v1 sharing top place - I'll talk to Cheyenne, and see if she can bring out even more of the Weld beads from r3v3 in r4v1 :-)
Some general comments included:
The [r4v1] central part is better than the central part of r3v1
The r3v3 logo is the best, especially if you need a small logo. The other look unclear and bluring.
I prefer the subtlety of r3v1.
We also got some (negative) comments on the tight kerning of the typeface. So if you like this, then please speak up now!
Font for "Weld" might be a little too thick.
Use the same character spacing as for the Seam typeface?
The r4v1 logo looks great, however I think the text stuck together like that looks a bit sloppy.
I understand it is probably meant to signify the letters are "welded" together, but I feel that spacing between the letters would look better and be consistent with the seam logo.
The weld text looks cramped up. Not sure if its due to the font. If we can have it like the seam logo text spacing, I think that will look hot.
There were some comments on r2v6 (the flying sparks). This is certainly a favourite of mine, but quite simply, this won't scale to a small size well (something we need e.g. for IDE icons). However, be sure that we will use this motif in banners, desktop backgrounds etc :-):
r2v6 is nicer logo but r4v1 fits better with Seam
Standalone I definitely like r2v6 the best. The only downside is when you view it side by side with the Seam logo the former overpowers the latter. This effect might be mitigated by darkening the seam logo or by lightening the weld logo.
People had conflicting views about whether staying close to the Seam logo was good. We certainly see these as very closely related projects, and wanted to emphasize this in the graphic design:
Not liking the similarity between some of the weld designs and the current seam logo
I think its clever to stay close to the Seam logo.
wont this get confused with actual seam framework?
Maybe stagger the bumps so it's a little more reminiscent of the staggered 'zipper' from the Seam logo?
And some people were concerned about that the logo won't scale well. It's important to remember that these are just mockups and Cheyenne will do a lot of pixel-by-pixel fixing for the very small (icon) versions of the logo for the finished product:
I really like the clean look of the two welded sheet variants. The trick will just be getting the welding bubbles just right at different sizes. But I'm sure every time the logo is printed, that can be tinkered with.
r3v3 works best in low-res / tiny
As for the colouring, Option 7 had a strong lead over the pack, with Options 1, 2 and 8 closely grouped as the second choice. I also really like the colouring in 7 :-). Yet again, there were some good comments:
As for coloring, the bumps could be shaded to look like hot almost liquid metal near the front and get cooler towards the back. this seems more Weldish :-)
Really hard to choose :p
Avoid low contrast ones, the cyan looks too pale on white, and most of them are like that
The contrast between the two [metal sheets] makes it easy to distinguish the logo (weld or seam) without even looking at the symbol or reading the logo text.
Since we are trying to get the point across that these are two sheets of metal, we should probably avoid colors which are not metallic. I also think that having a color which complements the Seam logo is very important. Hence the choice for the dark gray.
Hopefully we will have a final result for you all to admire in the next week or two!
I've alluded to our plans for the CDI TCK, but I wanted to expand upon them. We're pretty proud of the fact that the CDI TCK is open source (something we share in common with Bean Validation and JSR-330 in the Java EE space), and we intend to treat the TCK like any other open source project (as far as possible within the constraints set by the JCP).
I've just created the 1.0 branch of the TCK, and we will use this branch to deliver TCK bug fixes only (no new tests allowed) to implementers of JSR-299 and the Java EE platform. In general, we won't be working on this branch much :-)
Trunk has been re-versioned to 1.1.x, and will be the place where we place new tests for JSR-299 - we plan to significantly increase our test coverage over the next few weeks. It is totally optional for implementers to use 1.1.x, but we strongly encourage them to as it will increase their test coverage too. We certainly will use this version for Weld :-)
To ensure we make progress in this area, myself, Shane, Dan and Norman will be adding a couple of tests a week each. Contact us if you are interested in helping out :-)