JSF Central - Jason Lee in depth: Mojarra and Scales
JSF Central

 Articles & Books 
Community Chat
Jason Lee in depth: Mojarra and Scales
by Kito D. Mann
25 Mar 2009 02:30 EDT

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Jason Lee about Mojarra (the JSF reference implementation), the Scales component library, and all things JSF. This was recorded in September of 2008 at JSFOne.

Podcast (MP3)
Welcome to the JSFCentral podcast #12 for the week of March 16, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hello, I am here at JSFOne and I am going to chat a bit today with Jason Lee, who is a committer on the JSF reference implementation, also known as Mojarra. I am going to talk to Jason a little bit about what he does, his work on Mojarra and a few other JSF topics. This is the first JSFOne conference that we are at. Jason was kind enough to make it out to speak at the conference. Jason, why don’t you just tell me a little bit about yourself and what you do on a daily basis?
Jason Alright, I am a Senior Java Developer with Sun Microsystems for my day job and I work on the Glassfish Administration Console, which obviously uses a fair amount of JSF in that. My primary responsibility there is actually developing the admin console itself, not so much the frameworks that we use. I do a lot of that work kind of on the side at lunch or in the evenings. Late at night is where I get a lot of my JSF-specific work done. I have been working with JSF now for three years. I started off when I was at a company called International Environmental in Oklahoma City, Oklahoma. We had a real mix of technologies in the environment and we migrated to JSF on Tomcat and then we eventually went to the full EE stack under Glassfish. My involvement with JSF kind of grew out of that. We needed support so I found the forums and IRC channel and started asking questions, then over time got more comfortable. I got to the point where I could actually start answering questions and then Ryan Lubke asked me to get involved working on Mojarra, simply known as “the RI” at the time. That was a little over two years ago that I started working on that. Over time that kind of worked into the full-time gig with Sun working directly on Glassfish. In a nutshell that is the past three years or so.
Kito Okay, cool. Let’s talk a little bit more about Mojarra in general. There are a couple different JSF implementations, right? There is Mojarra, or “the RI” or “reference implementation” – whichever name you want to pick. It took me a while to start actually using the term Mojarra. And then there is MyFaces, right? Take a step back and just explain to everybody what the differences are between the two.
Jason The history there, from what I understand, started out as a licensing issue. MyFaces wasn’t real happy with the license Sun had on it so they started their own implementation of the spec. I think a lot of those licensing issues have been resolved for the most part. Of course they both implement the spec and MyFaces has had the 1.2 version out now for about a year. I think it was last summer it was released. With Mojarra, we have been compliant with the 1.2 spec since it was released – two years now. I’m a little biased because I work on it, but we have a longer history with the spec so what we are getting to now is more performance issues, where we are having issues in the tracker or maybe some really odd corner cases. By and large it’s a really stable implementation of the spec and Ryan and Jim Driscoll do a great job there. They are the two full-time guys on the implementation, employed by Sun. I think MyFaces seems to have a real strong presence in Europe. Most of the guys that I have met are mostly European and they have a real strong 1.1 spec. I think looking back at 1.1… when 1.2 came to the front, the RI version of that didn’t get as much attention, just because of resources as Sun focused on getting the 1.2 spec out.

So trying to be honest, I think MyFaces 1.1 -- if you are into that environment -- might be a little more stable. Certainly it’s more actively supported. Not that Sun doesn’t [support it], but Ryan and Jim are busy maintaining 1.2 and trying to do the implementation for 2.0 as we work on that spec. The Mojarra 1.2 is probably a little more solid on that front. Not a whole lot but that is just kind of me being as honest as I can be. There is an obvious bias.

Kito Right, okay. So in terms of Mojarra, it is the reference implementation, right? So it is supposed to comply with the specification. But it also has some unique features. Can you talk a little bit about what sort of features it has over and above the standard JSF spec?
Jason The Groovy support is probably the biggest thing we have added. Ryan implemented that as sort of an experiment. His goal with that is to be able to – as you are writing JSF artifacts, components, or what have you, you can write it in Groovy, using the more Java like syntax. You can deploy your application as you work through developing that and fixing bugs, and you can change the Groovy file on disk in your application server. You make those changes, the runtime detects those and will reload the class and run them without going through that compile/deploy cycle. His vision of that is once you are done with that you take the Groovy file, rename it to .java, put it in your Java source tree compile and run a compiled version of that.

I think in practice we will probably see people not doing that. I think once it is compiled once, it is byte code in memory, so you will have a little performance hit probably at startup. It certainly is a nice tool for rapid prototype and rapid development on some of those JSF artifacts.

Kito Okay, cool. You do work on Mojarra, the implementation, but you also work on Scales which is like a Mojarra sub-project. So tell us a little bit about that.
Jason Well, Scales started out in what we called at the time the “RI sandbox.” It was an area that Ryan had opened up for Mojarra developers to play in; if they wanted a feature to add to the implementation or that sort of thing they could work on it there. We relaxed the rules a little bit in terms of committing and code reviews. When I started doing the component development I needed a place to put that so Ryan and I got to talking and we stuck them there with the goal of eventually moving that out to the sub-project like we have.

What we found that motivated that to happen earlier is we have fairly strict rules on commit access to Mojarra. The implementation is governed by the Sun contributor agreement which some people kind of balk at. From my understanding it really just says “you retain rights to your code but you also give Sun the right to use it.” I don’t find it particularly onerous but some do, so to kind of ease that a little bit we moved that sandbox to a separate project. That also let us promote that as we got closer to a 1.0 version of that. We were able to manage that externally and hopefully get more external contributions. We have gotten some from that…

Scales is just a set of components that I mostly worked on, either because I really wanted to have that functionality in general, or we have a couple that I developed at a former shop that we needed for our business. We needed multiple file uploads. We were uploading 20-30 files at a time. We didn’t want to click “browse,” find it, and do that over and over, so we developed an applet based approach to that, and it is kind of wrapped up in a JSF component so we didn’t have to worry about all that stuff. You just drop the component on there and off your go. Those were developed at that company, and we were given permission to submit those to the sandbox.

Kito Okay. So just for our listeners, there is a JSFCentral “In the Trenches” article about that component specifically, right?
Jason Yes there is, from two years ago I think.
Kito I think maybe we did it last year – the interview maybe last year.
Jason Maybe so. That’s where those two components came from.
Kito What else is in Scales?
Jason Another thing that we developed there at International Environmental (IEC) was a pretty URL phase listener. We had one particular application where we needed to pass request parameters to the application and… for possibly political reasons, we didn’t necessarily want to have the ?key=value and a bunch of ampersands. We wanted it kind of pretty and a little more neatly integrated with JSF, rather than in our managed bean have to get the external context and get request parameters. We wrote this pretty URL phase listener, which basically is, you map what that URL is going to look like in your web.xml using an EL syntax. It uses some regular expressions when it identifies the request as belonging to it. It will use a regular expression to break the URL apart, pull those values out, and set the values on the EL in your mapping XML file. Then it will pass it on to the regular JSF lifecycle, so without any real extra work, it pulls those request values out, sets them on your managed beans -- or whatever you point to -- and then the page can process it as normal. I think it’s the only non-visual component.

We have some of the YUI, the Yahoo User Interface, JavaScript widgets that wrap the date selector. I actually just did the panel and the color picker. We have the slider and some other components like that wrapped up.

Kito Okay, so why did you decide to wrap those components as opposed to using like the Woodstock components from Sun or another component suite?
Jason That effort really kind of started 2 ½- 3 years ago when I really wanted to get into component development and I needed just a good starting point. I needed something to wrap. I didn’t want to reinvent the wheel necessarily, although some of those components do exist in other places, but if you like the YUI look and that sort of thing, this makes a nice JSF interface for that. I picked that library for that reason -- I needed a good starting point for getting into component development. No one had done that so I thought “I’ll wrap this” and my first pass at those of course were what you would expect. The code wasn’t real clean, but I learned a lot through that.

I kind of re-engineered the back end of that, which is one of the things I will talk about tomorrow: using some components from Woodstock, some annotations for generating the UI meta-data, the JSF meta-data, and for template-based rendering from the JSFTemplating project. That is really where that kind of came from. It started out as a vehicle for learning more about the framework as I worked on the implementation and addressed those issues, both on the tracker and with people on the forums. I just felt I needed to get a better handle on how that worked. So it kind of grew out of that to a more complete UI component library.

Kito So, just to take a step back – you said a lot there – so in terms of the pretty URL phase listener, do you know how that relates to something like RestFaces? Or even the support for similar sort of features in JBoss Seam?
Jason I am not too familiar with what Seam supports in that regard. I have looked at RestFaces and talked to a couple of the developers. There is a philosophical difference in how it is implemented. Not that one is better than the other, but RestFaces, from what I can gather, uses a lot of annotations on managed beans, where you put an annotation there and I think you may define what the request will look like and how to pull stuff out of it. Whereas my approach with the phase listener is pretty minimal in terms of its impact on the code. The managed bean really doesn’t know where the data is coming from and doesn’t really care. I have got a context parameter that defines the mappings that I want to expose to the phase listener. It can require, depending on how you map it, an extra servlet mapping.

Say we were going to look at orders that we had in the system, so we would say /order/1 to get order #1, so we would have to map /orders to the FacesServlet. Then the PrettyUrlPhaseListener would have a list of its mappings and say “oh, /orders, that one’s mine, I’ll take that,” and process the URL. It requires a little bit more setup than the web.xml, but not so much on the Java side. My understanding is that RestFaces does it more annotation based. It requires you to change your Java code a little bit more, which I was really trying to avoid, mostly because when we were developing that, we had a real need to get a product shipped to the customer. We took the minimal approach and it has worked pretty well for us. I am not at that shop anymore but as far I know, it’s in production and not having any issues. It has been pretty solid and stable for them.

Kito Okay, cool. So you mentioned that and then you mentioned the Yahoo UI components. For the Yahoo components, I haven’t taken a look at that library for quite a while but I assume that they add new components every now and then or make changes. Is it something you are constantly maintaining in terms of keeping up-to-date with Yahoo’s UI?
Jason Yes, I try and stay as current as I can. Of course I test all that before I make the change and they have been really good about moving from one version to the next and not necessarily breaking things. There were some earlier versions that were kind of painful that way. I upgraded a PHP based website from 2.3 to 2.5 and all I had to do was change the URL and nothing broke. It has been pretty painless to keep on top of that. They have got 2.6 now so when that hits final I will play with that and try and upgrade that so that we get all the bug fixes and performance enhancements.

Of course they are adding widgets too so I add those as I can. I don’t have them all wrapped yet and I may not. I just look at what makes sense. They offer some things that might be cumbersome to use from a component perspective: the grid CSS which is really powerful and cool but may be difficult to use from a component perspective. I am certainly looking into that because I think it is pretty nice. I certainly try and maintain that. The nice thing about being component based is that the user doesn’t necessarily have to worry about that. They upgrade their jars and they don’t have to worry about the version upgrade and downloading files. It is all bundled there in the jar for them.

Kito Okay, so you work on your day job, but you sound very happy with your external activities. Your day job is working on the admin console. Do you use the Yahoo components there? Or the Scales components? Or do you use Woodstock components or what?
Jason We use all Woodstock right now. There are some things that we would like to do. Ken Paulson is the architect on the team and the JSFTemplating founder. We have talked about, when I came on – I bring that YUI experience, so he is open to using those but we haven’t really found a real need for them just yet. We are certainly open to that as we modify the console and try to make it more functional. Right now we do use all the Woodstock components.
Kito Okay. So again for the audience, can you explain what Woodstock is and also what JSFTemplating is?
Jason Sure. Woodstock is a component set that Sun developed and it was open-sourced in 2006 I believe, at the first of the year. It has been around for a while and it is used by a lot of the Sun products. An advantage for Sun there is that it kind of encapsulates the Sun theming so they get a great set of really powerful JSF components, a broad range of functionality, and a consistent theme across their products. It is themable, as a lot of the bigger more complete components libraries are, so you can change that theme if you want, which we are adding for Glassfish version 3.0. I am not sure about the history before they open-sourced it, but it is a well-supported library from Sun that they use internally so we see a lot of traffic from external people using as well. It is very solid and powerful.

JSFTemplating is a view handler. I think most JSF developers, if not all, are familiar with Facelets, which replaces JSP and fixes a lot of things. JSFTemplating is the same type of library. It is an alternate view handler implementation that if you need to use JSP you get away from some of the pain there. It offers some extra features. It has a pluggable format for the template. It actually right now supports three different formats for your pages:

An XML format that is not really used much anymore. That was the first brush at it. It was really verbose and is pretty much deprecated now.

A template format that is more HTML like. It’s real simple. It maybe looks a little foreign when you first look at it but it is pretty easy to come up to speed.

And in the last year I added support for the Facelets Syntax.

Kito Oh, you are the one that did that.
Jason Yes. Ken asked me if I would be interested in doing that and apparently I can’t say no. So we added support for the Facelets syntax, and it’s mostly complete. There are some incompatibilities with Facelets proper that are typically bugs in our code. There are some corner cases and some odd usage that we don’t necessarily support well but it is actively maintained -- as we find as we try to fix them. But the format is pluggable so if you want to, you can define any sort of… you know, if you want a POJO based templating or MBean -- Ken’s wanting to write something with MBean so it takes that MBean and generates a page based on the MBean you passed to. It is really flexible in that regard, really nice. It has an abstraction layer that takes your template – whatever it may be – and creates a tree of layout descriptors that the layout definition manager then hands to the next layer up that converts to the UI component tree. Really all you have to do is create that layout descriptor tree for your template implementation, and hand that off. Then it does the UI component stuff for you so that abstraction there makes that possible.

It also offers some events. JSF phases are kind of coarse-grained -- you can do this before you render, or after you render, or before view restoration and that sort of thing. JSFTemplating offers a number of things like before encode or after encode, so if you want to set up something before a component encodes or if you want to test to see if you want to render it, you can hook into that and call some handlers, which is a little bit like Scriplets in JSP. I say that very cautiously because I don’t want to confuse people. You define the event in your code and you have a string that basically “I am going to call this handler and pass these parameters and get these values back.” The nice thing about that is a lot of times with managed beans you might have an onClick handler) for a button that does a whole lot of work for a given page. Some of that functionality you need on another page but you can’t really use that method anymore because it is specific to that one page so you duplicate a lot of code, or I guess if you design your system well, you just call a bunch of methods from your action-event handler in your managed bean. With the handler approach on those events, it let’s us write smaller more cohesive methods and then kind of chain those together. “I am going to call this method passing these values. Get this value back and then pass that to the next handler.”

We actually use that for the decode event on components. If you don’t need to do something special, you just want to get the value and tuck it in the component, then you can easily write a handler that takes a string from the request, sets the submitted value and move on. Or date conversion. If you have a lot of components that take dates, you can kind of do the same thing. Write one decode handler and just attach that to the decode event for your various components and reuse that method over and over. It is really powerful and we use that a lot in the Glassfish admin console. We don’t have a single managed bean, just a bunch of handlers that we use. We call those from the events on the page. It’s pretty nice, I really like it.

Kito Alright so you have been working with JSF for a couple of years. Were you working with any other web frameworks beforehand?
Jason I had done a little bit with Struts, just enough to know that I didn’t really care for it. I never really got a good handle of all the XML stuff. I did a lot of copy and pasting and hoping it worked there. Luckily we were able to move away from that to JSF before I spent too much time on it. I had also done a lot with just JSPs and servlets. I would write the servlet, render this JSP, do a lot of forwards -- I did a lot of that. That was painful -- it is the reason all these frameworks exist. On the Java side most of my experience prior to JSF was with JSP and servlets with a little bit of Struts.
Kito Okay. So for those who are currently working with Struts or an older framework, what advantages do you see in terms of working with JSF in particular, in comparison?
Jason JSF being component based, it encapsulates a lot of the functionality that you want on a page. With Struts or some of the action or page based frameworks, you spent a lot of time writing the HTML for whatever widget you want. Then on the server side, either through XML Config or through Java APIs, you have to pull the value out of the request and do the casting or validation, that sort of thing. It’s a little more manual in the setup from what I can remember from Struts, with the validators you can tie in. It’s just a little more work setting up all that stuff, whereas with JSF – of course I mean it’s not without work – but it simplifies that, at least for me. I can drop an input text field on the page and say “I want to validate that this integer is between these two values.” Then the framework does that for me. It renders the HTML and when I submit the form, it will take the value from the request, it will process the validators. If it passes that, then it sets it on my model. I don’t have to get a hold of the request and get the value out. It comes as a string, and then I have to cast it and catch the conversion exception and that sort of thing. It is all handled very cleanly and neatly for me.

From the page authoring perspective it is a lot simpler in that I don’t have to worry about writing all the HTML, wiring things together on the back end. On the Java side it is a lot cleaner in that the framework is pulling this value out, doing the conversion and then finally sending it to the model only when it passes the validations and things that I have set up on it. I can then start working with that value in my Java code, whether it is a managed bean or a templating JSF handler. I have got the value and I can start doing my business logic with it. Usually I pass that to another layer to do anything real serious with it. It cuts out a lot of the boilerplate, kind of the grunt work of shuttling data to and from the view and that sort of thing. Conversion validation, it’s all wrapped up in a couple of components on my page.

Kito Okay, it makes sense. I think at least judging by the people here who are in no way biased; there seems to be a lot of migration from Struts. I am sure it is not just to JSF but certainly some percentage of it seem to be moving, which is a nice thing.
Jason It is.
Kito Alright, so the last question – at least that I can think of right now. JSF 2.0 is coming out and all of us are very much involved with what is going on with it. You talked about JSFTemplating and that is definitely going to have a pretty big impact on the way JSF 2.0 handles templates because it will be some variation of that and Facelets. If you could pick your top three features that you hope that we nail in JSF 2.0, what would those be?
Jason Well right off the cuff my first one would have to be annotation based. One of the biggest complaints that I get from people is that JSF has too much XML, which is odd given some of the other frameworks out there and some of the other integration solutions. But as minimal as I think the XML is, there is some and that bothers a lot of people. Really, when I am writing my managed beans, a lot of time I have to look at another one or look it up. “I need a managed property. What is the exact syntax on that?” I just don’t use managed beans enough to have all that in my head. Being able to put an annotation on there, to define managed beans and validators and that sort of thing, I think will really help a lot in terms of page authoring. From the component development, I think it is going to help a lot there, because you don’t have to worry about defining your component and component family and type, and then your renderer, and make sure you get your strings just right. Then if you get the case wrong, your components are not rendering. There are a lot of ways there that you can trip up and not really get what you are expecting. I think that is really going to help a lot there.

There has been a lot of talk about navigation rules and how to handle that. It would be nice to see some flexibility there in terms of conditional navigation or that sort of thing, like we see with Seam – it has that nice jBPM integration. We probably won’t go that far because it is a little too much for JSF but something more along those lines. I am not too bothered by all the XML involved in that, although some are kind of hoping to see an annotation based approach. I don’t know that I have a real strong opinion there but I won’t necessarily push for that.

Also, the PrettyUrlPhaseListener came about because everything meaningful in JSF is a postback. So the Scales PhaseListener, RestFaces, Seam has a solution… I think Spring has one as well to work around that limitation. In JSF 2.0 we are going to have bookmarkable URLs and we are saying “REST support”. I don’t know how RESTful it is going to be for the purists, but that will be the type of support we will have. That will be real nice too, so that if you are writing a JSF based ordering system and you want to send someone a link, “hey look at this product,” you don’t have to say “go here, type a field in here and click submit.” I think that will really solve a lot of the complaints from some of the detractors of JSF, that we will be able to act more like a website, more than just a post only web application. I think that will be a really nice feature, real well-received I hope.

Kito Okay, alright, anything else you want to add?
Jason Nothing comes to mind.
Kito Okay. That seems to be what everybody says.
Jason Yeah.
Kito I am not really sure why. I think they remember if there is something they want to plug, but that’s pretty much it.
Jason Nothing I need to plug unless someone wants to go download Glassfish and install it, and buy support.
Kito You can always “pay Jason’s salary.”
Jason Yes that would be helpful.
Kito Alright, well I appreciate you taking the time out to chat, and also for coming to the conference and hopefully we will get to do this again next year.
Jason I hope so.
Kito Thanks a lot, Jason.
Jason Thanks, Kito.
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.