JSF Central - Inside Mojarra with Ryan Lubke
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Inside Mojarra with Ryan Lubke
by Kito D. Mann
21 Jul 2009 12:45 EDT

In this podcast, JSFCentral Editor-in-chief Kito D. Mann talks with Ryan Lubke about Mojarra, Sun's implementation of the JavaServer Faces specification. This interview was recorded at JavaOne 2009 in San Francisco, CA.


Podcast (MP3)
Welcome to the JSFCentral podcast #15 for the week of July 13, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hello my name is Kito Mann. I am here at JavaOne 2009 with Ryan Lubke in beautiful San Francisco, CA. I always love coming back out here. I come here at least once a year for JavaOne. Do you live in this area?
Ryan I live south of San Jose.
Kito Ok, I kind of thought you were – so that’s not super close to San Francisco, but…
Ryan No but close enough.
Kito Yes definitely. So I’m pretty tired because I just had my session today. I kind of want to go home and take a nap. How are you holding up with the conference?
Ryan I’m enjoying it so far. I’m feeling a little more energized after getting our BOF out of the way last night. Now I can enjoy the rest of the conference without having to think about getting up on stage again.
Kito Yes, I am looking forward to the parties tonight. Definitely a good night for it.
Ryan Yep
Kito So what I wanted to talk to you about was Mojarra, JSF 2.0, and the JSF RI, which is what Mojarra is. Before we get started can you tell me a little bit about yourself and what your background is, even before you worked at Sun?
Ryan My first foray into the tech field was training tech support engineers at Gateway Computers. I did that for a couple years and eventually moved on to Sybase and worked as a tech support engineer there, then moved into product support engineering, which was kind of the buffer between tech support and engineering. Then I joined Sun about nine years ago, initially with the Sun One Webtop group, which tried to bring OpenOffice to the web through a browser plug-in that would let you look at your documents through handheld devices or whatever.
Kito So there was a browser based version of OpenOffice?
Ryan It was a plug-in.
Kito So it was all in Java?
Ryan It wasn’t in Java.
Kito Oh okay, interesting.
Ryan It was a native plug-in but it had a web based portal for document management that used DAV. When you clicked on the document link it would actually invoke the appropriate plug-in for the type of document and let you browse it on the web, and then it would scale back depending the device type.
Kito Right. And it never got into production?
Ryan Never took off.
Kito We’ll see if that comes back with all the JavaFX talk.
Ryan Yeah. I have heard some mumblings.
Kito So you were at the Webtop group for a while and then?
Ryan I moved into the Java compatibility group working on the servlet and JSP TCKs, followed by the JSTL TCK, and then eventually the JSF TCK. Shortly before JSF 1.2 was final, I switched into the implementation team and have been there ever since.
Kito That just got me thinking, for JSF 2.0, the beta just came out last week so congratulations.
Ryan Thank you.
Kito But what is the story with the TCK? When are we going to see that?
Ryan TCK is out.
Kito It is really? Okay.
Ryan So it is available now, with the proper licenses of course. We won’t get on that -- it’s a pain point. Part of the JCP process is when the spec goes for the final vote and you have to provide the RI and the TCK and the final spec artifacts. It’s there.
Kito Okay, cool. So you started working with the RI team and there are basically two main JSF implementations, right? There is Mojarra, which is the reference implementation, there is MyFaces, and actually Matthias Wessendorf from Oracle pointed out that Resin has their own implementation, which I haven’t actually looked at.
Ryan I haven’t either.
Kito But it’s there I guess. And then there is a company in China that has an implementation as well.
Ryan I haven’t heard that.
Kito I don’t remember the name of the site now, but there is a whole Chinese one for 1.2. He apparently downloaded the code and de-compiled it to see what version it was because he can’t read Chinese. So there are the other two implementations but from a popularity standpoint it is these two.
Ryan Right.
Kito When you started working on the reference implementation, it seems to me that you made a big impact. I could tell -- honestly I thought Sun had hired like twelve more engineers. I was all impressed. Mojarra is essentially the reference implementation so it corresponds to the spec but there are some other features, right? Some other add-ons?
Ryan Right.
Kito Tell us some about some of these other features.
Ryan Sure. Probably the biggest one is the Groovy support that we added shortly before JavaOne of last year, which lets you write any JSF artifact, be it view handler, managed bean, component, renderer, in Groovy. It lets you rapidly prototype without having to go through the whole code-deploy-test cycle that plagues most web app developers.
Kito Right. I can write the Groovy class and just change any line and I don’t have to re-compile or anything.
Ryan Right. There are a few caveats, like if it’s a view handler or something that is application scoped or whatever, if you make changes there you might have to touch the Faces-configfaces-config file to cause it to be reloaded. That’s minor compared to having to do the whole rebuild.
Kito So the Faces-configfaces-config reloads without having to deploy at all so that’s a nice feature.
Ryan Right, timestamp changes and it reloads itself.
Kito So I must say it is kind of a pleasure to make changes and have it automatically pick everything up very quickly.
Ryan Ed did a lot of rapid prototyping using that stuff last yearfor some of his stuff and he said he enjoyed it a lot.
Kito Cool. So what made you use Groovy instead of one of the other scripting languages like Ruby or Python or something?
Ryan There are a couple of things. The first thing that attracted me to Groovy was the fact that I could use Java syntax. I didn’t have to learn any new syntax to use it, so zero learning curve. The second is that at the time I did it, Groovy seemed to be the only language that I could ask it for a class file and use that class file like I would any other Java class file. So if I am creating a managed bean, I instantiate the Groovy object, I have a class file. So I can do anything I would with a normal class. Ruby and others didn’t seem to have that feature at the time. I believe they are working on that. That has been what was mentioned to me when I have talked about it. So as soon as that’s available, we will definitely integrate that.
Kito Cool, I know I was talking to Cay Horstmann about different languages, and he was saying that he has a student who is working on Scala Faces, which I think would be interesting to see. He said it is probably not something that is going to be some production product, but I think it will be an interesting proof of concept.
Ryan Absolutely, I would love to see that.
Kito Yeah, me too. So you have the Groovy support, right?
Ryan Right.
Kito You can basically very quickly build your applications without any kind of re-deployment cycle. With Groovy, it’s a really big syntax overlap with Java so you can take the whole Java class, rename it .groovy and put it in the right location and pretty much it runs, right?
Ryan Right.
Kito Have you experimented with any of the deeper meta-programming features?
Ryan I haven’t gotten really deep into it because I have bugs to face and the typical day job stuff, but if you want to use the Groovy syntax, one of the major complaints with any of the standard bean programming paradigms is that you have your properties, you have all these getters and setters, so use your Groovy bean and have your fields and you don’t have to generate any of that stuff. I have done that.
Kito Right, you have used the properties. I think what appeals to me about it is the fact that if you are using the whole backing bean type construct, where there is some sort of UI-based logic in between your core business logic etc., that stuff does kind of change quickly so it is nice to be able to do that in a scripting language.
Ryan Right.
Kito Whereas your domain model may not really change all that often, so I kind of like the idea of being able to do the backing beans and stuff like that.
Ryan Or the renderers. I was able to quickly prototype up a couple of components and change a few lines of Groovy code and see it display immediately in the browser.
Kito That’s a good point. With Groovy it is a lot easier to output markup in general. Have you experimented with Groovy builders at all?
Ryan No, people mentioned those to me shortly after this feature was released and I made a note to look into it closer and just haven’t gotten to it yet. I think it was you that mentioned it to.
Kito Was it? Good idea. The only thing I have seen that does that is a project called Gracelets, but I haven’t looked at the code to see really how he is doing it. It is called Gracelets because it is built on top of Facelets. It using Groovy builders but I think eventually it goes through the Facelets compiler and everything. You might want to check it out. I have been meaning to play with it myself.
Ryan For a year.
Kito Yes exactly. So you added the scripting support and everything. There are also some other features that Mojarra has that are not part of the actual JSF spec.
Ryan Right. The verify objects feature, the context init parameter -- if you specify that and set it to true when the application starts, it will do some basic sanity checks on the artifacts you have configured in your Faces-config. For managed beans it will make sure that the classes have no argument constructors, that you can find the class. Same with a validator’s constructor and a components’. Just double-check your work. Some other minor things that come to mind – I remember a thread on TSS maybe a year and a half ago about some of the drawbacks of client-side state saving, specifically that you can have a page with the client-side state in it and submit that three or four days later and still get a valid response from the server. We quickly implemented a feature that you can enable. It’s not on by default just for backwards compatibility reasons. You can actually set a timeout for client-side state. Like server side state, when the session expires it will throw the expired exception when you detect the client state is now stale.
Kito Okay.
Ryan One other thing that we had out of the gate, and thanks to some ideas from Jacob Hookum, was the ability to run JSF 1.2 in a Servlet 2.4 environment if you are using Facelets. I think that really helped increase adoption for JSF 1.2.
Kito I think it made a huge difference.
Ryan So thank you, Jacob. Some other little things we have added are... for example with client-side state saving you have to use serialization and as we all know serialization can be kind of – it’s not performant in all cases. We have added a way to plug in your own serialization mechanisms.
Kito Really?
Ryan You could use JBoss serialization if you so desired. We have also added other integration points for containers so it might not be as interesting to typical developers, but it allows you to do resource injection in Tomcat Jetty. JBoss has implemented this for their container, as have the other vendors like Oracle.
Kito You read my mind. I was going to say “isn’t there some sort of SPI interface?
Ryan Right, we have a couple, and we will have a couple more for 2.0.
Kito Okay cool. So if you look at the work on the RI up to the new features in JSF, were there any big challenges or areas where you really tried to improve things like performance or other sorts of issues you were working on before?
Ryan I guess between the initial release of 1.2 and 1.2.04 was when we were still kind of rocky on some of the content interweaving stuff. That’s pretty much the time we focused on getting as many bugs fixed as we could, and performance. We did use JMeter to do some profiling, looked at the memory hotspots, and tried to tune the best we could. There are some things we can’t fix just because of the specs. State saving is one of them. We did what we could, but we were able to see a noticeable difference from the initial release.
Kito And for those who are not aware, content interweaving would be….
Ryan Many of your listeners may remember with JSF 1.1 you had to use the <f:verbatim> tag for any template text within a particular view so it would get output in the right location. JSF 1.2 got rid of that, so you didn’t have to use a <f:subview> or have to use the <f:verbatim> tag. Just to make it a little easier.
Kito Okay, cool. So I guess over the last year and a half or so you have kind of been maintaining the 1.2 branch but also starting work on JSF 2.0 at the same time which must have been a lot of fun.
Ryan It has its moments. It comes and goes. There are points of frantic activity to get a 1.2 patch out because people are yelling and trying to juggle the other stuff.
Kito Right, and Mojarra which application servers does it ship with? It ships with basically all the Java EE servers, or most of them?
Ryan I think all of them right now except for Geronimo.
Kito Okay, right because Geronimo is MyFaces. Do you know if many of the vendors…I know IBM had a very customized version for a while, which I have had the joy of working with. Do you know if the other vendors did much customization on top of it?
Ryan I don’t think so. I think JBoss had some sort of integration points to get rid of some logging messages that they didn’t like and something along those lines, but other than that I think it’s just stock runtime. I could be wrong.
Kito Who knows? At least it helps just knowing that it is supposed to be the RI as opposed to MyFaces, just so you know which one you are dealing with, which is always good. Especially for the people who develop on Tomcat and then try to move to whatever server, you have to pick the right one to start with. So you have been working on a lot of the JSF 2 stuff. I imagine that has been consuming most of your time in the last few months.
Ryan A lot of it yes.
Kito And lots of great new features, right? I think my favorite is probably the composite component feature. A lot of people like the resource loading, or just the fact that it includes Facelets. What is your favorite feature?
Ryan I’d have to say composite components. I really enjoy how fast you can knock out a component with very little work. There are a lot of great features. The Facelets is a nice one. Having the ability to template is great.
Kito Yeah, definitely.
Ryan We now have bookmarkability, which I think is gonna go a long way to turning the heads of some of the people that turned their back against us because we didn’t have that feature. Resource loading is nice. We have got some other less well known features like being able to order configuration files now, which was kind of a pain point, especially for the portal guys. As you know, view handlers can be decorated in a certain order and that order was somewhat undeterministic in 1.2. Now you are able to control that. Minor but important.
Kito Yes, very important. I notice all of the component vendors were very happy about that too.
Ryan There are other little things, support for multiple configuration files within a jar.
Kito What I like is the API or just basically a few methods, but some sort of insight into the navigation rules. I was very happy that now you can programmatically access navigation rules.
Ryan You can give it an outcome and actually get a handle to the navigation rule that would be applied. Or you can actually add them, query them all. Now you can do declarative navigation right within the view without having to have navigation find the faces-config at all.
Kito Right, which is something a lot of people are happy with, I think. I think having the access to the navigation rules and the basic way to represent cases really gives you a lot of dynamic possibilities too.
Ryan The bookmarkable URL feature relies heavily on that.
Kito That’s a good point.
Ryan Because the new components that provide this feature, <h:link> and <h:button>-- in order to generate the URL you have to give it an outcome. So you query the navigation handler for that outcome and generate the URL.
Kito That makes sense. Another feature that people probably haven’t heard much about is the page parameter feature.
Ryan That ties heavily into the bookmarkable URL. It is interesting, they kind of have their own life cycle but you can define parameters that need to be present for the page and you can attach validators and converters just like any other JSF component.
Kito Which is definitely a good thing, because I have had clients where they want to be able to pass in some parameters but the conversion doesn’t run, so then you have to decide what you want to do about that.
Ryan It is all baked in now. It is gonna get better with 2.1 because I think page actions are going to be next on the list.
Kito Right. Dan Allen has been very vocal about the page actions feature. So that way you basically have actions that could fire for a given page.
Ryan You can do it now, but it requires a little bit of extra legwork.
Kito Right, because you have events, so they have a whole bunch of new events, one of which could be like before the page is rendered so you could call a method then, which is sort of like a page action.
Ryan You can fudge it.
Kito Yes, exactly.
Ryan Events is another big feature. A totally customized event bus. In your application if you have specific needs, you can define the event for it and fire it off. It is really easy to do.
Kito What is your sense about how performant that is? The events are fairly granular, like before the component is added to the view?
Ryan We have added the PreAddToView event. That is one of the things I really want to look at but the JBoss guys said that as far as Seam goes, they are firing events all the time and it hasn’t been a huge impact, but we will see. If you have a really complex large view like some of these people do, there may be something that we need to look at. We have written it to be as performant as possible.
Kito So if you could look at all these features, which there are many, what was the most fun part to work on?
Ryan Probably – and this is somewhat sadistic – the partial state saving feature. I enjoyed working on that a little bit. I have always had a thing for state saving and trying to optimize it. It is a tough issue, but that was a fun week and a half to get the initial cut done. Ed, of course, did the prototype work for the composite components by going back in there and trying to do some optimization there and plug holes and whatnot. Obviously it’s just a prototype. It was interesting to see how that was all working.
Kito It is definitely interesting, the whole idea of retargeting objects from the calling page to the actual component.
Ryan Yeah you got that, but with bean validation now, you don’t really need to re-target your validators, you just pass in your beans straight in and you don’t really need to worry about it.
Kito So what you are talking about then is – there really is a lot of stuff in JSF 2.
Ryan I know. It’s like “well you can do validation this way OR you can do it this way.” There are like five different ways to do it.
Kito Right, so validation has been improved. Not only conditional validation – not conditional but conditional in the sense that you can have dependencies on different values in one validation phase -- which was a problem before. Because if you wanted it to say “these two components are valid depending on each other“ -- that was kind of difficult. So that is doable now. That will make a lot of people that went through pain with JSF 1.2 happy. Then there is also integration with the bean validation JSR. Bean Validation is a separate spec that will be part of Java EE 6 that allows you to annotate your model with actual constraints, right?
Ryan Yes and you can set up validation groups, just anything you can do with bean validation you can configure with JSF.
Kito Right and I think that is great. Two or three years ago I had a client that actually – I think this is even before the Hibernate Validator was popular -- they basically wrote their own model validation layer, but they were doing client validation in JSF views but they weren’t using the JSF validation model and everything, because they didn’t really understand that part too well. I am very happy to see all of this standardized.
Ryan The nice thing about it is if the bean validation runtime is there, you don’t have to do anything, it’s just going to be used automatically.
Kito And the bean validation runtime – even though it is part of the Java EE 6, you can still download it and use it in Tomcat or whatever.
Ryan Yeah absolutely.
Kito It’s definitely a nice feature. So those were ones that were fun. What do you think was the hardest part?
Ryan Configuration ordering. You have so many different combinations. This can be before this. This can be after others. Then just trying to get it as accurate as possible. It took a couple of weeks to get the algorithm proper.
Kito So basically with configuration ordering, you have different artifacts which are normally JARs that have a faces-config, right? So let’s say you throw RichFaces in your class path and then you throw in Tomahawk in your class path, and you throw in some other library. They want some ordering like one wants to be in front of the other. Let’s say you put it inside of a portal, then you don’t really have to worry about it, right?
Ryan Right.
Kito But what if two artifacts say they want to be before the same thing?
Ryan The order in that case is indeterminate. They will both be before the same thing but they may be swapped. It’s a partial order so it is not going to be absolute. But there is an out for you there, in the WEB-INF/faces-config you have the option to use absolute ordering so you can apply full control of how everything gets ordered if the partial ordering isn’t doing it for you.
Kito Nice, so for those power users who actually run into conflicts and understand what’s going on, they can go and do some tweaking there. You can tell this is a part of a spec that I didn’t really read the emails for it. So you are saying that was the hardest. What was the hardest about it?
Ryan As Jim Driscoll my counterpart would say, it was like evil Sudoku. Getting the algorithm sufficient to the point where we could produce accurate results for several different test cases. Some of those cases came from the spec itself and some are some that I derived in my head. When you have the combination of others, and some things want to come before others, trying to shuffle those around properly, it’s a pain.
Kito I can definitely see that. One of the things we didn’t really talk about was the Ajax integration stuff. So now in JSF 2 there is actually an Ajax integration layer. Did you work much on the Ajax part?
Ryan It was Roger and Jim mostly.
Kito Okay, so there is the JavaScript layer but there is also kind of the partial tree traversal part on a client.
Ryan You have the partial traversal stuff on the server side, so that allows you to be very efficient when you are sending IDs that you need to execute and render for an Ajax request. The partial view context is what makes that magic happen. The Ajax support is very nice. You can use the low level JavaScript calls directly or you can go the declarative approach with <f:ajax>. It’s very easy.
Kito And <f:ajax>, the whole feature really, for users of Ajax4jsf, it really makes a lot of sense, kind of intuitive. I’m not saying it’s all Alexander’s idea from Exadel, but definitely just the idea of being able to pick specific components that need to be re-rendered and everything.
Ryan Right, it’s very easy. That was the whole point behind it: to make it as easy as possible.
Kito I think we will find that once vendors start using the Ajax layer, also, the components will work better together. It is kind of a big deal.
Ryan Yep we are close to that, in fact you were at the BOF yesterday with the Ajax portion of the EG and we are getting very close to that.
Kito Yeah, because they are already prototyping with ICEfaces 2 and RichFaces and everything, so that will be exciting to see.
Ryan Yeah, that will be a huge step for it.
Kito Another thing – this has never been an area I have been too interested in but I know Martin Marinsheck was interested in the whole state saving stuff in general, right?
Ryan Yep.
Kito You mentioned the state saving, but it is probably a good idea to point out that part has been redone as well.
Ryan Yep, Martin provided some of the initial legwork, as far as some of the high level ideas of how to do it, and some initial patches. We spent a week talking with these guys, working on the prototype, and we eventually had something that is working. There are still a few kinks in there that we know about and we are going to start addressing after JavaOne. The initial result is a page using client-side state-saving would have about 10k worth of state, and it is down to 2k.
Kito Wow. Is that true also for server-side state saving?
Ryan It should be. It will reduce the session footprint quite a bit.
Kito Wow, so that’s pretty impressive. I didn’t realize the order of magnitude.
Ryan We have a way to turn on and off the partial state saving, either wholesale or per view ID. There are probably going to be some cases where partial state saving just doesn’t work if the page is overly dynamic. There is just no way to capture it properly. We have a way for you to deal with that.
Kito For some people – especially for certain pages – they really don’t want any state saving at all. There is a way to turn it off, isn’t there?
Ryan No, there is no way to really turn off state, but as far as Mojarra goes and I think MyFaces may do the same thing, if you have a read only page, just don’t include a form and no state is saved.
Kito That’s a very good way to look at it. Mainly because of the way Facelets work, right?
Ryan There is that, but the view handler is smart enough to know it is not going to need to buffer or do anything like that if StateManager.writeState() has never been called. Additionally you should be able to -- now with Facelets -- mark the UIViewRoot as transient.
Kito That is what I was thinking of. Okay
Ryan It could be easier but we will get it.
Kito I think that although there are people like Gavin King who really wanted the stateless pages and everything, I think the majority of users just really want easier development and things like that.
Ryan One step at a time.
Kito Yes exactly. Alright well I think those are all the basic questions I can think of right now. I am looking forward to getting people to use JSF 2. Are there any special features you think you might add to Mojarra?
Ryan I am going to start evaluating the other scripting languages and see what state they are at, so we will see about that. We had a long talk at the bar last night about EL performance issues, so we might start looking into that a little more to see if we can come up with a custom solution for that.
Kito Would that be outside of the reference EL API stuff?
Ryan It would have to be until we can get the EL EG to make some changes, if we could come up with a reasonable prototype.
Kito I definitely think you should check out Mojarra. The beta for 2.0 just came out last week. Now this is in June at JavaOne. But by the time you hear this podcast there will probably be another beta but we will see. Any last words? Comments?
Ryan Definitely download the beta and if you have any issues let us know. We want to have feedback, be it positive or negative. If you have an issue we will get it turned around as quickly as possible.
Kito Just in case you weren’t aware, Mojarra is open source and there is a mailing list, dev list, there is a bug tracker, you can download the code. I just built it the other day so it is actually easy to build once you check it out of the source tree, if you are that bleeding edge. There are also nightly snapshots if you want to get something between the betas.
Ryan The Mojarra developers, including the spec team, are all on the ## JSF IRC channel. So if you want to talk to us we are there.
Kito Alright, Ryan. Well, it’s certainly been a pleasure. Thanks for chatting.
Announcer That’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann.


RSS feed(all feeds)

The Editor's Desk
Podcasts
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.