JSF Central - Martin Marinschek on MyFaces 2.0, IRIAN, and Related Topics
JSF Central

 Articles & Books 
Community Chat
Martin Marinschek on MyFaces 2.0, IRIAN, and Related Topics
by Kito Mann
03 Mar 2010 02:15 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Martin Marinschek about MyFaces, IRIAN, and related topics. This interview was recorded in December of 2009 at the JSF Summit conference in Orlando, Florida.

Podcast (MP3)
Welcome to the JSFCentral podcast #20 for the week of February 22, 2010. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hello this is Kito Mann and I am here at the JSF Summit 2009 in Orlando, Florida, where normally it is very sunny but today it is raining. Today I am here with Martin Marinschek. Martin is one of the co-founders of IRIAN, which is the main company backing the MyFaces project. So we are going to talk today about MyFaces, IRIAN, and related topics. Martin why don’t we just start with a little bit about yourself, your background, and your company?
Martin I wrote the first productive application in JSF 0.3 of the specification, and of course in the MyFaces implementation. It was in 2003. It was fun. I have done a lot of JSF development, consulting, and training since then. I founded the company IRIAN together with two other people. A lot has changed in the JSF world since then, to the good I think. As of now, I am really satisfied with the developments that have happened in the last years in JSF, and I am really happy that JSF is as good as it is right now.
Kito Why don’t we talk a little bit about the types of projects you work on?
Martin Currently I am mostly involved on one side with running the company, which definitely would be a job of its own. I am also full time at a project at Credit Suisse, which is our biggest customer. They are revamping the whole credit application suite. Basically it is the third largest Credit Suisse application that is out there on the web. They are revamping it from a small web application, and doing it all based on JSF. They developed their own component suite for this and other projects that are using JSF. They have made it clear that JSF is the standard they use for new projects that are doing web development. That is actually a pretty nice environment to be in as a JSF consulting company.
Kito Yes it is.
Martin A lot of my guys are sitting at Credit Suisse right at the moment, having fun there.
Kito Can you say anything about the technologies, like what they use there?
Martin Apart from the UI, they are not very state-of-the-art based in many cases. They have some projects which use JPA, and they are actually evaluating it in many places and are thinking about using JPA. I think they did a lot of performance testing and decided to go with…what was it? It wasn’t Oracle…
Kito Was it OpenJPA?
Martin No it wasn’t OpenJPA either. Does WebLogic have a JPA offering?
Kito I don’t know.
Martin I think it was a WebLogic product that they want to use. They decided the performance was the best. Apart from that, they are using a strange architecture with a lot of CORBA services.
Martin Yeah yeah yeah…
Kito I remember CORBA.
Martin Yeah, I don’t want to remember CORBA. To be honest, if you do CORBA well it can be quite nice, but it’s not very well done in the CS environment. The JSF part is very well done. It is a nice component suite. I wish it was open source so that others could use it as well. There are some pretty nice features, for example with tables, it has really very sophisticated fields for sorting -- whatever you are thinking about you can do it with these tables. Plus it also has a JavaScript-free fallback. That would be an interesting feature for a lot of people.
Kito Yeah definitely.
Martin Especially for government agencies who want to be fully accessible. You can be accessible with JavaScript as well, but if you need to be WCAG 1.0 fully covered then you would have to have a JavaScript-free fallback as well.
Kito And WCAG is?
Martin It is one of the standards for web accessibility.
Kito Ok.
Martin Given out by WAI -- Web Accessibility Initiative.
Kito Right, ok.
Martin It’s not the current one. There is a WCAG 2.0 which doesn’t enforce JavaScript-less fallback. But the 1.0 version does, but usually on a per-organization based, not like a government law -- it wouldn’t enforce that.
Kito Ok, cool. Why don’t you talk a little bit about MyFaces? Your company provides some training and support for MyFaces and also you have several committers as well, right? Doesn’t the founder of the whole project work with you guys?
Martin The founders of the project were Manfred [Geiler] and Thomas [Speigel]. Both working for…..
Kito That’s right Thomas was a founder too.
Martin Manfred and Thomas, they both are working for us. Not currently so much on the implementation anymore; we have other people doing that. They want to do the project based stuff more so they really don’t work on the fundamentals and stuff. They like to do a project where they have contact with the business, and then sort something out and then come up with something which is useful for the client. They want to keep it like that, to bridge the business technology gap somehow. We have other people working on the infrastructure part. From the 62 committers in MyFaces, there are 20 from Irian and close to 20 from Oracle. Then the rest are from a lot of companies from all over the world.
Kito Let’s talk a little bit about the project. MyFaces was originally just an implementation but now it has grown into a very large set of projects. Tell us a bit about some of the different projects that are part of the MyFaces umbrella.
Martin I hope I don’t miss anything. Of course there is the core MyFaces implementation and API. For the JSF implementation you have to do the API and the Impl, so it is actually two jars which are developed in the core section. Then there are the three component libraries: Trinidad, Tomahawk, and Tobago. Then there is Orchestra, which is a conversation scope implementation for long running conversations with integration to JPA as well. Then there is the JSF Portlet Bridge, and there is ExtVal validation integration for JSF, where you can put annotations on your managed beans and domain objects. It will directly be converted into JSF converters and validators, pretty nicely done. Now that bean validation has been standardized, it is also an implementation of bean validation, so you can use the bean validation annotations together with ExtVal.
Kito Is that currently shipping? Are they finished with that yet?
Martin I do think there is a version which already has support for the annotations. I am not sure if the full TCK compliance is out there, but you can use the bean validation annotations as of the release that is out there currently. I have a sample app written for the book, and we used one of the releases of ExtVal for doing that, and we are already using the bean validation annotations.
Kito Nice. I should say that there is currently a series on ExtVal on JSFCentral so if you are interested in more about that you can take a look at the article series.
Martin Then there is Ext-Scripting, which tries to provide Groovy support for having artifacts written in Groovy for MyFaces. I thought it was out already, actually, but it isn’t. It is going to be released in February. Then Ext-Scripting also – if you use Java 7, it supports you if you reload everything you have written in Java as well, so you can use managed beans, converters, validators, whatever. You can write that completely in Java and have that reload even while you work on it. Even if you put annotations somewhere, it is going to reload the whole thing.
Kito Nice.
Martin That is going to be a nice feature. Ext-Scripting is independent of the implementation so you might be able to use it with Mojarra as well. Let’s see how it works out in February. Did I cover everything now?
Kito Isn’t there a kind of commons project?
Martin Yea there is, but actually I don’t think there is a lot in there as of now.
Kito Ok.
Martin There is a shared project, which is stuff that is shared across the component libraries. That is not actually for usage by end users, more to share stuff between the libraries themselves. There is a common project which is supposed to be, in the end, a place where you can put stuff which is really the same all over the JSF world. Where a common API can reside and everybody can use that in their projects on top of the specification. Something which is long lived but more dynamic than adding something to the core specification. Let’s see how that works out in the end.
Kito Is that where -- if you were to address an issue like a limitation in the specification, is that something you would try and put there?
Martin You could possibly put stuff there, yes.
Kito Ok.
Martin If it is something that is useful for all the implementations.
Kito Right.
Martin It is possible to detach it from the implementation in the API.
Kito Ok. So just for people who aren’t really familiar with the different MyFaces projects, can you explain what’s different about the different component suites? Like why do you have three different component suites?
Martin They were coming from different sources. We had long discussions on should we have only one component library, or should we allow other people to also donate their component libraries and make them available as open source under the umbrella of MyFaces. We decided to be more open and to include other component libraries as well. In hindsight, a choice is always a good and a bad thing.
Kito So what’s different about them?
Martin They would have been open source anyway.
Kito This is true.
Martin They just would have been somewhere else, then.
Kito They are pretty different, right?
Martin They are definitely pretty different. They all have a distinct mindset behind them. If you look at Trinidad, it’s the mindset of Oracle, where they have a lot of features, very data entry based features, where you can do a lot of cool stuff with Trinidad if you are working with data entry. Especially client side validation is very well done, the messaging part. Also they were one of the first ones to support Ajax in the component suite. Actually I think they were the first ones.
Kito I think they were.
Martin ICEfaces is kind of detached from component suite, right?
Kito Right.
Martin For maybe the component library, they were the first ones to support this
Kito What about Tobago?
Martin Tobago was donated by a small company, which is now Irian Germany. So Tobago is also a very cool component library. It’s a very homogenous experience. A nice component library with a lot of features. Everything that is necessary is there. Really the only thing that is missing for Tobago is marketing.
Kito Right.
Martin It still doesn’t have that big of a user base and it really should have, because it was really one of the first component libraries which had a full feature set and a very homogenous experience.
Kito Isn’t one of its core principles that you can… like layout and that kind of stuff?
Martin Layout is very nicely handled in Tobago so you can have the dynamic layout managers. You can even exchange the layout managers that they have. They are a little bit Swing based, right? They are doing an absolute positioning flavor as well in the latest version.
Kito Really? Interesting. I imagine that might work better now than it would have a few years ago.
Martin Definitely. They say it was only possible with the latest enhancements to support that the browsers are getting right now. Tomahawk – I always call it bizarre – because you have hundreds of components and they all kind of work together or not. They are all useful in a sense. In many cases for the project you find out you need one or two components.
Kito Exactly.
Martin The nice thing is that Tomahawk is so close to the standard that you can add it to the project and it won’t blow up the rest. It was interoperable with all the component libraries right from the beginning, which was good.
Kito I always recommend, basically any team no matter what component suite, I always say you are going to need at least one or two Tomahawk components. I think maybe with JSF 2, some of the ones that provide some of the core features won’t be necessary, like that style sheet component.
Martin Yeah.
Kito In JSF 2 you don’t really need it, but there are a lot of little goodies in there.
Martin Yeah, a lot of little stuff. Things that other component libraries just don’t have. As I say, it’s a big community and everybody who had missed something and added it, just added their missing feature to the component library. It’s kind of nice. The JSF 2.0 version of Tomahawk is not going to take that long because it is so close to the standard, so there is not that much to do. The only thing that will take some time is the resource handling. The rest is really basic stuff and not a big problem. We expect a JSF 2.0 release of Tomahawk soon. We will do it right after we have finished the 2.0 core implementation.
Kito Nice.
Martin I expect it to be done in the next half of the year.
Kito Do you think that you will deprecate any of the components that duplicate JSF 2 functionality?
Martin If there is no added functionality we are certainly going to deprecate it. For the 2.0 version we can do that. There is certainly not going to be a , for example.
Kito Right.
Martin If you use flash scope replacement that we had in Tomahawk, it is not going to be necessary in JSF 2.0 anymore.
Kito Speaking of JSF 2.0, this week I noticed that you released MyFaces 2.0 Alpha. Tell us a little bit about that whole process. I saw a lot of activity on the mailing list and everything.
Martin It has been a lot of work to get MyFaces 2.0 out the door. We have a few committers who are working on the fulltime, for example Leonardo and a guy from IBM as well. It was nice to implement all of this hard work. We are now close to done. We have actually tried it with a lot of sample apps. We have run the TCK and it runs through except for certain tests which we need to discuss with the Sun guys, so it’s really nothing anymore which would be on our side. There are two minor issues that can be done with Ajax support exception handling, especially in the Ajax case. Then 2.0 will be done right. You probably want to use it and then see what else we have to do. That is certainly going to be quite a few bugs….
Kito It still sounds pretty good for an off release status. It’s pretty much passing the TCK and getting most of it.
Martin What we did as a company as well is we published a German JSF 2.0 book in November and we partially wrote it in Mojarra for parts which weren’t done in MyFaces yet. We made sure that all the samples are running on MyFaces as well.
Kito Nice. What's the name of the book?
Martin JSF 2.0
Kito Simple name.
Martin Simple names are good. It is for the German speaking listeners. If you are interested there is a JSF tutorial, which is essentially this book, completely online, freely available, if you need to look stuff up on JSF 2.0. You can find it on tutorials.irian.at/jsf. That would be the online JSF book, you can read it if you are studying a project and want to do JSF 2.0. I hope that in the next week there is definitely going to be a good release of MyFaces 2.0 that passes the TCK, that’s ready for prime time.
Kito That’s actually really cool because I know with JSF 1.2, it took about a year or so for MyFaces.
Martin We were way late. We didn’t have any people who really worked on the implementation who were spending only time working on the implementation. That has changed now. We have people working on the implementation, at least part time, as well as the component libraries… dependant also on our revenue stream.
Kito Yes exactly. I remember at the time people were saying that since there was stuff that dealt with some of the JSF 1.2 features in MyFaces Tomahawk, they were like, well….
Martin And you could use Facelets.
Kito Right.
Martin And then 1.2 didn’t add so much benefit, so the community really didn’t have to scratch the itch. For 2.0 it’s really a very different thing. There is a lot of cool functionality in 2.0 that we will all want to use in our everyday projects. It’s just so much of a difference if you really need these features. That’s also the reason why we see a bunch of activity going on for the MyFaces 2.0 release. Also IBM recently joined the team.
Kito That brings up and interesting point. I have some of IBM’s customers that are using their WebSphere application server, and I met a few at the conference too. IBM has a reputation for being very slow with the new standards. Do you have any idea about when they might start trying to include support for MyFaces?
Martin They are completely secretive about this.
Kito At least it’s good to tell people – I know they are definitely committed.
Martin Obviously, they put their stakes in MyFaces right now.
Kito Right, so that’s good. Let’s look at a couple months out – now it is December – when MyFaces 2 is beta or completely stable. I am not tying you to any particular dates but just whenever that happens. Why would someone want to pick MyFaces versus Mojarra?

For now there is not so much in implementation that would be different. As always, we try to give the developer a better development-time experience than Mojarra did, right from the beginning. We can definitely say in the first version, 1.0, MyFaces was the only implementation you could really use for big projects. Quite a few flaws in Mojarra, which made that impossible. Synchronized statements where they shouldn’t have been and stuff like that. It’s not like that anymore, so you can definitely use Mojarra for your everyday project. What MyFaces always did was… like make sure that messaging was alright. You would get the right exception messages if you did something wrong. Really small stuff. A feedback page like the one that you have in Facelets -- we had that early on in MyFaces as well, so that you could see… even for stuff that wasn’t happening during rendering, you would see proper error messages. Reloading off configuration so you didn’t have to restart the server if you changed something in your configuration – MyFaces offered that from early on. Mojarra has picked it up as well.

We will try to innovate further in this regard. For example the Ext-Scripting support will be something like that, which will also enhance your development-time experience. When that February Ext-Scripting is out, we will try to have a version of MyFaces together with Ext-Scripting support where you really don’t have to restart your server at all anymore. That would really be cool. I think that will be a feature edit which will help a lot of people, even without using Groovy. You can do that with Groovy but not a lot of the big shops are going to jump on the Groovy train just for this development-time experience. It makes a huge difference for the developer, I think. Also for error handling, debugging, I don’t know, we will try to innovate in this area more. We cannot really do much with the API specification, right in the implementation. This is one of the areas that we can concentrate on.

The second area we can concentrate on is performance. Currently in the 1.2 versions, Mojarra and MyFaces don’t deviate much, and it’s really the same thing if you look at the benchmark results. For 2.0 we might try to enhance partial state saving a little bit more in the MyFaces implementation. We see a saving of 80% of the state as of now with Mojarra in the benchmarks. We will certainly try to reduce that number for MyFaces even more. That would be a cool thing to do.

Kito Nice. Is that something that Oracle might be interested in with Trinidad?
Martin Definitely.
Kito I know they have always been really into state saving.
Martin For example Credit Suisse, our largest customer, they also have that problem to a large extent.
Kito Makes sense. One of the questions that people might have is which pieces are in Tomahawk and which pieces are part of the MyFaces core? For instance, I know there is a security manager.
Martin We tried to move everything which is not in the specification out of the MyFaces core. So MyFaces core is really supposed to be plain JSF implementation, which will implement the specification, nothing else. Whatever is additional features should really be in MyFaces common or one of the component libraries, or in Orchestra, or in the JSF portlet bridge, so that it also works with both implementations. You can certainly use both implementations working together with this project.
Kito It is probably worthwhile to point out that the JSF Portlet Bridge part of the MyFaces overall project is a reference implementation for JSR 301.
Martin There are a lot of other standards coming up in this regard. Mike has to do a new standard for all of the versioning issues, right?
Kito Yeah, it’s a lot of accommodations. I kind of wish we could clone Mike. Mike, by the way, is the spec lead for the JSR 301 Portlet Bridge stuff. He is an Oracle employee but I kind of wish there were like two or three of him…
Martin Definitely to work on the different versions.
Kito Such is life. I think those are all of the key questions that I had for you Martin, do you have any other things you want to add? Are you having a good time at the conference?
Martin Definitely yes. I brought my sister, had some fun with her as well. We went shopping and to theme parks, it was a nice experience. Thanks for inviting me Kito.
Kito I am very glad to have you, and that does bring up another topic, which is another JSF conference coming up in February.
Martin Thanks Kito. We have JSFDays in Europe, so if you are listening and are from Europe, please come to JSFDays 2010. JSFDays 2010 will be from the 22nd to the 24th of February in Vienna. If you are interested in the JSF ecosystem and want to hear the important speakers in the JSF world, come to us, you certainly won’t be disappointed.
Kito That was a pretty good plug there. There is also some Java EE and Spring stuff there too, right?
Martin Sure, it’s not only JSF. It is one track JSF plus Web. Then there is one track Java EE, Spring, whatever you need on top of JSF 2 to make your project work.
Kito What are your thoughts on CDI by the way? Context and Dependency Injection for Java? The new name for the Web Beans spec.
Martin Yeah, it’s definitely a cool thing to have the conversation scope finally standardized, and that’s what we see in 299. We are talking about JSR 299 with CDI and then we have JSR 330 which is basically the base for JSR 299. So those two together are a very important step forward for the Java ecosystems. I definitely think the whole dependency injection stuff has shown its merits in the last years.
Kito Definitely.
Martin It should definitely be in all the standard based projects out there as well. Thankfully this has happened now. So there are going to be topics on this, of course as well. For the reference implementation, but also on the Spring side, Jurgen Holler is going to be there. It’s all going to be covered at JSFDays.
Kito So if you couldn’t make it to the JSF Summit, which most people from Europe didn’t, then you should definitely check out JSFDays. You can get some of the same content with different people, and some of the same people. It should be good. Thanks again, Martin.
Martin Thank you, 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.