JSF Central - JSFCentral Episode #25: Werner Punz on MyFaces Ajax and MyFaces Ext-Scripting
JSF Central

 Articles & Books 
Community Chat
JSFCentral Episode #25: Werner Punz on MyFaces Ajax and MyFaces Ext-Scripting
by Kito Mann
29 Mar 2012 03:00 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann discusses MyFaces Ajax, MyFaces Extensions Scripting, and alternative JVM languages with Werner Punz.

Podcast (MP3)
Welcome to the JSFCentral podcast #25 for the week of March 19, 2012. This series of podcasts features interviews with leaders and innovators in the world of JavaServer Faces technology.This interview was recorded in April of 2011.
Kito Hello. My name is Kito Mann. I am here at Confess 2011. Is this like the fourth year of JSFDays or something?
Werner Something like that. Yes.
Kito Yeah. So, this is the new name for the JSFDays conference sponsored by Irian Solutions, which does MyFaces' training consulting, and lots of other JSF consulting work. Today, I'm here with Werner Punz. Werner is a big MyFaces' committer, and also works for Irian. So, why don't you tell me a little bit about yourself.
Werner Well, I work mainly as a consultant for Irian. And I basically joined the company over the MyFaces project. I think it was about five years ago, or six years ago. My work in MyFaces itself is mainly the JavaScript part, currently, and also the Extensions Scripting project.
Kito Okay. Anything about your client work? What sort of clients do you guys work with?
Werner Well, I basically am assigned to tasks currently within the Credit Suisse, which is a major client for the Irian Company.
Kito Alright. So, you've been working with extension scripting, and I guess the JavaScript portions of MyFaces. So you obviously have an interest in other -- or non-Java languages.
Werner Yes. I have a huge interest in non-Java languages. I don't know when it started and how it started but as for the JavaScript part, over the years I became entrenched deeper and deeper into the language itself. I think the turning point was around 2005 or so. Before that, I thought, like many people, that JavaScript itself is just a simple language, where you could do just a little bit. And then, I think the turning point was when I first saw the Prototype library.
Kito Ah.
Werner I think that was the turning point for most people. Because then, I suddenly saw that there is something underneath ... which is way deeper and which allows way more flexibility than most people knew back then. And with the Prototype library, I got deeper and deeper into that language, and well, now I'm here. But still my main work most of the time is dealing with Java.
Kito Right.
Werner Currently, my main work for the customer is JavaScript, but normally it's Java, still.
Kito Okay. Did you...prior to Java, had you worked with any other languages? Like in a university or...
Werner Yeah. In the university -- well, I started studying computer science in 1990 or so. So obviously, I had to deal with what were the languages of the time, what are the two for tutorial language, then I was deeply into C/C++ for a while. And where as other languages ...like I even once programmed in a language I didn't know. [Laughs]. Or several times.

And I cannot really count which languages I used up until now. But from the big language groups, I think the only language type I've never used is a language that implements predicate logic. Like Prolog I've never used Prolog.

Kito Yeah. Me neither.
Werner And I mean, I have used functional languages, but I've never touched Lisp. I'm not very comfortable with the syntax of Lisp.
Kito That was my problem. I was only exposed to Lisp in college, and I didn't like it. I couldn't get over the parentheses. I just felt like every line had about 20 or 30 parentheses in it, it was just too hard. It was not hard, it just...
Werner Yeah. I think that's the biggest problem most people have with it.
Kito Yeah. And I've heard once you get past that, it's better. And supposedly, Closure doesn't have as many parentheses. But...
Werner Well, it's still bad enough because also, you have this prefix syntax in Lisp, which doesn't really map to the natural flow of thinking very well.
Kito Yeah. I think that's what makes it more difficult. Well, looking at all of the different languages out there, I mean, there's ... in terms of the more recent languages, especially on the JVM, we've of course, got Java, and then Groovy...
Werner And Scala.
Kito Right. And Scala.
Werner And Closure.
Kito Closure, Erlang.
Werner Is Haskell already ported?
Kito Oh yes, Haskell. Yeah. And I haven't really worked with Erlang or Haskell or anything. But do you have a preference? Is JavaScript your favorite other language?
Werner No. Actually, not really. I just have to deal with it all the time. I mean, JavaScript itself, from its possibilities, is a really nice language. But it also has some shortcomings, which could easily be resolved, but which never have been. Because you always could mask those shortcomings with some extensions. But I personally think something like a namespace should be in the language core, not being mapped to some kind of escape method or something like that.
Kito Yeah. Wasn't there a -- I know they were working on a newer version.
Werner Yeah. They were working on a new version, which should've added namespaces, and classes, I think. And they dropped those extensions again. And then, they did some odd extensions like native data types for speed reasons and whatever, but the classes and the namespaces were dropped as far as I know. I haven't looked at the latest spec.
Kito Yeah. I'm kind of sad to hear that. Okay.
Werner I always have a problem with not having those features in because you'll always end up with hacks, which are slower than what would be there if it would be implemented natively. And you definitely need those constructs.
Kito Yeah. Definitely. What are your thoughts on Groovy?
Werner Well, Groovy is a nice language. I did some stuff -- I wrote a small compiler with it once. And also, I had to deal with it in Extensions Scripting. I think Groovy is the easiest language -- if you come from a Java site -- to switch over to. But on the other hand, it's untyped. And the untyped part is way slower than Java, of course. That might be resolved in Java 7, but currently. If you really need speed, then Groovy is definitely not the right choice. But in many occasions, you don't really need the speed and the code reduction is enormous. But on the other hand, Java 7 has Closures, as far as I know...unless they dropped it.
Kito I can't remember if that was in 7 or 8. Right, so it’s just basically adding another file to the archive, essentially.
Werner Yeah. I think it's not dropped, I think it made it into 7. It definitely will make it into 8 if it was dropped in 7.
Kito Right.
Werner And the other big part for code reduction is the setters and getters, which they really have to get rid of.
Kito They really do.
Werner There's something like Lombok, of course. But the Lombok IDE integration, there's a plug-in for Eclipse, I think it already works in NetBeans, with some extensions. But there's nothing with IntelliJ of course.
Kito And what does that do?
Werner It's a set of annotations, which you can put on your properties. And then, you have to recompile, which generates the setters and getters. And a set of IDE plug-ins, so that you don't get errors if you use those annotations.
Kito I see. So, speaking of annotations for getters and setters -- or to generate getters and setters...
Werner That's the best approach you can get currently on the Java side.
Kito I know. That's too bad.
Werner But for instance, Closure ... no, Groovy and Scala have solved it differently, of course.
Kito Yeah. I think it's kind of interesting that with Scala, the getters and setters that are generated don't use the JavaBean syntax at all ... which I find kind of an interesting design choice.
Werner Yeah. I don't know why they did it.
Kito Yeah. So, you've got to use that Bean property annotation if you want the right sort of getters and setters, which --
Werner For instance, in JSF, generally, you always can make a custom ElResolver, which resolves the setters and getters currently.
Kito That's a good point.
Werner I did some testing of Scala in December, because I wanted to integrate it next into extension scripting. So, I needed to get a feel for the language, what is possible there, and what the pitfalls -- especially for the JSF integration. And it ended up that the biggest extension I had to write was the ElResolver. The rest was pretty straightforward.
Kito That's a really good point. So, before we get to Extensions Scripting, you also did some work on the JavaScript/Ajax part of MyFaces 2, right?
Werner Mm-hmm.
Kito So, what was that like? Because you know, JSF 2.0 defines a very simple API that is used underneath -- or used to do the Ajax from a developer's perspective. But there's a lot of work you had to do sort of in the middle to make that work, right?
Werner Yes. It was a lot of work. But I was not the only who basically wrote the scripts. There were two people from Germany also, who basically brought the code over from another project.
Kito Oh yeah. What was the other project called? I remember I saw that in the mailing list.
Werner Uh ... such a bad remembrance of names.
Kito But they had done a lot of the work.
Werner They did a lot of the initial work, especially on the Ajax part. It was a part -- they did about 30 percent of the original code or 40 percent. And I did 6 percent or something like that.
Kito Cool.
Werner But the original code was quite different from what the state of the code currently is. But there's still some code left from those guys.
Kito Right.
Werner And they really did -- it did help a lot. Because from then on, I could start to refactor and clean up the code a little bit.
Kito Right.
Werner And one of those guys has an interesting component library. Almost no one knows, which is DojoFaces
Kito What's it called?
Werner DojoFaces. He did a Dojo integration with JSF, on top of Facelets. He basically wrote the entire library on top of Facelets. And kept it lean that way. Interestingly, I had a similar project going on before I started the JavaScript part. I wanted also to integrate Dojo into JSF, and I was pretty far along, but I went the old component route. And as soon as I saw their approach -- that they had at that time -- was further than I was, I stopped my work. I didn't see any point to do it anymore.
Kito Right. Now, is this library only JSF 2.0? Or does it just use Facelets and like JSF 1.2?
Werner I think it's still -- I haven't had a deep look at it, but I think it was developed for JSF 1.2, and then was brought over to 2.0. So, they added the changes for Facelets for 2.1 ....
Kito Okay. Nice.
Werner It's really interesting because almost no one knows that library. But they have a nice site on the Internet. I think it's dojofaces.org or something like that.
Kito I think I do remember seeing it. I think it's actually in the JSF central product directory, but probably just not updated to the latest version. So...in JSF 2.0, in terms of the spec, there's the simple API and then, there's the --
Werner Layer underneath.
Kito Right. But there's the messaging format part and everything. So, what was kind of the biggest challenge in terms of making that all work? And making it also compatible...
Werner I think the biggest challenge was to be compatible with Mojarra. Because the biggest issue simply was that it was a first ... really, a first draft of the spec, but I wasn't a member of the expert group back then. I'm still not, but I am going to apply for it. And the problem there was that the spec was in its first incarnation -- it wasn't bad, but there obviously were some holes. And some stuff simply had some errors, which were ... as far as I was concerned, I fed every single one of them to the bug tracker. And let's say that the basics are there now. They need some small extensions, but outside of that, I think you can -- it's a good foundation to build upon.
Kito Okay. Did you have any challenges in terms of making it performant?
Werner Yes, I did in fact. Because my structures were quite different than what Mojarra tried to achieve. And I went for an approach, which basically I'm heavily influenced by the Dojo toolkit. I've worked a lot with the Dojo toolkit, and I've tried to follow similar structures. First of all because we had some IBM guys on the team that were familiar with Dojo. And the original idea from them was to build upon Dojo, but I didn't want to do that because I didn't want to carry around a heavyweight library, just for doing the Ajax stuff. So, I tried to be as close as possible as people who would look into Dojo would be used to. So, what we did basically was build an OO layer underneath, and a module system with namespaces and whatever.
Kito Wow.
Werner And on top of that, we built the entire library.
Kito Okay.
Werner We are -- in our code base -- due to that, a little bit bigger than Mojarra, or twice as big. But on the other hand, I think it will pay off in the long-term because of the modularity, and the code structure will be quite maintainable now. And we also have a lot of extensions, which might make it in 2.2 or so, which are not officially enabled yet, but you can use some configuration parameters to enable them.

For instance, we have file uploads working, we can use HTTP GET, we can send Ajax requests queued and un-queued and we can do queuing inside. We have queue control inside. Like you can cover type-ahead situations where you don't want to be hammered down with hundreds of requests sent by one user. Because we can reduce the queue to a certain size. We can define timeouts.

And also, one of the things we carried over from the other project -- the German people carried over from the other project -- was the partial page submit, for instance. So, that you only can submit the parts of your form you want to execute.

Kito Nice.
Werner But that stuff is -- let's say it that way -- it's rather undocumented because I ran out of resources for 2.2. But you can use it if you want, but you have to really look at the code. And some of the postings I did on the mailing list, how to use it.
Kito Oh, so it's not really a documented --
Werner Not really officially -- well, it's outside of the spec.
Kito Right.
Werner So, people can use it, but they have to be aware if they really use it, they have to know what to do.
Kito Right. Okay. Cool. So, tell us about extension scripting.
Werner Yes. Well, the project itself started as a me-too project, originally. We obviously, have been a little bit in a competition with Mojarra. And Mojarra one day, suddenly, brought out a Groovy extension. And I had a little bit of a look at the extension from a user's perspective, and thought it might be cool to have it in MyFaces as well. But on the other hand, I had then the idea that I could do it better. And what it is now is an extension for Groovy, and for Java, with dynamic reloading. So, we can reload, for instance, managed beans or renderers or validators dynamically, if they change. And if you code them in Java, it doesn't matter because it's written in Java as well.
Kito Okay.
Werner And one of the differences we have here is that we do some internal byte code scanning to determine some kind of dependency graph of the artifacts. And which means, if you ... alter managed beans, for instance, you will drop all other references and classes, artifacts at the same time, so that the class reloading properly happens. Because we don't parse anything, we just compile, and then reload the artifacts again. It isn't perfect; it works about 90 percent of the time, but I never aimed it to be perfect because there were some limitations in the JVM, which I could only fix at the byte code level, and I didn't want to interfere with the byte code. If somebody really needs something more sophisticated, they should license JRebel.
Kito That's exactly what I was thinking.
Werner It's more for the developer who needs some kind of prototyping.
Kito Right. So basically, what you're saying is for any JSF artifact, any main JSF artifact, like a backing bean or a renderer or a something, you can write it in either Groovy or Java and reload classes automatically.
Werner Exactly. Yeah. The main thing is that you have to put those files in a special path, which without configuration is the same path as Mojarra uses, like WEB-INF/groovy or WEB-INF/java. And if you need it in a different location, you'll just have to revise the configuration entry.
Kito Oh, okay. Nice.
Werner So, we tried to be as compatible as possible to Mojarra.
Kito I don't know if you can even configure it in Mojarra. You may be able to, but I'm not sure.
Werner And also, we added something else -- you can set a reload path for your web artifacts as well. So, that Facelets is picking up your templates and your resources from another path, which means you can rewrite the path through IDE, and once the service started and you edit something and you hit refresh, then the change in the page comes instantly online.
Kito Nice. So it kind of is like a mini JRebel sort of thing.
Werner Well, only for JSF for now. We had some side projects for Spring, and CDI, but we don't have it integrated yet.
Kito Right. Are those just sort of things you're playing with? Or are those things you think ...
Werner No. It actually wasn't done by me, the CDI stuff was done by another guy who did Google Summer of Code. But he's not in the project anymore, and I didn't have time to take his work and integrate it yet.
Kito Right. Now, this stuff ... it's only going to work for things like JSF specific artifacts, like renderers or converters or things like that?
Werner Exactly, yes. Because it hooks into the framework. And it currently only can work for MyFaces because the hooks go partially straight into the implementation.
Kito Okay.
Werner The biggest problem I had by making it implementation neutral was that there is no SPI for dynamic configuration changes.
Kito Right.
Werner You cannot unload managed beans, you cannot unload components, you cannot register new managed beans into the system without getting into the implementation. There's no way.
Kito I wonder if that's something we should look at in JSF 2.2.
Werner I already sent a request for that in the bug tracker.
Kito Yeah. That would make a big difference. Well, in terms of implementation, here you're dealing with sort of compiling classes and things like that dynamically. And figuring out the dependency graph, et cetera, et cetera. What was the most interesting part of that for you?
Werner I think the most interesting part was the byte code scanning. Because it was an area entirely new for me, I've never looked into the Java classes byte code. And the funny thing is I didn't even have to buy a book; I got all the documentation from the Net that I needed.
Kito Really?
Werner And I originally opted for the Apache BCL, but it was not as sophisticated as I needed because it didn't cover the Java 5.0 annotations back then. And so I went for ASM instead, for the byte code scanning. And that was the harder part because ASM is way closer to the original byte code, and with this listener interface and then the artifacts it scans for interpretation, than BCL is.
Kito Okay. Cool.
Werner And I think the roughest part was to get all the ... hooks from the implementation to get at a dynamic artifact reloading done right. I tried to be as implementation neutral as possible. For most artifacts it worked, but some artifacts were close to impossible to reload without touching the implementation. It was managed beans mostly, which caused the biggest trouble.
Kito I can see that. Yeah.
Werner You can use proxies for most other artifacts, you just can't generate the proxy for the original artifact. The proxy basically reloads the original. Once it gets the information, its core class has changed.
Kito So, what makes proxies difficult for managed beans?
Werner Java.
Kito Ah.
Werner Because usually, you have direct casts. You don't have interfaces, you have direct casts usually. And without byte code interference, you can't replace a running managed bean with new code.
Kito Right. Right. And this also goes back to the fact that managed beans, you know, aren't proxied at all to begin with, right?
Werner Yeah. Well, if you were to do some byte code engineering, you can replace it. JRebel of course, does it, otherwise you can pull their stuff up.
Kito Right.
Werner But in a dynamic language, this would be easy. I think my first implementation was to push invisible proxies on top of Groovy Java Beans. It worked as long as they stayed in Groovy, but as soon as they hit the Java side, the proxy was gone, of course.
Kito Interesting.
Werner It also would have been possible if I would've had some kind of dynamic ... invoked dynamic, like we have in Java 7.0, and if I would have replaced every method call on the byte code level with invoked dynamic. And then, I would have had to replace every data type, every typed data type with a plain object. That would be the approach in Java 7.0 to really make that transparent.
Kito Right.
Werner But that would be byte code engineering, of course, which I try to avoid.
Kito Understandably so. So, do you find -- what do you think will be primary use case for this?
Werner I think prototyping, mostly. And I think most users -- if they start to use it -- most users will start with probably with a dynamic reloading of the web artifacts. Because that one is a huge timesaver. And I think -- I don't think that too many people will use the Groovy part. Some will start to use it, but I don't think it's very entrenched into the current enterprise development.
Kito Yeah. That's what we were finding. I was talking to Ed Burns earlier. And also, I did a polyglot JSF session earlier, or yesterday. And we were like, is anyone actually using Groovy in the audience?
Werner And nobody raised their hands, probably.
Kito I think there was one person. But yeah. Very, very few people -- at least in the sort of enterprise Java JSF world -- seemed to be really using it much.
Werner I think it's a pity because you have many parts to code, which are not really performance critical. Because most of the performance is usually spent on the database layer.
Kito Yeah.
Werner And if you use some kind of scripting language, first of all, you get all the dynamic stuff in, which means you have less of a restart. And on the other hand, you'll finally get closures in, which also are a huge code saver. And the third part is to get rid of the setters and getters. And if you ever have looked at code without setters and getters, especially in the JSF world, you have about ... for instance, for a few controller beans, you have something like 50 percent less code because of the setters and getters being gone.
Kito Right. Yeah. I come from a Delphi background, and I still can't get over the getters and setters.
Werner Yeah. I think for one or two years, I programmed Delphi as well. It used to be very popular in the 90s.
Kito Yes. I think it came out in like '95 or something initially.
Werner Yeah. And before that it was Turbo Pascal.
Kito Yeah, me too.
Werner I think everybody did that in that time.
Kito I think you're right. It was the best thing ever back then. Alright. So, right now you just -- I think today you said you finally got the artifacts for 1.0 of MyFaces Extensions?
Werner Yes. It has been in beta long enough.
Kito Alright. So, I think that will be great, to get that out there and get people using it.
Werner Yeah. I hope people will start to use it.
Kito Yeah. Well, it certainly does save some time, which is good.
Werner Yeah, because I want to make a 1.0.1 release one week afterwards. The reason is, due to the fact that I have programmed deeply into the implementation -- we did some major SPI changes in MyFaces between 2.0 and 2.3 for the Geronimo integration. And of course, I couldn't test Extensions Scripting for the last three months, too, due to my personal situation. I've become a father a second time.
Kito Congratulations.
Werner Yeah. Thank you. And when I finally brought to result -- the break was through in December -- I noticed that after 2.0.3, the thing didn't run anymore. So, I did the fixing, but I really have to get the next release out as soon as possible, so that people really get their hands on the release, which works with the latest MyFaces implementation.
Kito So, probably by the time people hear this, there will be a link on the site and everything.
Werner I'm pretty sure about that. Just wanted to give you fair warning.
Kito So basically, the deal is like most of the MyFaces stuff, there is like the core, which is just the implementation, and then, you can download this or any other extension.
Werner Exactly. Yes. Most of the extensions are pretty version and platform agnostic by now. I think my extension is the only one that really requires MyFaces. I'm not sure -- CODI doesn't require it, I think.
Kito I don't think so.
Werner And ExtVal also. I think that runs also standalone. And outside of that, we don't have too many extensions.
Kito Right. Although, I swear every time I go to that site, I find a new project, or something. There's MyFaces Test, but it's not really an extension...
Werner No, it's not really an extension. We will integrate it one way or the other later in the build system, to get the tests better covered. I haven't looked deeply into the project, I don't know what it is about -- I think it's about programmatic tests or something like that.
Kito Yeah. It's basically stub or mock objects or mostly JSF artifacts.
Werner Yeah. We have something like that already, which stems from Shale, but I think it's getting old by now.
Kito It's the same thing. MyFaces Test is just the new version of the Shale stuff.
Werner Oh, okay.
Kito So, yeah. Alright. Anything else you want to add? Are you having a good time at the conference?
Werner Well, I couldn't -- unfortunately, I couldn't attend too many sessions because I was working on the release. But the sessions I attended were pretty good.
Kito Good.
Werner And I really liked the conference. I don't have too much time to attend to many conferences, so this is pretty much my only conference.
Kito Ah, okay. Yeah. I love coming out here, so -- glad to come out to Vienna again. Cannot complain.
Werner I think it's a good meeting point for the JSF people.
Kito Oh yeah, definitely.
Werner And also, I like it that the scope is enterprise -- well, there was an enterprise sessions last year, but the scope was pretty much still JSF and this year, it's -- there is JSF, but it's only part of it and so, the scope has become broader. I think this is more interesting for the visitors now.
Kito Yeah. We'll just get more -- basically, more exposure to all the technology that they're using. And also, I think there were -- there were two sessions on Tapestry yesterday.
Werner I think so, yeah.
Kito But there was a Wicket session, too. So, I thought that was pretty good to broaden the focus a bit. Alright. Well, thanks for joining me, Werner. And good luck with your new kid.
Werner Thank you.
AnnouncerThat'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.