JSF Central - Dan Allen on Seam and Spring
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Dan Allen on Seam and Spring
by Kito Mann
20 Aug 2008 00:30 CDT

This podcast is an interview between JSFCentral editor-in-chief Kito D. Mann and Dan Allen, an independent software consultant, author, and open source advocate. It was recorded in May of 2008 at JavaOne in San Francisco, CA.


Podcast (MP3)
Welcome to the JSFCentral podcast #6 for the week of August 18, 2008. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
We're proud to announce that JSFOne just got bigger! JSFOne is the one event exclusively focused on the JSF Ecosystem, taking place September 4th-6th in Vienna, VA. It's a conference for application developers, solution architects, and project managers who develop applications with JavaServer Faces, Seam, and related technologies. Our speakers are deeply involved in every aspect of the JavaServer Faces ecosystem - from developing core technologies to building real-world applications. And now, we just added an entire new track full of quality nuggets of knowledge including portlets, security, Google API integration, and more. That makes four tracks total: Intro, Seam and Spring, Ajax and Component development, plus Security and Integration. JSFOne is hosted by JSFCentral and the No Fluff Just Stuff Symposiums for more info, visit JSFOne
KitoI am here at JavaOne 2008 with Dan Allen. I thought I would talk to Dan a little bit about Seam, JPA, JSF and whatever else is on his mind. How do you like the show Dan?
Dan It is great, the excitement here is just tremendous. I came out here for this particular show at the last minute because I knew there would be a potential to meet a bunch of folks I only know via email, and have really good conversations that you never really get to via email. That's been a huge success and I am really glad that I made the trip.
Kito Yeah I have always felt that way, with the whole networking thing you meet so many great people. So as far as you are concerned...you're known for the book Seam in Action, right?
Dan Yes.
Kito So tell us a little bit about yourself, what you are focusing on these days, if there is anything other than Seam...and the book. Also tell us a little bit about the book itself, because there are other Seam books. Tell us what's cool about yours.
Dan The Seam book brought me into Seam -- I have been focusing on both the book and Seam pretty heavily because writing a book is tough, I have learned. It is really rewarding at the same time. For about two years I worked on Seam and Hibernate in depth, but it wasn't until I wrote a book that I took it to a whole new level of depth. I really started to understand fundamentally how Java EE worked and all the modules that I never really got to. That is one of the reasons I chose to work with Seam. I actually came from a scripting background. I started in PHP and actually wrote a port of Jakarta Struts to PHP.
Kito Really?
Dan Which is sort of a strange thing to start with, because a lot of people come into Java and they don't try to write something in Java before they have ever used Java, but that is sort of how I came into Java. I studied the Tomcat source code, wrote my own servlet implementation in PHP. I had limitations because PHP has limitations, so I couldn't do certain things. I think that it was a worthwhile experience and it taught me how a lot of the servlet stuff works form the internals. That is why I think now I can look at things like Seam and some of the other technologies, and I already have that familiarity with the API so I really understand how it works. Now I am really glad that I am in Java, and it is funny how I get comments from people who want me to do PHP stuff. I have sort of moved on from that, because there is just so much more that you can do with these technologies, to build upon that. What happens with the PHP developers is they are just trying to figure out how to emulate all of this stuff. At one point you wake up in the morning and you say "okay if all this technology is written already, why am I trying to re-write it? I want to build on top of it. I want to extend it. I want to make it go to the next level." That is really the mentality you start to take with these frameworks, especially in Seam and Spring. Let's see what we can do that is new and interesting, not try to do what we have already done.
Kito That makes sense. PHP servlets... you know it is funny, everybody seems to be supporting PHP; now and you can run PHP on Glassfish, and I saw today that you can run PHP inside of Liferay Portal -- you can run a PHP portlet and everything -- but I don’t think they have gotten to that level of interoperability that you can get with the languages that actually run on the VM. It is kind of an interesting space. Seam in Action is your book, and of course you cover Seam. Is it like an intro to Seam? Is it a tutorial? What kind of book is it?
Dan I started out, and one of the things I wanted to do was get people to really understand how Seam worked. Not so much how to use Seam but actually how it worked. I have gotten criticized a little bit about that from some of the reviewers saying "this is really, really, detailed and it would be really good for people working in Seam, but maybe a little too advanced in some sections for people who are just trying to use Seam." But those people that brought up those topics were few and far between. Most people said "thank you," really a lot of the feedback so far has just been "thank you. Because nothing has gone into the detail and we have spent a lot of time with these problems and you have addressed these specific problems that we didn't understand." It is interesting because anytime you deal with an advanced technology you are going to have a degree of confusion because we are dealing with very advanced technologies. It is not necessarily a negative of the technology; it is that you are trying to do something that is very advanced. The same could go for Aspect J, for instance. The power is tremendous but you could really shoot yourself in the foot if you don't really have the right documentation. Seam in Action is that. It gives you the understanding you need to really take your Seam apps to the next level. I've found that as I have moved along, I go back to Seam in Action because I forget how some stuff works.
Kito I do the same thing with JSF in Action. It is kind of funny that way.
Dan It is very in-depth, I really had to take a step back and make the first three chapters a lot simpler so that people could get into it and I think I accomplished that. You really can start from scratch. There are a couple of people that have only been in Java for six months that said they have been successful with Seam in Action. It is possible, but I think at the same time that you do have to be committed when you read the book to learning it.
Kito That makes sense. I think that goes for any good book, you can't just stare at it. I try at home - I have lots of books and I put them against my head - it doesn't really quite work, so I don't know. Just for those who are not totally familiar, can you just take a step back and give a brief one or two sentence overview of what Seam is?
Dan Yes I will be brief. Basically the idea is... so there are a lot of APIs in Java EE and there are a lot of developers that really don't understand how to get into them. They see that maybe it's a neat thing. "EJB 3, that's sort of interesting, but how do I get into EJB 3?" Seam really provides a build tool to get you going with a project right out of the gate, then you can start using EJB's.
Kito And that's Seam-gen right?
Dan That's Seam-gen. So really the idea is Seam provides some annotations, that if you use them straight from JSF or any EL value expressions, you can start accessing EJBs. So people realize that "I'm using an EJB right now, this is incredible. I have never had the opportunity to get here before because JNDI look-ups and getting stuff configured can be daunting." So Seam really closes all those gaps. At the same time it says "why don't you use EJB 3s from your JSF? Why do you have these backing beans that are really worthless? They just pass stuff back to the other layers." That's not to say you can't do it with Seam. You have the option of having a very layered app, or you have the option of having very collapsed layers in your app. The other thing that Seam provides is it has a POJO model where you can use java beans to do just about everything you can do with EJB 3s. The reason that I like that...some people say "why don't you just use the Java EE standard? Why do you try to duplicate everything?" It's a migration path in my mind. People are afraid of them, so they use POJOs and they get all the services that you get with Java EE, and not services that are done completely differently. These are services that almost work exactly the same. Then you say to people "you are about this close to EJB 3 so all you have to do is change the annotations from whatever name in Seam to Stateful plus name or stateless plus name." Then you are using EJB 3.
Kito You do have to still write an interface, there is a little bit of extra work.
Dan In EJB 3.1 that will go away. What I like to say is "Seam makes Java EE accessible." Accessible to those that don't understand it, as well as accessible to the advanced developers who really know it and it is boilerplate code for them. It takes care of that boilerplate code.
Kito Okay, cool. One of the things that you have been blogging and writing about, I am sure in addition to writing for your book - or in conjunction I should say - is Seam and Spring together. In a lot of ways they seem to overlap. Spring is a container and a lot of other stuff. Seam is a container and a lot of other stuff. Can you explain in what scenarios you think it makes sense to use the two together and what benefits you get by using Spring and not just using all Seam?
Dan Absolutely. Earlier I slipped and said Spring instead of Seam and that's because I have been thinking about both. I have spent probably equal amount of time in both technologies. I like to think of myself as the diplomat. It goes back to what I said earlier: we have these technologies, and we really as Java developers want to leverage the technologies we have out there. We don't necessarily want to say "I am going to avoid Spring for avoidance's sake. I am going to see if there is something useful in Spring and if there is I am going to use it. If Seam has something useful I am going to use it. "That's where this comes about. Seam does something very well: it manages the entity manager in JPA, or the Hibernate session, so that you can extend it, and of course EJB 3 offers this. But not only can you extend it, you have a place to stick it when it is extended. So in EJB 3 you would have to stick it in -- let's say the session --if you want to extend it. That brings the question "why would you extend it?" The quote that you hear all the time is "Seam avoids the lazy initialization exception problem," which is interesting because that is not really the problem. The problem is that the entity manager is a stateful component. It was designed to retrieve and manage objects until you are finished using the objects. In web applications that could be over a series of multiple pages, but in the Spring contract, the entity manager is typically bound to the transaction. When the transaction closes on your service object, so does the entity manager. What happens is all of those objects that were managed by the entity manager are all of a sudden detached, so the only way to get the changes back into the database via JPA is you have to either merge them in on the next request, which requires a lookup and then an overwrite of what is in the database. Or you have to manually copy the properties back on to a managed object yourself, selecting the properties that you are interested in. That sort of takes away the whole beauty of JPA, which is dirty checking of properties that have changed, which works nicely with JSF, because JSF has bindings to the form fields, so you just submit the form and if there are no changes to the form the database doesn't get touched. That is a beautiful thing. The other thing it enables you to do is stick a collection of entities in an editable grid, press save and in the business logic... there is no business logic. The business logic is "open the transaction," "close the transaction," and it commits to the database. That's really the idea behind the extended entity manager. Spring doesn't really have that. You have it in Spring Webflow to some degree. Even that, you could argue, is finally that we are realizing that there is something here that is useful.
Kito Yeah, I think the stuff is in the new version - the 2.0 - from what I have heard.
Dan Right, so the nice part about Seam's conversations is that one, if you are already using them, you can use them. The other thing is that Seam conversations are not necessary page flow. Seam's conversations are loose, declarative end points where you say "I'd like it to start and I'd like it to end," and the user can do any number of things in between, so there is some flexibility. Why Spring and Seam and how does it work? The idea is Spring has the ability to... when it parses the XML file you can have delegates and those delegates can be other containers as long as they are listening to the parse events. So the idea is Seam taps into that and wraps the names of the beans so that they get called back into the Seam container. That's how you can say "okay from Seam I am going to use a Spring bean." Then conversely on the other hand, you can take a Seam component and inject it back into a Spring bean. Though this somewhat complex - but once you have it set up, it is quite elegant - interchange between the two containers, you can get the entity manager managed in Seam and contributed to Spring. Spring is none the wiser -- it thinks that it is operating on the same entity manager factory that it has always operated on to get new instances, and all of your Spring beans work exactly like they did. It is just some configuration and all of a sudden your Spring beans stop closing the entity manager, and that's the key. Get your Spring beans to stop messing with the entity manager. Once you have that, then your services in Spring can be used the way they always were.
Kito If that's the case though -- if Spring has these issues with the entity manager, etc. -- why wouldn't you just move everything to the Seam container to begin with?
Dan That's a good question and I think it comes down to a simple answer. These companies invest money in technology - in the business logic - and they have no money to re-write it, but they do have money to write new things that use it. It makes no sense for them to re-write code. This is why we can't get rid of some code that is out there that maybe uses Struts, because there is no business need to actually re-write it for re-write's sake. What this allows you to do is take advantage of the vast number of services you may already have in Spring that do a lot of great business logic, but the way that they are consumed in their JSF pages, in your client, you want to do new. You might have new pages that you want to create and those services are going to be very useful to you. So you have the advantage to tap into existing business logic and existing services.
Kito I think that makes sense, but don't you think there are also things you can do with the full Spring container that maybe Seam doesn't do so well?
Dan Absolutely, Spring does things that - personally I don't think Seam will ever implement. It's a philosophy thing. Seam doesn't really believe in AspectJ. We don't necessarily believe that we need to implement it. That's not to say it's not useful, it just doesn't make sense for us to implement that now. Maybe we will change our mind sometime in the future but for now that's Spring's position and Seam has its position. Why should the developer not be able to take advantage of both? Why should the developer be caught in the middle? The developer doesn't have to get caught in the middle because it is possible to have a much broader technology choice by taking Seam and Spring, putting them together and saying "no matter what the two technologies decide they want to get involved with, I can take advantage of both sides." The reason that Seam doesn't get into AspectJ is because Seam is about trying to make the business components as simple and easy to understand as possible. Annotations... while some people might not think that annotations are elegant, they are very clear. When you put an annotation on a method, and you are a Java developer and you are looking at the method, it is very clear what is going on. In AspectJ because some of the configuration happens externally and is quite complex, you need an advanced or highly talented developer sometimes to understand how that actually gets applied. It is a difference in philosophy; if you are a shop that likes the elegance of Seam in the UI, but you want to use AspectJ for your advanced business components that you have separate developers working on, you can actually integrate the two, and that's a nice thing.
Kito I think another thing is all the different utility things that Spring provides. For instance, I have one client that uses stored procedures. Hibernate is not the best thing for stored procedures. Spring does have some stored procedure stuff -- it is okay but it does integrate with iBatus, which is better with stored procedures. For them, for me to say "well why don't you go ahead and use Hibernate?" Well they would say "it doesn't work." But they get more support from the Spring area for that type of development. I think there are some areas... Because Spring is coming more from the integration side of things where Seam is coming more from the application stack side of things, it seems like there are some things you can leverage in the Spring world that you probably won't see in the Seam world, like aspects or some other things.
Dan That's a great point. That expanded this discussion a little bit to things I wasn't thinking about right now. You are absolutely right. There are things that Spring has - it could be anything, as simple as a configuration Spring offers to expose a constant as a bean, which is a nice thing and Seam hasn't gotten to that yet. Maybe we will, but we haven't gotten to it yet, so if you want to use it today you can tap into Spring and take advantage of it - which is nice. You have Jasper report generation, and you have a couple other things that - again - Seam hasnt worked on, maybe we haven't gotten to, maybe we won't get to. You get a chance to use those. Seam is very focused on improving Java EE, it's very focused on the technologies that are in the stack, so if you want to use something like iBatus, or a simple JDBC template... Perhaps it's not that you're moving your whole application stack over, maybe you are running some reports in a section of your application and you have determined that for you the report would best be queried using straight JDBC. So hey, you can go over to Spring and do that one thing, and get the services from Spring to run that report. Again, the integration there is nice because you can expose the bean through the EL and then you can access it from JSF, or you can access it from a business process or any of the number of other things where in Seam you are allowed to use EL.
Kito Right.
Dan The other thing is Seam has some things that are really interesting that Spring doesn't have, like the ability to generate PDF documents from XHTML, basically from Facelets templates. About to be committed in the next couple of months, we will have the same thing for Excel documents, because if a manager walks up to you or the product manager - whatever it might be - and says "you know it would be really great if I could generate this Excel document," you can create advanced Excel documents using the POI, or other equivalent technologies using their API, and Spring would be able to give you some templates to help you get started. Nothing can beat just cracking up an HTML page, because essentially that's what Facelets are - they are nothing more than XHTML with some custom tags. In probably about ten minutes you could have a prototype of an Excel document that would generate some report very quickly.
Kito Nice.
Dan Those are things where -- when you go back and talk about what Seam is -- is that Seam does help improve Java EE and look towards the future. The other thing it does is tries to solve problems at a very specific level. It looks at this very specific level. It looks at this very specific need, not just a general solution but saying - you know a manager might walk up to you and need something in fifteen minutes, how do we solve that problem? Hey let's give them a solution for that. It's highly specialized, but it's highly useful.
Kito I think - Gavin made the point that the goal was really to make it like the most productive platform for Java EE development. Kind of like you get with some of the .NET products. To that end I think it's definitely is doing a very nice job.
Dan Then there are some things that aren't in Java EE, so how do you deal with that, right? We need something today. The JavaScript Remoting is a very interesting thing, because there are times where you are using JSF and there are times when in your page you need to do something that is just outside the lifecycle. It's a one-off thing, but in the world of web applications there are a lot of one-off needs, and there is nothing wrong with that per se. What you can do is interact with the server-side model through an alternative approach, rather than going through the JSF componentry. That's not to say you are totally dumping JSF, but your hands aren't tied. I need to talk to a Seam component directly for it to do something, perhaps it needs to update something. I want to write something on a page and all I need to do is just flip a bit. You can use the Seam remoting to just flip that bit and that's a nice thing. It is very lightweight. You don't have to get into the Ajax, you can kind of think of it as an Ajax library. It doesn't try to be Scriptaculous, it is trying to interact with the Seam components, and it is very focused.
Kito One of the things I have been wondering is, when you try and integrate Spring and Seam, what is the performance like? There is a lot of code in Spring, there is a lot code in Seam, and it all has to kind of work together. They are different containers. What is the performance like when you try to do that integration?
Dan The performance degradation is potentially sourced from two areas. One is that Seam heavily relies on the EL, so the performance of the EL directly affects the performance of Seam's look up of components. The EL is sort of a mini scripting language inside of Seam and it is dynamic, so it is going to have the same problems as any dynamic language. The other thing is interceptors. Any time you have to call a method you get Seam’s interceptors, and then potentially Spring's interceptors, or if you are integrating with EJB you get EJB's interceptors. One of the things you can do there is disable Seam's interceptors. What you are using Seam for, in that sense, is the contextual management, the contextual component model, but you are not using it per se for the interceptors which might apply things like bijection because you already have all that done for you in Spring through dependency injection or transactions. You don't necessarily have to use Seam's interceptors to use Seam to manage the scoping of something.
Kito Alright cool. We have time for one more question. JSF2 is coming up and I know you have been working with JSF in the context of Seam. If you could pick the top three things you would like to see in JSF2, what would they be?
Dan The one thing that I keep bringing up that always bothers me is the fact that for the longest time we haven't really committed to XML for the view. We have always had a pseudo XML, in that TLDs were their own DDT - if you will. Then we have Facelets and they use a Taglib.XML file which has even less use than TLDs. The problem is that you have to wait for some sort of interpretation. What I would like to see is for us take advantage of XML Schema, because I feel like all the configuration files are going that way and it has been tremendously successful. Any XML editor that understands XML Schema can provide tag completion, and the fastest thing that you need as a developer... WYSIWYG development is always one of those things that looks great on the tradeshow floor, but I have never been able to get really productive with it because we are developers that look much lower level, and what we need is tag completion like we get with Java, code completion. If we can get that, the sooner we can get it the better. XML Schema provides that today out of the box, it's a standard. I would like to see us use that. The other things I want for JSF is it has got to be easier to create components and I would like us to take advantage of some of the work that has been done: potentially an Ajax4jsf CDK and potentially have a build framework for doing components so that you can describe it -- whether it be through annotations or an XML descriptor -- and it will generate a lot of the necessary UI components in Java and the necessary XML Schema, if that is going to be supported for doing the views. It just needs to be easier to do that. We get a lot of criticism for that. The other thing - obviously that a lot of people talk about - is the state management. It is one of those things that needs to be talked about. I don't necessarily have a solution for it right now but it's one of the things that JSF gets criticized for a lot. My main goal for 2.0, that I'd like to see happen, is for people not to dislike JSF so much. We need to try to understand why people hate it so much because it reflects poorly on the platform if JSF isn't good. It's just like when EJB has had problems and people didn't want to use Java EE, they wanted to use Spring, so we solved that with EJB 3 and more with 3.1. We have to move through the same path with JSF. We have got to move it forward.
Kito I will say as an EG member who is working hard on JSF 2, that we are really doing a lot of that stuff. I am not sure about the schema. I think you do have a lot of selling to do on the schema thing, but in terms of simplifying component creation, it's not necessarily code generation but it is definitely down to the minimum of one artifact. State management will be solved. We haven't gotten to it yet but we will.
Dan Actually, one thing about the component creation: one of the things that was interesting about the Ajax4jsf CDK is that they use JSP to create the actual HTML dynamic output. One of the things that was not really addressed in the first spec was that we went back to essentially servlets, and we were spitting out HTML using Java which is unattractive. If we could have some sort of way to create almost something like Wicket where you essentially have the ability to create the things in straight HTML and have bindings…
Kito That's exactly what we are doing.
Dan That's great to hear.
Kito Dan, it has been a pleasure. Enjoy the rest of the conference, and I'm sure we'll see you write an article someday for JSFCentral.
Dan I appreciate the opportunity, Kito.
Announcer That's it for this edition of the JSFCentral podcast.

Don't forget, you can catch Dan Allen and other expert JSF speakers at JSFOne, the one event exclusively focused on the JSF Ecosystem, taking place September 4th-6th in Vienna, VA. For more info, visit www.jsfone.com.

The music for this podcast was composed and performed by Kito Mann. Thank you for listening...


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.