Community Chat JSFCentral Episode 31: Ed Burns, JSF Spec Lead, discusses JSF 2.2 and Java EE 7

Ed Burns

October 07, 2013 at 12.19:00





In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Ed Burns, JSF Spec Lead, about JSF 2.2 and Java EE 7. Podcast (MP3)



Kito: Hello, and welcome to the JSF Central Podcast. My name is Kito Mann, and today I'm here with Ed Burns who is kind of enough to join us from the Oracle offices in Jersey. Ed: How you doing? How's everyone doing out there? Kito: Hopefully, well. So, if you're not familiar with Ed, he is the spec lead for JSF 2.2 in particular, but also many previous versions of JSF. I think it's been every version except for JSF 1.0, right Ed? Ed: Right. I was co-spec lead, right. Kito: Oh, so -- that's right. You were co for 1.0. Wow. Okay. Well, talk about longevity, I'm telling you. It's been a while. Ed: Well, it's -- that's why I've been saying abstractions endure, right? So, the important -- we all know this, this is just academic CS 101. If you define something as an abstraction, then the implementations can change underneath, and the ideas can change underneath, but really, the programming contract is the thing that matters. So, while we have been doing JSF for a long time, the fact that it is an abstraction technology is what we have to thank for this longevity. Kito: Yeah. Definitely. And plugability, too, has definitely been very handy. You know, we've…from my clients, we've been interviewing people for JSF work, and we actually found someone whose entire career has been in JSF development. Ed: Wow. Kito: Which I was just blown away by because it makes me feel kind of old. But I just think that that's kind of fascinating. Ed: That's great. Yeah, we hope we're doing the work that enables that. That's a huge benchmark of the success of any technology is…and I've been saying this for a while, too: to what extent can people build their livelihoods and careers and stacks on top of it? Kito: Yeah. That's a very good point. Definitely. So before we get started with details about exciting new features in JSF 2.2 and Java EE 7—sort of tangentially—tell everyone about yourself and how you got into this particular line of work. Ed: Well, it's been a big blessing that I got associated with JSF back in 2002. At the time, I was working at Sun, and working on the AOL/Sun/Netscape alliance that was delivering Netscape 6.0. And when that sort of wound down, I looked at what was happening inside of Sun, and learned that Amy Fowler and Craig McClanahan were ramping up this new spec, and I got involved with that. And it's been a good fit for me because it enables me to bring the kind of stewardship skills that you need to have to be a spec lead to the floor because JSF is a technology that integrates a lot of other things, and it being a JCP technology, it gives me the opportunity to interact with leaders, thought leaders and leading companies across the IT landscape, and collaborate on a piece of technology that hopefully is useful to people. So, it's been a great thing, and I've been enjoying doing it for a very long time. Kito: Yeah. And I must say, I think you've done a very good job with sort of dealing with the complexity that's involved with a specification like this, and all the different parties involved. Ed: Well, I do appreciate that. Thank you. Kito: So, we're looking at JSF 2.2, which just came out in…was it June? Ed: No. We'll call it final in early/mid May. Kito: That's right. Because I'm thinking about the whole release train for Java EE. Ed: Right. It's been a…what we like to call rolling thunder, you know? We get that JCP thing, and we get the Java EE 7. There's just so many pieces to Java EE now that it just…you do need a few…you need a series of days to get them all rolled out. Kito: Yeah. Definitely. So, obviously JSF 2.2 is part of Java EE 7. And the big theme…what would you say is sort of the big theme in Java EE 7 as a whole? Ed: Well, we're trying to enable HTML5, and web socket and sort of newer style applications, which is kind of interesting because when you look at JSF, I've been saying all along that the sweet spot for JSF is where the UI state resides on the server, and you may have islands of state that are living on the client. But that is a decision that's left up to the component library and even the individual application developer as to how much state they want to put on the client. If they want to do more, you know, thin server, thick client type things, they can do that. But I will say the theme that we've been trying to put out there for Java EE 7 is enabling HTML5, and web socket, and JSON, and that sort of thing. And JSF has been…there are some features that we'll talk about today that enable that. But I do need to point out that it's not…JSF is still going to continue to be what it is, which is a UI component technology for integrating things on the server side where the UI state mostly does continue to reside on the server side. And I know that the trend is moving in a direction where you have more state on the client. And that is perfectly appropriate and good in a lot of cases, but there's still a huge number of cases, and indeed I would say in a majority of cases where you don't want to put that much state on the client. So, we can look at Java EE 7 as sort of laying the foundation for future efforts that might put more emphasis on the thin server type developments. But from my perspective, HTML5 and WebSocket and JSON were some of the themes for EE 7.0. Kito: Okay. Fair enough. And then, basically, all of the specs got some revision so CDI went up to 1.1, and they also…they added the Batch API as well, which is nice. Ed: Right. Concurrency, Util APIs, you know, we got a new bean validation, which had some great features. EL 3.0 was really exciting, bringing a lot of the power of lambda expressions to Java EE 7 before it even made it into SE 8.0, so that's really exciting. Kito: And finally, it actually went through its own expert group outside of JSP, which is nice. Ed: Yeah. It's been a long road to get that happening, to finally pull EL out, but it's been an acknowledgement that EL really is such a key technology. It's really this thing that enables polyglot applications where you have your views written in a markup language, and you have your model written in some kind of Java, and then EL is this very nice glue that lets you hook that together. Kito: Yeah, definitely. And one of the things that I'm happy about is just a very minor thing. The JSON parsing API. Just because it's one of those things that obviously needed to be a standard. Ed: Yeah. It's great. And it's a good example because standards are for standardizing, not for innovating. And they're already well understood technologies for doing that, and it was just trying to put it in the platform, so now everyone can count on it being there. I just hope that I expect that this will be true that we don't get into a situation where there's still some people hanging on saying "oh, well I prefer to use the proprietary nonstandard way of doing things." Just look at all the pain that's been induced by the fact that people still insist on not using Java Util logging, and they have their very good reasons for doing so. But it's certainly, at least, arguable that everyone could just give it up and use Java Util logging and make everyone's life a little bit simpler. But it's one of those issues that people get very passionate about, and everyone has good reasons for doing so. Kito: Yeah. It's kind of hard. Some things like the Java Util logging probably should've been there much sooner. But some things like this, you know, I'm not really sure it could've been much sooner because JSON just really took off. So, I don't know. We'll see. So, moving onto JSF 2.2. So, 2.2 is kind of an interesting little evolution in JSF. It's not a big ticket super release, it's not a 3.0. But it's certainly a pretty reasonable leap forward. It addresses a lot of sort of minor annoyances, but also adds a few kind of big ticket features. Ed: Sure. I mean, yeah. The big three would be Faces Flows, HTML5 Friendly Markup, and resource library contracts. And all three of those are pretty significant new features. Kito: Alright. So, let's start with the HTML5, since that's a hip thing these days. Ed: Indeed. Well, our challenge there was we wanted to allow people to write HTML5 in whatever way they wanted to because it's such a broad label, and it accomplishes so much. So, what we were trying to do was turn the traditional model of JSF kind of upside down. We used to sell JSF as if you want to have a really fancy component, but you don't want to write all that HTML and JavaScript and CSS and stuff yourself, you could encapsulate that into a JSF component, and then your page authors could deal with it as if it was a simple markup tag. So, the example I'd often use is the calendar chooser. There is no -- there was no, prior to HTML5, rich calendar chooser component, so you could build a JSF component, then your page author could say <my:calendarChooser> on the page, and then when that thing got rendered, you know, you'd have all the richness that was necessary. So, that was a great answer when there weren't so many degree programs that put out web designers. Now that it's much a more commonplace skill to have high quality web designers available and ready to work, those web designers want to use their skills, but they don't want to -- they might not necessarily want to have to put everything inside of JSF components. So, we want to make it possible for those who prefer to write their HTML manually, and deliver the scripts in CSS and manage that on their own, to still be able to leverage the JSF components. So, Frank Caputo was instrumental in helping craft this feature, and also Imre Oswald, who are JSF expert members where they basically redefined the mapping. When you have a piece of markup in a Facelet page, which we always call them .xhtml pages, but in fact they are XML pages, they're parsed by an XML parser. So, it has to be well formed. That's one important thing to note. HTML5 angered some XML purists by continuing to allow the non-well formed style of authoring, and I guess this goes back to Marc Andreessen's famous old quote, "There's no such thing as bad HTML." Throwing well-formedness aside. But for JSF, you still have to have well-formed XML, even though it can be considered HTML5, it has to be the well formed variant. So, you have any little piece of markup, and you can declare that to be a JSF component by putting one of the attributes from this JSF pass-through namespace on there. And when that happens, the system kicks in, and it'll try to establish a mapping between the markup that you wrote, and an existing JSF component from the existing HTML basic library. So, this actually turned out to be another good example of leveraging the existing specification in a way that cleanly allows it to move forward. So, we already had the equivalent JSF components for all of the basic HTML components that are out there, from HTML 4.01. But we didn't want to just go through and make new ones of those for HTML5 to account for the new elements. There are quite a few new elements, like there is a date picker, there's a color picker and such, HTML5 elements for those. So, we just said well, really, when you send or post back from a form with these components, as far as the server is concerned, it really is just a bunch of name-value payers associated with a specific ID. So, we will find the mapping, the closest kind of component that actually fits, and use that. And if there is no fit, then there's the fallback mechanism where you can define your own. So, that's one side of the HTML5 story. The other side is data attributes. You can -- a lot of the HTML5 authoring style, we use data attributes to convey meaning from the server to the client, and then you might pick up some JSON there that will look at that data attribute and do things with it on the client. We wanted to support that as well, so we have some techniques for supporting that -- JSF 2.2. Kito One of the things I like about this approach is it takes advantage of one of the sort of intelligent design properties of JSF components, which is that they all can accept an arbitrary map of attributes. And it's really the HTML5 support is about enabling Facelets markup to interact with that in a way that makes sense to a page author. Which is really nice, I must say. Ed: Yeah. We're lovers of the whole pass-through element and pass-through attribute concept for that. Kito: Yeah, definitely. So, one of the questions I remember when -- I wasn't really involved with this part of it, but I remember reading your emails about the HTML5 stuff. How does this relate to the old Facelets, as we call them, Tapestry style views? Which were pretty similar, conceptually. Ed: Yes. You know, we have this "jsfc" thing, that was one of those things that was in Facelets, and we didn't quite pull it into the standard all the way. When we chose to standardize Facelets, we picked just the best parts for standardization. But we still picked up the whole implementation. So, we don't really think that's a necessary thing to do when you have HTML5 pass-through attributes. And most importantly from the competitive landscape, this really lets you do one of the things that people talk about loving about Wicket, it lets you do that with JSF. But you have this added benefit where you don't have to keep these two different trees in sync. You know, the markup tree and then the component tree is created programmatically. So, you can still write your markup in pure non-JSF-looking HTML, but yet, you don't have to manually programmatically create an analogous tree of that on the server side, which you do have to do with Wicket. At least you did in the version of Wicket that was present when we finished JSF 2.2. Kito Oh, interesting. Okay. And do you know how quickly third-party component libraries will be supporting this? The HTML5 features? Ed: Well, I know that PrimeFaces was really keen on it, and they helped with some of the definition of it. They're pretty much the quickest to pick up the new stuff. And I can't speak to the other -- I have not heard about the plans for the other vendors. But the nice thing is, is this is a really important thing, actually. We had to design it in such a way that page authors could get access to these features without having to upgrade whatever component library they were using. So, that's really one of the major motivations for the design that we ended up with. Kito: Alright. Cool. So, that's one sort of key feature, is that those who are designing HTML5x can now work directly with HTML5 Markup. How do you think that's going to affect existing applications where people have already used a lot of the—as they say—JSF tag soup, the detractors would say. I actually prefer using the real component tags. Ed: Well, it'll be fine. Everything will be able to continue to exist alongside. So, it's not disruptive, it's just you can fit it right in there, the same page can have just as many JSF components as it can have in these pass-through components. There's no need to like say, "oh, this page is a new-style page, and that page is an old-style page." Which was the case when we went from JSF—when we went from JSP to Facelets. There were some things you had to be aware of in migrating that. But this just completely fits into existing Facelets. Kito: Alright. Great. So, let's talk about another feature, Faces Flows. So, this is sort of an interesting feature, which we've seen in other frameworks. Ed: Yeah. This is another example of the standardized…after the market has decided to release the technologies out there for a while. And we looked at ADF Task Flows, we looked at Spring Web Flow, and we looked at some of the work in the Apache MyFaces coding project. And those were the pretty well-understood problems. And so, the real art was doing it in a way with JSF that made it very easy and natural to do. So, you also could look at CDI 1.0 conversation scope as something that was a precursor to this. But one of the things that people complained about with the CDI conversation field is you have to manually begin and end the conversation programmatically. Well, when you're defining a flow, you know what pages are going to be in there. So, why not just have the system automatically start it out and close it down? So, we defined a bunch of rules. Kito: Before you get into that, Ed, just take a step back. Explain what the problem is that we're trying to solve here. Ed: Sure. Well, prior to the introduction of any kind of flow technology, everything in your JSF app was basically one large function with a bunch of go-to statements in it. And that's no way to program. And it's certainly no way to manage complexity. So, over the evolution of those, a web application over time, you would end up with various little homegrown schemes you're trying to manage things with. People would put pages in directories, and they'd put Java classes in certain packages that corresponded to those directories. But it was just a stop gap approach, there really was no way to have a proper programming scope where objects would come into existence when you enter that scope, and they would go out of existence when you exited the scope, and there was no way to nest these scopes as well. You basically just had request session and application, and then CDI added conversation scope, but you still had to manage the creation and destruction of that yourself programmatically. So, what it does is it brings a way to modularize your application functionally…you know, with page flows. Kito: Alright. That makes sense. So, I'm sorry, continue with your other thread that you were saying about the way this is… Ed: Right. No, no. It sets the context, of course. So, we wanted to do that. So, we looked at the ADF Task Flows and it had a very XML-heavy syntax because the design space for ADF is people that are using the Oracle JDeveloper tool. So, if you're using the Oracle JDeveloper tool, and that tool happens to generate lots of XML for you on the backside, then there's no problem there. As long as you like using the tool. But we had…in the JSF spec, we wanted to also appeal to people who prefer to use different tools, or preferred to use very lean tools, like even down to just the text editor and the compiler and build tool, so we wanted to minimize the amount of config file that was generated for this. So, we looked at ADF for that, and we certainly took a lot of their XML syntax in, but we also defined a way to define flows programmatically using a builder API. This is something we picked up—well, it's not a new pattern at all, but the JSON spec has this, and I talked to the JSON spec lead in helping to define the builder API for flow definition. So, those two pieces kind of tied into our desire to have more convention over configuration when you're building your flows. So, at the simplest level, if you have all of your HTML pages in a directory, and you happen to have a file in that directory that is the same name as the directory ending in -flow.xml, it will automatically declare that directory and all the files in it to be a flow. So, whenever you visit any one of those -- when you enter into the start node for that flow, then all of the pages in that directory will be in that flow, and you can create flow scoped beans, and know that when you exit that flow, those flow scoped beans will all go away. We wanted to make it as easy as possible to define simple basic flows, and then of course, when you need more complexity, when you need more power, we have all that config syntax for you there. Kito: Alright. And I really do like that sort of convention feature and the idea of sort of automatically picking up flows. One of the interesting things about the Faces Flows is that the flow scope, which you just mentioned, is actually a CDI scope. Ed: Right. There's two of them. You can have your own flow scoped beans, so this is just analogous to saying my bean is an @SessionScoped. You would just say @FlowScoped. And then, you have to give the name of the flow itself. But there's also a new implicit object, which you can access from your EL and your JSF pages. So, you could say #{flowScope.something}. So, you don't even need to create a bean…so if you have a bunch of pages, and you all want to share that data inside this flow, but not outside of the flow, then you could just put stuff in the flow-scoped implicit object for EL. But as you mentioned, we do have a CDI, a full-fledged CDI scope as well. Kito: So, this is one question for, I guess, current development shops. So, probably most of the JSF shops I've seen are either not using EJB or they're EJB shops. But there are also some shops which are Spring shops that are using JSF. And for the most part, JSF plays very well with Spring. But what would you say if someone was in a Spring shop and they wanted to use the flow scope which is now… Ed: That's a very good point. And no one's actually brought that up to me before, but that is something that we don't…you know, the CDI…the @FlowScoped in the JSF spec is a CDI based scope. And I have not looked into what the equivalent technology would be in the Spring world. I assume they have a way to do a custom scope thing. So, you could probably…that's a space for an add-on right there. But it certainly wouldn't be in the per view of the JSF spec, being a part of EE to place a requirement so that implementations provide a Spring version of the thing. Although they could. But there's really no reason why someone couldn't write that extension pretty easily. Kito: Okay. And I think that's probably what would happen because right now, that's what happens if you want to use the view scope and Spring. You've got to basically use the Spring custom scope to roll your own -- so, it's the same sort of deal. Ed: Well, that would be a great thing for someone to do for a summer project. Kito: Yeah. It might happen. You never know. So, that brings me up to another point though, there's now a CDI-based view scope as well. Right? Ed: Right. That's right. Yeah. We added two of those. We added the @FlowScoped and we added the @ViewScoped, those are our new CDI-based scopes. And this brings up a point, even though JSF 2.0 and 2.1 were delivered as a part of Java EE 6, we have always made a point of not placing any dependencies on the same version of Java EE that JSF has delivered in. And we've done this intentionally to allow for people who like to run JSF outside of the Java EE platform on Tomcat, for example, to be able to do that without…so they can get the new JSF features without having to wait for the next version of Tomcat or something, or even a full EE container for that matter. So, JSF 2.0 came in the version of Java EE, but offered CDI. But yet, there's nothing in JSF 2.0 that requires CDI. Now here we are in 2.2, which is a part of EE 7, and going with our one less than rule, now we can for the first time in the JSF spec place requirements on CDI. So, that is why we were able to say hey, now we've got CDI, we can actually make use of it. So, let's see what we can do. And that's why we added these new scopes; CDI-based @ViewScoped, and the new @FlowScoped—we will be deprecating the old javax.faces.bean package, which has been around for a really, really long time. And people often forget this, and I'm happy to point out that JSF was the first Java EE technology that had dependency injection. JSF 1.0 had just as much dependency injection as early Spring 1.0 did. So before CDI even came around, we had a way to do dependency injection in JSF. It was bulky; you had to use a lot of XML, but it's still -- you could wire up your whole story that way. Kito: Yeah. And I mean, I still find they are used a lot. But what I liked about it is its simplicity. There's not like 20 different proxy layers and inceptors and everything, it just kind of works, which is nice. Ed: I know. You're right about that. And simplicity ties into the debugability there, too. Kito: So, just in case you're not clear, whoever's listening, that javax.bean is the package for the JSF managed bean feature. Ed: javax.faces.bean… Kito: Yeah. Sorry. Okay, so let's move onto the next topic. Another big ticket feature is Resource Library Contacts, ah…Contracts not Contacts. Ed: And now what you just did was a problem that we had because this name is not as good as the name we came up with initially. And I'll give you some back story on that. The name was contributed initially by a JSF community member, and as part of a much larger and more ambitious effort that is still worthwhile to pursue, and we're going to see where that goes. But that other name was multi-templating. We took a subset of that idea and called it Resource Library Contracts because we didn't want to take that name if we were only going to do a subset of the full idea. Kito: I was going to say…when you guys were going over that in the expert group, I didn't actually look thoroughly at the original proposal. So, what was the overarching idea? Ed: Well, I won't say too much about it because I'll leave that for the other JSF community members to talk about. But what I liked about it was that it really took some of the energy that you get from the PHP universe, which is a gigantic ready-made set of templates that you could just grab and use, and it brought some of that to JSF. So, letting you really kind of package up a site template into a well-defined format, and ideally distribute it easily, in a JAR and a Maven repository. We did pick up that part, the ability to package the template into a JAR, but we just didn't pick up the full idea. So, that's why we didn't want to do any disrespect by taking the name, but only taking some of the ideas. Kito: Okay. Fair enough. Ed: What we did do is really a nice counterpart to the Faces Flows feature. With Faces Flows, you get to modularize the behavior of a portion of your site, or your application. You could create a flow as I mentioned earlier that describes the checkout process or a flow that describes browsing through an inventory, any number of things you could do in a web based application where you have a workflow. The Faces Flows feature lets you modularize that. Well, with Resource Library Contracts, you can modularize the appearance of parts of your page -- parts of your site. So, it takes the basic idea of Facelets, where when you define a Facelet, you are in fact creating a usage contract. It's a very lightweight usage contract, but just the same, there is an agreement that has to be understood between the template and the template client. Namely, what is the name of the template file, and what are the insertion points that you could put in, right? So, when you imagine a Facelets template, you have to say: what is the name that you're going to apply to your template client? And then, you need to know what are you going to put in your UI defines. And with those two pieces of information, you really are defining a contract. So, with Resource Library Contracts, it lets you implicitly say that various parts of your site—or even your whole site—can have templates applied to them without explicitly calling them out. So, you basically say: my page was going to automatically have this template applied to it, and there are some conventions that let you drop in a JAR and then it automatically gets applied to all of the pages in your app, unless you configure it to be more narrow, to only subsets in your app. And then, you just know that every page is eligible to use this template, all it needs to do is start putting in those defines, and then you get to have access to template features. And we defined a syntax for packaging these things up in JARs and you could distribute them as Maven dependencies in your project. So, it gives you some of the modularity that people would like to have when doing multi-tenant style applications. We want to be able to let people create applications that play well in a multi-tenant environment. So, you could imagine… Kito: And for those who don't know, multi-tenant is basically one application that's basically dealing with several sets of users. Sort of more of a cloud sort of environment, right? Ed: Exactly. And a really good example that occurred to me recently while I was on a business trip was…I would think there'd be a business for this, actually, where someone says I'm going to build a cloud-based web property for restaurants that don't have an online presence already. And I'm going to sell this to however many restaurants I like, and each restaurant is going to be its own tenant. And of course, the restaurant's going to have its own set of food, you know, its own menu, and it's going to want to present the menus in various specific ways that are unique to their specific restaurant. But yet, the underlying code is all going to be the same. But yet, each restaurant might have separate flows, you know, different times of day, different kinds of menus, and you could really use the Faces Flows and the multi-templating feature to enable that so that each individual client—or tenant that is—would have its own set of capabilities packaged as multi-template JARs or packaged as flows. And it lets you achieve a high level of reuse across the tenants. Kito: So, what if all you really want to do is change the style sheet or something for each tenant? Ed: Right. And that's a great thing, you're getting into the question that people often ask, which is what is the difference between multi-templates and skinning? And really, multi-templating is a superset of proper skinning. Because really, with skinning, people just want to have one look apply to the whole site, and then maybe they want to change the style sheets and such. You could do that as well. I mentioned two pieces of information that make up the Facelets client. Well, there actually are three, but most people don't even worry about the third one, and that is the style sheets and the specific CSS class names and such. So, if you have a Facelet template client that's using a particular Facelets template, and that template has some CSS associated with it, and you want that CSS to be referenced in a specific way from inside your template, then you need to know what are those CSS class names, for example. So, that's also a part of the contract. And the multi-template system also really builds on top of the resource library concept that we had in JSF 2.0. And that's why we called the feature Resource Library Contracts because it takes the resource library contract…I'm sorry, it takes the resource library concept from JSF 2.0 and marries it to the Facelets concept of JSF 2.0 to create this modular site templating system. Kito: Yeah. I really like that feature. And also, what I think of is…let's say you've got a module that does…I don't know, security, or something…add users, delete users, whatever. You could package that up as a flow. And then, you could also provide a Resource Library Contract so that if we're using different applications, you could change the look and feel to match whatever application. So, there's definitely a lot of flexibility there. Ed: Right. And you know, we wanted to do it—this was another feature that we really got a lot of help from the JSF community. And expert group member, Frank Kaputo came up with some of the expedient ideas that enabled us to take the multi-templating feature and pair it down in a way that really fits what we were trying to do with JSF 2.0. And conceptually, it's not much new to learn, right? I mean, if you know how to use Facelets, then you already know how to use this feature. It's not like with Flows where there are some new concepts that just did not exist, that had no analog prior to JSF 2.0. Everything in this feature is already something people know. Kito: Yeah. And it really is very easy to use, too. Definitely. Alright. Well, there's just a couple others that were big…I guess those are sort of the key big ticket features that you wanted to discuss; the HTML5, Faces Flow, and Resource Library Contracts. There's a couple of other sort of useful things I like, like the CSRF protection, the file upload stuff. Those are a couple of the top ones, but there's some other ones as well. Ed: Right. There was a lot. And anything that takes as long as this thing did take…and unfortunately, it took longer than we planned, but we fit into a larger Java EE 7, which also had a re-plan that happened midway through, which added some more time. So, while you're working on the big ticket features, you want to get as many sensible other things in. So, you mentioned cross site request forgery protection because that was actually one that we wanted to get into 2.0. But we missed. So, we got it into 2.2. And the file upload component. That one is great to talk about because it lets us tie into the previous story of how JSF always lags one -- intentionally lags one Java EE release behind the EE in which it's embedded. And this is so Tomcat users can get access to the up-to-date JSF so not having to wait for another version of their stack to come along the pike. Of course, as we get more and more intertwined with EE and as far as like CDI, for example, that's less and less of an option. Because if Tomcat's going to continue to be just JSP and Servlet, and the same is true for Jetty, then you need to let these other containers that are coming up like TomEE, that is a full web profile implementation. So, that's what we do. Kito: But also you could still use CDI with Tomcat, you know, without the rest of the stuff. A little bit of extra work, but it's doable. Ed: It's certainly doable. And you just -- you have to have the right willingness to get your hands dirty and say okay, I'm going to do a more ala cart style implementation. Kito: Right, definitely. Ed: So, there's nothing stopping you from doing that, and so we like to enable it. But the way this ties into file upload is JSF 2.2 was the first version where we could offer something that depended on Servlet 3.0 and beyond. So, the file upload—or more specifically, the multi-part form data support—didn't reach Servlet until version 3.0. And because of Servlet 3.0 being introduced in Java EE 6, we couldn't depend on it because like I said, we lagged one release behind. So now, we're in EE 7, we can depend on EE 6 features and file upload is probably the most important one of those, CDI being the other. We did a few things, another one we could mention is the view scope, we re-implemented the JSF @ViewScoped as a proper CDI custom extension, portable extension. And now at this point, there's no reason to keep using the old javax.faces.bean package, everything can come from the CDI packages. Kito: Wait. What about the portlet support? Ed: Well, yes. It'll still be there, you know… we're not taking it away. Kito: Oh, I'm just saying, though…since the portlet thing still isn't totally worked out, CDI still—I don't think—100 percent works well in portlets. Unless I'm missing something. I know that they were working on it. I think maybe with 1.1 it might. Ed: Yeah. The JSR 362 expert group is working right now. I'm happy to be with Martin Scott Nicholas on that expert group and Neil Griffin. And we're just getting that whole effort started. Kito: Wait. Actually, I'm on the expert group, too. I've just been a little silent lately. Because I was kind of waiting to get to a thing that I could provide some good input on. So, are they looking in the CDI yet? Ed: Not yet. No. Kito: Alright. I'm definitely planning…there's that and there's also a lot of stuff with how Ajax is handled that I have a lot of opinions about. Ed: Yeah. That's a tough problem, Portlets and Ajax, for sure. Kito: Yeah, it's doable though. It's definitely doable. With the CDI thing, though, there's the view scope, right? And then, also what I like is that if you have managed beans, they now interoperate with CDI better, right? Ed: Well, you mean the CDI managed beans or the JSF managed beans? Kito: The JSF managed beans. I thought now you could inject them into CDI beans. Ed: I don't know. I don't think we went…because I personally have been recommending people to use either one or the other, but not trying to mix them. Kito: Right. Okay. So maybe that's something we were talking about and I thought it made it in, but it didn't. Ed: No. Kito: It's quite possible. And oh yeah, the other cool thing that I think is worth mentioning is View Actions. Ed: Yes. That's another good one. Right. Another one that was close to the finish line for 2.0, but we didn't make it. So, yes. That's good to put in. The capsule statement for a View Action is it's a button that clicks itself at a programmatically defined point in the JSF lifecycle, which you declare in the Facelet page. So, if you want to have…the most common use case for it is when you're doing – GET-based navigation and you want to make sure that parameters are properly initialized and you might have to do some action on the incoming request data that's coming in, and run that through various parts of the JSF lifecycle. So, the View Action is certainly handy for that. Kito: Yeah. And before you could always use the pre-render view event, but it's not really specifically designed for that— this is a much better way to do that kind of stuff. Ed: Yeah. Kito: Alright. So, I think that'll be great. And you know…I think what we're looking at in terms of adoption with JSF 2.2, right? It's basically out now in Glass Fish, right? And as a standalone implementation. I don't think MyFaces is out yet. I actually asked them recently and they said they're working on it, but there's like a…in the typical MyFaces fashion, there's no particular release date for the implementation. Ed: Yeah. They're certainly working on it. I know I've seen some issues coming across their issue tracker that Leonardo has filed. Leonardo is also an expert group contributor that I'd really like to give a tip of the hat to because he was very helpful in the flows, and also a feature that enables Flows. It's kind of hard to talk about because it's so difficult to describe, but it's the window ID feature. And Mark Struberg and Leonardo Uribe from the MyFaces team were really helpful in defining that. And that…the intent of that feature is to really give support to JSF for the first time for the concept of a browser window or a browser tab. So prior to that, there was no way in the spec to really identify that a particular view was bound to a particular browser window or browser tab. So now, there's an extra piece of information that gets conveyed as long as you are in a browser window or browser tab that can let you keep things going forward in that same context. And we call that window ID, and that feature is totally essential for flows to work. Kito: Yeah. And that's something -- did Seam 2.x have that? I can't remember. I think it might have. I also think some of the…I think there's some scope work done by…I forgot his name. A guy that has actually done some work with Neil Griffin from Mimacom… Ed: Micha? Kito: Yeah, Micha. Yeah. He was doing some scope stuff, I think, for Spring 3.something. It had the window stuff in there, too. So, I think it's one of those concepts that it took the industry a long time to realize they really needed to have it sort of baked in everywhere. But I think it's a very good thing to be there. Ed: It'll be interesting to see how that also plays with Portlet because we did our best to make sure we covered all the bases, but I have this lingering suspicion that we're going to come up with a need to do some revisions. Another thing we did—and this was something that Leonardo was really helpful with—was craft the window ID solution in such a way that it can be entirely pluggable. So, that was a top level requirement from the MyFaces community. And I agree that it needed to be in there as well. So, we tried to make it so it's as lightly specified as possible, while still providing the necessary capabilities. Kito: Yeah. That's really important. Especially for JSF. Any time I run across something in JSF that isn't pluggable, I get annoyed because I'm so used to everything being pluggable. Ed: Yeah, I know. It's, of course, a double-edged sword, and it's important for technology adoption, but it's challenging for technology maintenance. Kito: True. Alright. I've got one last key question here. One of the features that was added sort of at the last minute to JSF 2.2 is stateless views. Ed: Yes. I'm glad you brought that up. That was one of these ideas that back in the JSF 2.0 days, partial state saving was really a feature that came in at the end, and provided a big performance boost, and was driven in there by…at the time, our implementation guy, Ryan Lubke. Well, Manfred Riem did the same thing with stateless JSF where he came in and said "hey, we really need to get this, this isn't that hard to do. For one particular definition of it, you know, anything you could define and say it's arbitrarily hard, or arbitrarily complex, but if you define the problem narrowly enough it becomes tractable." And so, he created a solution where you could, on a per-view level, declare that a view is stateless. So, there's a new attribute…well, actually we reused an existing attribute, we already had the transient attribute, so every UI component has a transient attribute. And now, you could just say <f:view transient = true>, and that will cause the entire view to be stateless. So, there's no state management impact at all. Kito: Yeah. And I think for those who don't know, one of the big reasons that that's actually preferable in some cases is basically resources, right? Ed: Yeah. Kito: So, JSF view has a component state, has a lot of component state if it's a really large view, and that can impact the amount of RAM consumed on the server, which in larger applications makes a difference. Ed: Yeah. Big time. Kito: And also, one of the other things that I run into that makes this appealing is when you start doing—and I know there's sort of that blurry line between adding a little bit of extra JavaScript to a JSF application and writing a full-blown JavaScript client, but I've been on projects where there's a decent amount of custom JavaScript, but you're still using mostly JSF stuff. But maybe there's some advanced thing we're doing where we're manipulating some components, maybe with JQuery on the client, and we need to synchronize that state with the server. And the last part is what's a pain, right? The idea that now you have state in two places, and you have to worry about synchronizing the two. And there were some days where I was just like, you know, I really don't want state right now. So, this allows you to basically not have the component tree on the server worry about the state in cases where it's not necessary. Ed: Right. Yeah. The state is the key thing. That's what separates JSF from these client side things—where the state lives. I'm very fond of saying that, and I've been saying this for at least six years. You have to look at every web application as a first-class distributed application. And the art in building a distributed application is defining what's the best allocation of processing tasks to processing nodes. And where is the UI state processing task going to be? And that's the question that people are trying to answer. Kito: But I think JSF offers other…you know, obviously, state is a very important part of it. But really to me, that sort of prepackaged integration with the backend is still nice. Because you kind of feel like some of the other mechanisms now that are more client-centric, you're kind of rebuilding a lot of that stuff, and now, there's frameworks that do the sort of client side binding, which is pretty much what JSF does on the server side. So, the ability to have some really cool looking widget, you know, all styled in JavaScript and then have it integrate perfectly…not perfectly, but seamlessly with my backend, I still like a lot. Ed: Yeah. No doubt. That's the sweet spot. Kito: Yeah, definitely. Alright. Well, I feel like my interviews sometimes are like two-hour long interviews. So, I figure we should probably wrap up. Are there any other thoughts you have? Any thoughts about what might happen beyond 2.2? Ed: Well, I want to also point out that we've been in the business of engaging the community from the very beginning with JSF. People may not recall, but their JSF implementation was the first part of Java at all—client or server—that was ever open sourced. And we've always wanted to keep that as open as possible so people can engage. And if they go to jsf.java.net, they'll find the links to all of the mailing lists and user forums and such. And it's a technology that's very mature, but we still are developing it actively, and we're still trying to meet the needs of the users. Kito: Yeah. And you can always joining any mailing lists, give us some feedback there. And the thing I always tell people to use is the issue tracker. If there's something that you're having an issue with, file a bug because often, people will develop their own libraries to handle things, and they don't file an issue for it. Because sometimes we don't…we just may not realize it's something that people need. Or we may realize it's out there, but not realize quite the level of interest in it. Ed: Well, the link for that though is jsf.java.net/issues. And I believe that will take you to—yes, it does—redirect you a few times, and eventually take you to the place where you can enter the JIRA. Unfortunately, you have to sign up for the JIRA, so it's not like you could just log issues anonymously, but there's a link there for joining. It's just a regular Atlassian JIRA instance. Kito: Yeah. Cool. Alright, Ed. Well, I'd like to thank you for taking the time to meet with me. I'm sorry, I think we rescheduled like three or four times, but we finally… Ed: Yeah. It took a while. That's alright. It's summertime. Kito: Yeah. Indeed. And hopefully, we can do this again after the next release or sometime in the future. Ed: Indeed. Kito: Alright. Thanks again. Ed: You're welcome. Happy to be here.

Print article (all feeds)

Suggest JSFCentral features.

Sign up for our newsletter! Email address:



The Editor's Desk Podcasts Inside Facelets In the Trenches



Free Poll - Take Our Poll