JSF Central - Pete Muir shines the spotlight on Seam 2.1
JSF Central

 Articles & Books 
Community Chat
Pete Muir shines the spotlight on Seam 2.1
by Kito Mann
30 Oct 2008 12:35 EDT

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Pete Muir about Seam 2.1, WebBeans and JSF 2. Peter is a core developer at JBoss and the project lead for Seam. This was recorded in October of 2008.

Podcast (MP3)
Welcome to the JSFCentral podcast #9 for the week of October 26th, 2008. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Peter Muir about Seam 2.1, WebBeans and JSF 2.
Kito Hello, my name is Kito Mann. Normally I am at some conference but this time I am not. We are actually doing this through Skype. I am here with Peter Muir, who is the Seam project lead. Today we are going to chat a little about Seam 2.0 and also about some other related things like WebBeans and JSF 2. I am glad we finally got a chance to meet up, Pete. So why don't we start out by talking about you. Tell me a little bit about yourself, and how you got into JBoss and what your background is.
Pete Sure so as you can probably hear I am English. I live in Scotland, in Edinburgh, which is a very beautiful city. How did I start at JBoss? I started out as a community member. I was using Seam in my previous job, and got more and more involved in it, and got asked to be a committer and then finally Gavin said "do you want to have a job?" and so I said yes of course. I guess the rest is easy to follow. I joined JBoss and then took over as lead about three or four months ago.
Kito When did you join JBoss?
Pete In June, 2007 so it has been about 18 months now, something like that.
Kito Okay. I hadn't really seen you and then all of a sudden, since you became the project lead I have seen you all over the place.
Pete Well Gavin is quite a big personality, so while he was more in charge he was more than capable of fielding all the more public stuff, but I have quite enjoyed taking over some of that, it's been good fun.
Kito Right, right. So what is Gavin going to be doing? I know he is still doing some WebBeans work.
Pete Gavin is currently working very hard on the WebBeans spec, which means that I have to work very hard on the reference implementation. He is currently working mainly on the spec and it's really looking pretty good. It is very close to being early draft 0.2 now and it's really come a very long way since EDR 1. He has really tightened up a lot of the points. I really like it. It has taken a lot of what we learned from Seam and from other things, and really wrapped them up, and even if it wasn't a specification it would be such a major improvement to Seam, plus it would be a really exciting thing anyway.
Kito I am on that Expert Group too but unfortunately I don't really have a lot of time to get too into it. I am looking forward to reading the latest draft because I notice he has been doing a lot of stuff in that area. Why don't we just start with WebBeans while we are on the topic? Why don't you - for those who are not aware - kind of explain what WebBeans is and how it relates to Seam.
Pete Sure, so we did Seam, and Gavin built Seam from the ideas that he had established from Hibernate and some of his ideas about how applications should be built more statefully and around this idea of conversations. Then the obvious thing was to take this to the JCP to standardize it and he used this opportunity not only take the core of Seam and standardize that, but also he has taken ideas from frameworks like Guice, Spring Webflow, and things like that to really build us a much more sort of consensus platform that really builds on the best of all these technologies. That was kind of where WebBeans has come from. How it relates to Seam? The idea is this: Seam 3 will be built on the WebBeans core. A question I always get asked is "Is WebBeans all of Seam or is it a bit of Seam, will it replace Seam?" That kind of thing. I think if you look at the WebBeans spec it's clear that it's not the whole of Seam. Seam has many, many things beyond WebBeans. For example -- we are going to talk about some of them in a bit with Seam 2.1 -- but for example Seam Security is a really great example. Seam Security provides this great sort of unified way of building security into your entities and into your business logic and into your JSF pages in sort of a single way. None of that is in WebBeans. WebBeans really concentrates on the core of Seam so things like conversations, dependency injection, contextual calls, integration with JPA and things like that.
Kito Right, the way I always think of it is like a dependency injection container integrated with all of EJB, which is kind of one way to look at it.
Pete Yes. It's a contextual dependency injection framework so it matters where you are getting things from -- it doesn't inject everything. It injects something that's related to what you are working on.
Kito So you are working on the implementation. What do you think is the most challenging thing you have run into in terms of writing the implementation?
Pete That's a good question. I think one of the more interesting things that we have run into is implementing the dependant scope. This is a new scope that is completely different from any scopes we have seen. It's much more like the way EJB works in that if you declare something in the independent scope, it's bound to the life cycle of the thing you inject it into. This poses some interesting challenges. A second challenge that I was talking to Gavin about the other day, which I haven't implemented yet because it is in the new version spec, is that now it's not just components that are annotated with a WebBeans deployment type, which is a bit like in Seam the name annotation which identifies the component - the object - as a WebBean. Now pretty much everything is a WebBean in your class path. So we have got an interesting performance and scalability problem there identifying how do we - if we try and scan everything in the classpath, does that make everything a WebBean when we boot the container? -- well that is going to be really slow to boot. So we are going have to do some interesting runtime inspections so maybe when people request a particular WebBean if it's not part of the core that had been loaded - we can load the core and maybe some specific ones when you start and then maybe do some lazy loading in other ones as we go. So that's going to be a very interesting problem.

WebBeans - the third thing I would say is WebBeans - and Seam as well - is very heavily based around Java reflection. We do a lot of inspection of the objects as we load them, a lot of inspection of the classes as we load them. Java reflection doesn't perform brilliantly so...

Sometimes there are ways around this like you can use libraries like cglib or JavaAssist to do your reflection instead of using java.lang.reflection, and then that's a much more performant way of doing it. So that's another interesting challenge, working around some of the reflection issues.

Kito Alright, cool. So I think everybody is looking forward to WebBeans so I think it will be a great addition to the whole Java EE platform. Is there a drop that people can look at now or are they waiting for the public review draft?
Pete I would recommend waiting for the draft that should be out shortly. Gavin wrote - there obviously is an early draft review one out - Gavin wrote a serious of blogs around it. Gavin and Emmanuel and I have given some presentations around the more up-to-date spec and you can find all of that where we all blog which is at in.relation.to. Gavin also wrote a series of tutorials and explanations about WebBeans and how it would work. That's really the most up-to-date publicly available spec. I would really recommend waiting a couple of weeks or probably by the time this interview is out, not much time at all, and taking a look at the up-to-date one because it is a real improvement over what we had before and it's looking really nice now.
Kito Alright great. So I guess the main topic of our discussion would be Seam 2.1. This is the first major update for Seam in a little while, right?
Pete Absolutely. We did Seam 2.0.GA, so the last major change was a year ago in late November 2007. So yeah, this is the first time we have published a major update for quite a long time. There were a number of minor updates in between. It's pretty exciting for me to have gotten this out. I guess I can talk a little bit about some of the themes that go through this. The first thing that we have done is we have been experimenting with Wicket and how we can integrate Wicket into Seam, and really make Wicket a really strong possibility if you are using Seam. Just in the way that JSF is a great match for Seam, we're trying to get Wicket to the same level. I have spent quite a lot of time on this. Wicket is in many ways very similar to JSF, component oriented and you build your pages as components so it's not an action oriented framework. It is very definitely a component oriented framework. It is slightly different -- you build your layout and your styles in an HTML document and then you build your components in a Java class and you sort of tie them together using IDs. This is interesting for Seam because - of course, because it's Java we can use annotations in the Wicket components to inject objects from Seam and to begin conversations, end conversations, etc. It's definitely an interesting aspect to Seam 2.1.

Then otherwise, we have got things like a whole new identity management layer -- this is such a common requirement. We found that people building sort of business applications needed a way to manage the identity of their users. This identity management is sort of an end to end solution really, an extensible end to end solution for identity management. It includes manager classes that can do things like create users, create roles, etc. and a pluggable back end that can either out-of-the-box work with JPA, or with LDAP and then you can very easily build your own persistent layer as it were to persist your identities. Then if you use this with Seam security it sort of all ties in very automatically and you don't have to write any methods to authenticate users, etc. It just flows from that.

The second thing was, I don't know if you are familiar with Seam 1.2 and Seam 2 but we had two options for managing your permissions. Either you could use a rules engine to manage your permissions, you can use Drools to manage your permissions, or you have a sort of very simple flat permissioning model. People really wanted something more akin to UNIX access control list style permissions where you just say "so and so can read this, these roles can read this," etc. We now have an ACL permission based system where it stores the permissions using JPA. That should be - I think - a really useful addition for those who have strong security requirements.

Kito Yeah, definitely.
Pete That's probably the big, main upgrade to Seam core that I think a lot of people are really interested in. Then we had a community effort to build an Excel and CSV reporting library for Seam. One of the things we did really early in Seam was build a couple of libraries for producing PDFs and producing emails using JSF tags. So rather than rendering to a web browser, you are just rendering to an email or you are rendering to a PDF, so for example, mail, which I know quite well, you would have a tag like <m:to> and then you would put the address in, or <m:from> and you would put your from address or <m:subject> and you can do things like build attachments into it, etc. One of the nice things about this was the Java mail API is complicated to use, to say the least, especially if you want to just be able to type it all in.

So this is just - kind of what we did is just build a facade over that that makes it really simple. It makes this modern - I won't say modern now - but this idea of convention over configuration, but you do more things in a conventional way and it makes things easier to use. What they did was they did a similar thing for JExcel API library and they built some Excel tags or some reporting tag for using Excel spreadsheets in JSF so you can have things like <e:column> and <e:worksheet> and <e:style>and you can sort of write one kind of stuff where you are writing exactly like you write your view, your email, your PDF -- as a developer you are writing in the same syntax but it's just outputting to Excel instead. I think that has certainly been a very popular addition to Seam and we have had a lot of traffic in the forums about that. Thanks a lot to the guys who did that. It was a brilliant community effort and they have proven to be a real asset to the Seam development team. I think it's a real success story for us. Other things we have got in, some URL rewriting, some support for JAX-RS, which is the REST API. That is kind of the big highlights for me.

Kito Okay, let's kind of go back through those in a little bit more detail.
Pete Sure.
Kito For the Excel stuff - I am just looking at the docs on it.
Pete Yes.
Kito It's really quite complete; there is a lot of stuff on there.
Pete Yes.
Kito So you can do like headers/footers, you can create different worksheets, all sorts of stuff like that. Have you given any thought to what you are going to do on the tooling side of things?
Pete This is a really interesting question and something I have been going back and forth with Max - who is the lead on JBoss tools - for awhile, not exactly on the Excel stuff but on the mail stuff I wanted to have some tooling for the mail stuff so that essentially you could have a form that just looks like your new email form in Thunderbird, where you have things at the top where you can put in headers and then the body where you would type your text. You could just have a standard from like that and rather than the visual editor—um, maybe I should explain. The way our editor works is it has a top pane where you enter your code and then a bottom pane where it displays sort of a preview of your JSF page. So rather than the preview being the whole page it would actually be more like a structured form and it would just sort of show you this Thunderbird look-alike or Outlook look-alike email form that would fill in as you type your stuff. So rather than having "To: Pete.Muir@Jboss.org" it would have "To: #{user.emailAddress}" or something like that.

That would be the idea. You can do that and I think - I haven't actually thought about the Excel one but that would be another really interesting thing to do. Maybe you could have a similar visual preview where it actually starts to build up a real spreadsheet look-alike thing, with EL values inserted in rather than a visual preview of the HTML.

Kito Right, right. That would definitely be very interesting.
Pete Something else they have done with that library actually, and this is an interesting little point that we had a big discussion about, was - I am not sure whether it is Seam 2.1.0, I think maybe it is sort of a technology preview in Seam 2.1.0, but what they have done is introduced the ability to use CSS inside your Excel spreadsheet so that if you want to style a cell you can use CSS sort of like a styling class. So you put class = (some class) then you can write a CSS spreadsheet with some special identifiers and then apply styles like that. Kind of what we have gone for is like this "it's just like writing a web page" approach rather than being a different thing. I think that was an interesting tactical challenge. How you parse out the CSS and apply the right bits to the right cell, etc.
Kito Let's say I was making a JSF page and I wanted to - basically allow you to download the same data that I was displaying to you in a table, do I need to kind of - like I have my little data table component on the page, do I need to make a separate page that has all the worksheet stuff in it?
Pete No, you can actually export data tables. They wrote a little data table exporter so it would actually just take a standard JSF or Rich Faces - I think those are the two they have tested with as far as I am aware - data table and export it as a spreadsheet, so that's quite neat as well.
Kito Yeah definitely, cool. Alright let's move on the identity and permission management stuff.
Pete Sure.
Kito I think you are right that Java EE really did need something else in that area.
Pete Yeah.
Kito I am glad you guys have really taken the challenge on. For the identity stuff, basically as I remember before is it had kind of a built in way that you could do some kind of basic identification and stuff like that. Now basically you are saying that there is much more of an infrastructure for actually managing the users. Is that basically the deal?
Pete Exactly yes, so the way you use the identity management is - it doesn't come with any class that represents user or a class that represents a role or anything like that. You still have to build those classes for yourself. Of course the idea is that when we build a skeleton app, with a command line skeleton app generator, it might build you a simple user class along the way, but the idea is that you write your own class and you annotate the fields that you want to be references, like username as the role, or the password with some special annotations from the security package, and then you tell Seam that this is the class that represents user, and then Seam will scan that class for you and work out which fields are password, username, etc., and use those for authentication.
Kito Okay. When you say support for managing users in a database, how does that work?
Pete The idea is that there is—obviously, you have got this class with these annotations on, so we have identified what the fields are and that's great for when you are actually doing some authentication. But then at the same time you need to be able to do things like say "create new user" let's say or "create new role" and at the moment we have just got this thing that says "create new class" buts it's got to do something with it. The idea is that we have a couple of strategies out of the box for persisting these new user objects, one of which is JPA so in that case if you have made yourself an entity it would have an interface into the persistence context you can just save users as needed or you could parse in an ID and it knows how to load or you can parse in a user name and it would load the relevant object and it can manage - well you put your relationship to the roles this user has and then you can say "give me all the users in this role" and it would give you back a list of users for example. And, a similar thing with LDAP -- I think it comes configured out of the box for one of the LDAP servers but you can set your parameters for the entry into the LDAP and it will get the information from LDAP or persist it back into LDAP at the same time.
Kito Have you found that a lot of your clients are using LDAP these days? I know I worked with it a few years ago but I haven't really heard much about it recently.
Pete We find that quite a few are using LDAP or at least Active Directory, which exposes an LDAP interface, so the idea is that you can use this with Active Directory for managing users.
Kito Okay. So, for the permission management stuff now you have got the basic authentication -- not the official basic authentication from HTTP, but you have an authentication identity framework portion. And then for permission stuff you have the Drools permission stuff, and now you have added something a little bit more complete, so can you explain kind of how it works? Let's say I was writing my JSF application and I have handled the identity authentication stuff, and now I want to control who can access which pages, maybe I want to control who can access particular links on a page, etc...
Pete Sure, so to access - you have got to consider security at many places in your application, not only do you want to secure your front end but you also want to secure the business layer, you want to control who can access a business logic object, or who can access a method on a business logic object and similarly who can access a particular entity class or who can even access an entity instance. This permission management sort of spans the entire application.

Taking your specific question of how we secure pages, and how we secure views, and how we secure controls on views: to secure a control on a view it's really very easy. If you didn't want to render it - for example - you would use perhaps a fragment tag of some sort that had a rendered attribute or you would use an input text that had a rendered attribute and you would just put something like "rendered=#{" and then you would use an EL function like s:hasRole -- so s:hasRole is a special Seam function and then you would just put the name of the row you would want to check in there, so for example, if you wanted to restrict a box being shown only to admin users, you can just very easily say "only render this input box IF the user has the admin role."

And then for restricted access to pages we have a couple of schemes. The first one is just to implement this very simple, very common requirement that you have to be logged in to see a certain set of pages. Seam actually has an extended version of Faces config which allows many things. It allows our upgraded navigation system. It allows security to work. It allows you to control conversations, etc. So this is our page.xml file, and in there if you want to restrict access to a view to only logged in users it's really straightforward. You just put the view ID in, you put <page view-id="/users.xhtml" login-required="true">. So that just says "you must be logged in to use this page." Or you can put in a much more complicated restriction using an EL expression, so you would just put a <restrict> tag in or an restrict attribute, and then you put in an EL expression, and again you can use this s:hasRole function or you can do any query you like into your backing beans at that point. Then taking this one step further on to your business logic, we have a @Restrict annotation which you can put on a type or on a method in your business logic.

Again, you would put something like - you would use this s:hasRole function again so you could say, if its restricted you could just put @Restrict("#{s:hasRole('admin'}") and then you know, it would allow admins. And again on entities you can put the @Restrict annotation and restrict access using s:hasRole -- again it's this idea that all the way through your application, on every layer you are doing things the same way. You are using not only the same authentication authorization system but you are using the same sort of functions and the same semantics to do it.

Kito Right. Okay so moving on to Wicket, I guess my biggest question for the Wicket support is what made you guys decide to choose Wicket for integration other than JSF instead of Grails or Spring MVC or some other web framework?
Pete Well this really goes back I guess to - I am sure many people are aware - JSF has a lot of detractors and Wicket really seemed like sort of a good option. It really addresses for me a lot of the things that JSF doesn't do so it is quite an interesting counterpart as a result. For example, in JSF one of the biggest complaints that people have is that it is very hard to develop custom components. Now because Wicket has this componentry in Java, it makes it incredibly easy to develop custom behavior into your Wicket application because all you do to develop some custom behavior, you put in your text field for example and you just override a method - the random method in the text field, or you override the validate method, or you override the convert method or something like that and you write your custom behavior. It goes from being JSF 1.2 where you have to register things in three different places and implement five interfaces, etc.; it goes to something incredibly easy to build custom behavior.

Another thing is you can probably tell from our work in Web Beans is we are very keen on type safety and making things really type safe as close as possible to the view. This is something where Wicket really excels is because you are writing in Java so close to the view layer, you have got a really type safe way of doing things like navigation. It uses a navigation system very similar to Web Objects, which I really like, so you have got sort of a natural tooling out of the box.

However, if I can just speak for a minute about the struggles I have with Wicket, I mean for me the big thing is that while in JSF you are building this tree in a single place on the page so you build a tree, you bind using EL and it all just works, with Wicket you build one HTML page which describes your layout and your CSS, and you put some IDs onto your components. You then have to build your matching tree of components in Java and you tie the components together so you create your text field and you say the idea of this text field is input, input date for example, and so you tie them together with these IDs. But what it means is you have to build a matching tree of components in Wicket that match your IDs in the HTML files. I really struggle with this because I can find no tooling around this that would check this at development time. As a result, I would deploy the application to the application server and it would say "no your tree doesn't match. Fix it." I spent a lot of time fixing these tree mismatches. So that really is for me the big problem I have with Wicket. You write too much because you have to write everything twice and this mismatch problem really slows down the development cycle.

Kito I think that particular issue is what I call the "magic string problem". JSF has that too; just in different areas. That's one of the things I think - especially one of the joys of working with XML and HTML and trying to get some code somewhere is this magic string issue. To the extent that we can all work on ways to get around it I think we will all be better off.
Pete Its been very interesting having done that work with Wicket and Seam to then look at how those ideas apply to those ideas that people have around JSF, and how some of the ideas that people come up with in the JSF expert group are very similar to the ideas that Wicket have actually implemented.
Kito Yeah, yeah definitely. I think we all try to at least keep up to date with how a lot of these other frameworks are going, and I know a lot of people are very happy with Wicket.
Pete Yes, and I guess I should probably mention that the other two view frameworks we have support for in Seam - not quite at the same level at the moment as Wicket and JSF - are GWT, we have had GWT support throughout our JavaScript remoting layer for quite a long time now.

GWT I think is a very interesting technology and we are going to be exploring that more over the next few months. Then there have been a couple of community projects for supporting Flex actually in Seam. Using Flex in Seam 1 from a group called Granite DS who have done a good job producing a sort of integration layer between Seam and Wicket and they were telling me today that they just released their new version of that which sort of brings the Seam support group to a GA level. There is also a project called Flamingo from our partners Exadel which also sets up the same idea of integrating Flex and Seam. It's interesting looking at how these different view layers work and how they play with Seam and things.

Kito You meant for the first product Seam and Flex, right?
Pete Seam and Flex yes.
Kito Okay, I just wanted to make sure. I've noticed Flex has become - Flex is obviously doing pretty well in the market place but I have noticed more and more Flex/JSF integration products because there is another one on Google Code, I don't remember the author, I think he may be an IBM developer. So it's kind of becoming a thing now which is fascinating thing now because originally Macromedia was part of the JSF 1 expert group and I don't think they were really very involved. I always wondered if they would do anything but you know they have just been very interested in promoting Flex as a platform so it's really interesting that after all these years there are third parties that are bridging that gap.
Pete Yes.
Kito I wanted to move on to something slightly different. One of the things that is kind of a more minor thing that you are adding in Seam 2.1 is built in support for URL rewriting, which sounds pretty cool to me. Can you talk a little bit more about that?
Pete Sure so as I mentioned we have this - let me go back in time a little to start with. For a long time with Seam we have recommended a URL rewriting library which is just a Servlet filter. You just put that in front of your Seam application and then you write regular expressions to map Seam or JSF URLs onto these rewritten URLs and that works in both directions. You can rewrite URLs inbound and outbound. What we wanted to do with Seam 2.1 was bring this much closer into Seam and I mentioned earlier this idea that you have your pages.xml file, and so what we want to do is really make it so you can configure your rewriting rules not in some servlet filter or something like that, just inside the Seam pages.xml file. You are already listing out all the views that you have in Seam so why not just add in your rewriting rules there. And Norman, who wrote it, he really went for writing something that really is pretty much opaque to the user so you just activate the feature in components.xml, and then you just add a very simple element to your page in pages.xml which just has a regular expression in it that maps - it's not quite a regular expression. It's something close to a regular expression but not quite. It just maps your incoming URL, your outbound URL onto a Seam URL.

And you can put named parameters in. So the URL you would get would be /home/red, and that would be the URL the user sees, but then Seam will automatically translate that into /home.seam?color=red, because you have used a named parameter there to say that for the first parameter that comes in after the slash, the real page is /home.seam. The rewritten one is /home/red, so the first parameter that comes in is called color. It does the translation like that so it is really quite simple.

And again, Seam has these conversations, which we all know about and one of the ways that Seam keeps track of what conversation you are in at any one point, is just to put a parameter into the query string of your page, a CID parameter, a conversation ID parameter. Now that looks maybe a bit ugly and if you have some requirements around your URLs you don't want that so maybe it is better to do something like encode that..so you can use natural conversations along with this rewrite to do something like that so you can just move the conversation ID around, etc. So it's very simple. And you know, it has been written so you can continue to use the old rewrite servlet filter in front for a more powerful complete rewrite of your URL using regular expressions.

Kito So was the library you were recommending the urlrewrite library?
Pete Yep from Paul Tuckey, I think his name was.
Kito Yeah, that is a good library.
Pete A very good library and it works very well with Seam. You can use it straight out with Seam. This is just a slightly more integrated. His library addresses the whole of rewriting while our library addresses a much smaller section of rewriting which is just "I want to translate from this URL that has slashes in it essentially to this URL that has query parameters in it".
Kito Right, right. Kind of like the 80/20 rule.
Pete Yes, yes.
Kito Alright cool. So I did want to ask you a little bit about what you think about JSF 2 since you are on the JSF expert group and you are even very active. I must say I have been very happy to see some more involvement from the JBoss folks. You have definitely been pushing a lot of the great features you have developed in Seam into the JSF spec which I think is great. We are touching on a lot of different areas but if you could pick the three most interesting areas that you see in terms of JSF 2, what would they be?
Pete I am going to slightly warp your question a bit. I think the most important areas in terms of JSF 2 are Ajax and the Facelets standardization and the easy composition of components. But what I thought when I joined the expert group six months ago was that the expert group would really have these well in hand and was doing a great job and you have got some great guys from all sorts of - pretty much all the JSF ecosystems represented there and they really know what they are doing with the Ajax stuff, with the easy compositions. What I wanted to focus on much more was maybe some of the more lower-level enhancements that are a bit less sexy, I suppose is the right word, and what we have developed in Seam so I guess more of things I know more about.

So the first thing that I really, really felt had to go into JSF was this exception handling stuff that I have been working on a lot recently. Our golden rule with what we do is we always say that you always re-throw an exception. You never ever swallow or log an exception because you always want to propagate the exception down so the user can handle it. If you log and swallow an exception, it just fills up your log file and it doesn't really achieve anything. But if you actually re-throw it, then the user has a chance to do something with it. Of course we get to JSF, and JSF is pretty much as close to the user as we are ever going to get so we really do need to do something with all these exceptions that have come down from JPA and come out of Seam, have come out of WebBeans, have come out of - I don't know - your business process management system or whatever. At some point you do have to catch the exceptions and you do have to log them or display an error message to the user and so on. So I really felt that there were two aspects with what I wanted to do with the exception handling.

First of all, JSF 1.2 in my opinion isn't great in the way it handles exceptions. It's not consistent. Sometimes it catches and re-throws. Sometimes it catches and swallows. Sometimes it catches, swallows, and logs. The first thing is to really go through the spec and identify all these places, and clean it all up and make sure that it always re-throws any exceptions out of JSF so the user can always handle the exceptions and that JSF itself never ever logs an exception.

The second thing to do was to make sure that this place that we do handle exceptions is completely pluggable so that when your business designer comes along and says "when this happens I want you to not redirect to another page and highlight this input field here because this is my business requirement," you can do it. You can write any sort of custom exception handling behavior you wanted. The challenge has really been - we sort of prototyped this in Seam. We wrote some exception handling stuff in Seam and it works reasonably well. Unfortunately because of where the hooks in the JSF lifecycle are we can't handle all exceptions there and sometimes there are places where it is tricky to actually handle exceptions quickly. By putting this stuff into the spec we can actually put the handling in the correct place and deal with it neatly. The other challenge here is in JBoss, you know in Seam we developed this whole alternative syntax for how you want to specify which exceptions you want to handle but in JSF, we want to do this through the Servlet API's exception error page handling stuff that is already there. So you know this is some translation work I had to move from one system to another.

Kito Right, right. Okay. Alright so hopefully JSF 2 will be out probably early next year is what I am thinking, and Seam 2.1 should be out when?
Pete Seam 2.1 should be out - I hope 2.1.0 should be out early next week.
Kito So probably it should be out around the time or a little bit before the time you hear this.
Pete Around the 22nd, that sort of date.
Kito Okay. Alright, well it's been a pleasure chatting with you Pete. Anything else you want to add, or topics you want to discuss?
Pete No I think we have pretty much covered everything that I am working on at the moment so.
Kito Okay. Do you guys have a road map for beyond Seam 2.1?
Pete Sure, I guess that is the other obvious thing, and of course when you ask that question there is a really obvious answer which is Seam 3 which will be WebBeans based. It will be JPA 2 based and JSF 2 based so that is the big picture here. The next big thing in Seam is going to be really WebBeans. That is where Seam is going. It's entirely new, sort of really quite interesting and different core model.
Kito Sounds good. Pete, great chatting with you.
Pete Thank you.
Announcer That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening.

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.