LOTD: Josh Bloch talks about the state of the Java Platform

Wednesday, April 14th, 2010

link: PCWorld Article

An Honest Look at Seam – Part 4: JSF, Faceletts and the State of the View Technologies

Monday, April 5th, 2010

This is the fourth part in a series of posts about the Seam Framework

If you look at my previous blog posts, you know that I despise view technologies that force you to write tag soup. In the aforementioned post, I describe how much I like Apache Wicket because you write your html view in html, not xml, not jsp tags, not some other xml-like templating language or anything like that. Just html (and the associated css and javascript). Then you get to write you controller code in Java, only Java and nothing but Java, using a style very similar to how you would be a desktop app using Swing. But again, this is a post about Seam, so we are going to start by looking at what Seam uses by default.

Seam’s default view technology is JSF, using faceletts instead of JSPs and adding the Richfaces component library. That’s a mouth full. When I first started looking at the .xhtml files that were generated by seam-gen, I was a bit overwhelmed. However, I must say that working with the JSF/Richfaces model is much better than anything else I’ve worked with in the past where we have using JSPs or some other straight-line execution template. The component oriented nature of faceletts feels more elegant to someone used to Object Oriented Programming than the straight-line procedural nature of JSPs. You can decorate components and objects get called back instead of dealing with making sure things are setup before a tag gets called because the page literally becomes a method that gets executed. At this point in time, Richfaces and faceletts are very mature and offer you a lot of components to help build your application, so it all works out well. To me, this is all a step in the right direction, but it doesn’t go far enough.

Those who know me will have an idea of where I am going with this. Use Seam with Wicket. That is right, you can use Seam with Apache Wicket and there is already a lot of momentum for this in the Seam community. You get support for conversations, contexts and coordination (such as security) from Seam in your Wicket components while being about to leverage Wicket’s Swing-style UI components and separation of concerns between developer and designer.

There are some limitations to using Seam with Wicket at this time, specifically, If you are using Seam 2.2.x, you have to use Wicket 1.3.x. If you are using the bleeding edge Seam 3 or Weld, you can use Wicket 1.4. To bridge this gap, I have decided to start an open source project to port the existing seam-wicket module from Seam 2.2 to work with Wicket 1.4. The project is called Seam Wicket Plus, and can be found here: http://code.google.com/p/seam-wicket-plus/. I am just getting this project off the ground, and I would love help and feedback on it.

Next time, I will wrap up this series with a look at Seam 3 and where the framework is heading.

Previous Posts in the series
Part 1: How Seam Builds on Spring
Part 2: The Conversation
Part 3: Learning Seam

An Honest Look at Seam – Part 3: Learning Seam

Tuesday, March 30th, 2010

This is the third part in a series of posts about the Seam Framework

I wanted to take a brief departure from exploring the features of Seam to take a look at a common question I have heard from folks who are considering diving into Seam. It seems (no pun intended) that a lot of people take a look at Seam, download it, run seam-gen on some existing database to see what it does, and then their jaw hits the floor. “What is all of this!?” Seam-gem builds a lot of stuff. You get a completely functioning crud app with all kinds of nice extras. There is a lot of stuff there and much of it will be stuff you have never seen before, even if you have worked with JSF before.

There is a lot to Seam, but not becuase Seam itself is vastly huge and complex, but because Seam integrates so many things together, there is a lot of infrastructure that represents pieces from several open source projects. Additionally, especially in the case of JSF and Richfaces, the line between the frameworks Seam is integrating and Seam itself gets blurry.

For me, using Seam was my first serious usage of JSF. That meant it was also my first serious usage of faceletts/Richfaces and Ajax4JSF (more on that in part 4). So, when I first opened up those .xhtml files, I had no idea what I was looking at. And don’t even get me started on all the various XML files that were in WEB-INF. You have to keep in mind that this is a rather complete application and if you take a look at the XML files, none of them are very long.

To clear some of this up and get a general idea of how the various pieces of Seam fit together, we will take a look at a diagram from Dan Allen’s Seam In Action (Dan Allen. Seam In Action. Greenwich, CT: Manning Publications Co., 2009. 5. Print.). This gives you an idea of where the pieces fall.

Simple Diagram of Seam's High Level Architecture

At it’s heart, Seam is an integration project. It is stitching together EJB3 and JSF. But it does more than that as well. It also extends and improves on JSF and allows you to integrate libraries that provide rendering PDFs, sending e-mails, integrating with Messaging frameworks like JMS and more. It is a very ambitious project, and it must say I am impressed that it pulls it off very well.

There is a lot to Seam and it is going to take some time to digest, but not any longer than if you were learning any other new framework. I am going to plug Dan Allen’s Seam in Action again because it was a huge help to me in getting started with Seam and breaking down all the pieces.

With this covered, I hope that you won’t let Seam intimidate you as you dive in and see if you can leverage it on your own projects. Keep you eye out for part 4, where I will take a look at the view technologies you can use with Seam.

(Disclosure: Neither I nor CITYTECH receive any monetary benefit from mentioning Dan Allen’s book in these blog posts. I sincerely think his book is a great resource on the topic of Seam.)

Previous Posts in the series
Part 1: How Seam Builds on Spring
Part 2: The Conversation

An Honest Look at Seam – Part 2: The Conversation

Wednesday, March 24th, 2010

This is the second part in a series of posts about the Seam Framework

The next part of Seam I want to look at is the Conversation. A conversation in Seam is one of the new contexts that seam brings to the table. It sits in between the Servlet Request and Session in terms of it’s life in the application. The goal of the conversation context is to fill in the gap scoping objects across a logical set of requests that represent a real user case without having to juggle everything in the session. It also allows you to have multiple “workspaces” of your application on different browser tabs, as each tab can have it’s own set of conversations.

Now, what do you think belongs in this conversation context? An easy win here are Stateful Session Beans. The references to these are a no-brainer for the conversation context as they represent a conversation with the EJB container. We can also put business objects that we are building up as part of a wizard into a conversation. In fact, that is exactly where I want to go, proposing that those objects should be your JPA entities. Here’s why. When you use Hibernate as the persistence mechanism or the JPA provider with Seam, you get some extra goodies for tying the persistence context to the conversation. This feature is best understood in contrast to the way most of us have to work in other frameworks.

In most any other web framework, you would have to look up your JPA entity on the first step of your wizard, and either pass it as a detached entity through the wizard, making a JPA merge call at the end to persist the change, or you can manage and merge the changes yourself. Either way, merges are messy, and either blind to data clobbering or complex to code. Also, the fact that your JPA entity is detached means you can’t traverse the object graph without either getting lazy load exceptions (we all love those) and/or having to re-lookup the entity for each page.

There are two things that Seam does to address this problem. The first is that it binds the entity manager to the conversation, and keeps it open for the life of conversation, across multiple requests and multiple transactions. (Seam still runs with a transaction per request model, but you will see how the conversation works with that by the end of the post). This means that you can keep references to your JPA entities across requests and they don’t get detached. This reduces traffic to the database because you aren’t looking up the data in the database over and over again with each request. You also don’t have to resort to the “Open Session in View” pattern in order to avoid lazy load issues in your view layer.

The second thing Seam does has to do with a special feature in Hibernate. Hibernate implements a additional flush mode for the entity manager beyond JPA’s AUTO and COMMIT, called MANUAL. What it does is tell the entity manager to not flush changes to the database until it is told to, even across transactions. Seam will enable (when you ask it to) the MANUAL flush mode of Hibernate on your conversation scoped entity manager, which means you can modify your entity on the first page of the wizard, carry those changes through, and not have them flush (and thus commit) until the conversation is ended. This is significant because if the conversation never completes, the changes the user made during the wizard are “rolled back” when Seam cleans up the abandoned conversation (which it does for you without you having to worry about it). You get this rollback without having to detach your entities or worry about the data from the wizard ending up in an inconsistent state.

Now, the one caveat to this is that you must use Hibernate to get the Manual flush piece. The other pieces (including the conversation scoped entity manager) are available no matter what JPA provider you use. With that in mind, write to the JPA expert group and tell them you want manual flush to get into the next revision of the spec!

In the next part, we will take a step back from the features and address a question that I have gotten a lot about Seam. “Seam seems to be really complex and big. How do I go about learning it?”

Previous Posts in the series
Part 1: How Seam Builds on Spring

An Honest Look at Seam – Part 1: How Seam builds on Spring

Thursday, March 4th, 2010

I have been spending a lot of time with JBoss Seam, and I must say, I am very excited about what I have seen. My goal in these next few posts is to talk about why I think these features of Seam are game changers and what they are saying about the direction the JEE Spec is going.

Before I dive into the topic for this post, one of my coworkers gave a brief introduction to Seam a few weeks ago. I would recommend reading it first if you are completely unfamiliar with Seam. If you are looking for a more thorough introduction (other than the reference docs), I give my recommendation goes to Seam in Action by Dan Allen. It has been my guide in my own exploration of Seam and, in spite of it’s Seam 2.0/2.1 focus, it is extremely relevant to working with Seam 2.2 today. With that out of the way, let us begin with some background.

I am a big fan of the Spring Framework. The many “glue code” utility classes and the Spring IoC Container have been staples in my applications since I started working with the Java Platform. Spring provided a way to do POJO programming in a world that was under the tyranny of the ugly EJB 2 programming model. They created an alternative to a broken standard that was very welcome. But this post is about Seam, so what’s all the Spring talk for? One of the key features, or rather the key feature, of Seam is what the Seam guys like to call Contextual Components. For those of you with a Spring background like me, a Seam Component is analogous to a Spring Bean. The contextual piece is what makes it interesting.

In Spring, you usually assume that a bean is going to be a singleton and that it is going to be stateless. That is the way of things with Spring. The common case is that everything is constructed at startup and all wired together before your application services it’s first request. You get all that glue code and DI goodness right up front. There is another way to handle your beans that is not as widely used. You can declare the scope of a bean to be Prototype, which means Spring will construct a new instance of that bean for you each time you ask your ApplicationContext for it.

Seam has taken this a step further. Instead of beans being limited to being either Stateless application singletons or construction prototypes, Seam let’s you scope components to rich set of contexts. See here for the complete list. This makes the Seam context not just a repository of pre-built service objects, but a scoped application state manager that is managed as a central concern of the framework (which is a fancy way of saying Seam takes care of the plumbing so you don’t have to). Now, instead of having a DAO object that encapsulates your data access methods, you can have a Data Mediator that not only knows how to get at an entity instance and save changes back to the database, but it also tracks the instance in the proper scope for you, so you only have to read it once from the database, even across multiple http requests. It is extremely powerful.

The other piece that Seam adds is called Outjection. No, that isn’t a typo. As part of an operation invoked on a Seam component, it not only gets all it’s dependencies injected, scoped as appropriate for the context of the components involved, but it also can send new components back to the context to be used by other parts of the application, managing the scope all the way.

What does this mean practically? No more leaky Http Sessions!

Now, if you are wondering if this is relevant to where JEE is going, take a look at JSR 299. CDI, or “Web Beans” as it has been called, is largely based on what I just explained to you. This JSR is part of JEE 6 and will available in the next update to your favorite application server. You can get this functionality now with Seam 2.2, or if you are required to “stick with the specs” when you do things, go ahead and download Weld, the JSR 299 reference implementation. Weld is what JBoss AS 6 is using to implement CDI and what Seam 3.0 will be built on.

In my next post, I’ll talk about the power of the new Conversation Context that Seam and JSR 299 introduce.

Why REST made me like web services again

Monday, March 1st, 2010

I spent most of last year working on a project that has afforded me the opportunity to work with some technologies that I had played with a bit before, but hadn’t actually used them in a full-scale project. Apache Wicket is one of those technologies, that I wrote about previously and the other one is RESTful Web Services using JAX-RS.

There are many other great articles on why you would write a service layer that encapsulates your business rules and keep it separate from the UI, so I’m not going to go over that. I will just tell you that we had the goal of creating reusable services for our project, but we wanted to try something different as we were rather disillusioned with SOAP web services and EJB RMI was out as we need to support cross-platform clients.

First, my grief with SOAP is that it is really just another implementation of remote procedure calls that we have all come to know and loath. I have used remote procedure calls in CORBA, Apache’s XML-RPC, EJB RMI (Remote Session Beans) and WS-*/SOAP web services. I’m going to lump these all together into the remote procedure call bucket and tell you that I have had the same issue with all of them. They are incredibly difficult to reuse if you like to have explicit method signatures. This is problem I have experienced many times on various projects. I will also pick on WS-*/SOAP a bit because they built this monster amount of XML protocol on top of HTTP to get around the limitations of HTTP. It makes for a mighty headache when you are trying to debug.

Now, REST’s goal is to simplify things and to use the HTTP protocol’s full spec to make it easier to express what is going on in your service. REST also shifts the model from a remote procedure call to changing the state of a domain object. When you are working with a RESTful web service, I find that it feels a lot more like working with a database record than calling a remote procedure. I think most developers agree that makes it a lot easier to program because you know what to expect. You get a thing from the DB, change it, and save your changes. This is much more intuitive than “You make a call to get a thing. Then you maybe have to change that thing or get some stuff out of it and assemble a bunch of parameters that may or may not be related to what you are doing, but are there because some other client needs them and then make a call”.

Now, you may have instances where you need to get the equivalent of the procedure call in your RESTful web service. For example, in the security module, we need a way to tell the system to generate a random password and email it to the user. What we came up with was to do a POST to /users//password, which would generated, hash, save and email the new password on the backend. Then, the next time the user logged in, and we forced them to set a new password (since the last one went out over email), we would do a PUT to /users//password with the new password in the request body.

I really like the programming model that JAX-RS gives you. We have been using the jersey implementation of JAX-RS 1.0 on our project. The API makes it dead simple to map your HTTP methods and URL patterns to java classes. It integrates easily with JAXB (our choice for Java to XML translation). You just put JAXB annotations on the objects you want to return or use xjc (which can be a bit of a pain) to generate java classes from your XSDs. All the major JAX-RS frameworks also have extensions that let you use JSON as the wire format for your JAXB objects instead of XML. The amount of code you have to write is very reasonable for a java framework.

Being that I am a total transaction management nerd, I do need to say one thing about the state of RESTful web services. At this time, the only transaction model you will get with REST (at least that is cross-platform friendly) is idempotency. This is something that most developers are not used to. They are used to either assuming a single data source, or, in the case of something like Remote Session Beans, JTA just handles all the magic for you and ties everything together with a nice pretty XA bow (unless you are the one configuring XA, which can be a difficult task).

Thoughts on Snoracle and Why I like JBoss

Wednesday, February 10th, 2010

There are two blog posts I have read over the past few weeks that I think give good summary of how to digest the whole “Oracle-buying-Sun-thing”. The first is from Rich Sharples of Redhat on his personal blog. The second is from Mark Little, also of Redhat.

The main take I want to emphasize is that Java is here to stay and is going to continue to be a great platform for building software. I also think that now is a better time than ever to take a look at JBoss, especially with Oracle choosing to cripple Glassfish by disallowing features like clustering, which JBoss supports out of the box.

Official disclaimer: CITYTECH is a JBoss Partner. With that said, I have been working with JBoss AS for 5 years now, starting with version 3.2.x. Having watch the product grow through the 4.x series and now with 5.1 bringing us JEE5 goodness and 6 reaching it’s first milestone in December, things are looking great. I am totally geeked out about JEE6 and the way that it builds on JEE5. I’ll talk more about that in an upcoming post on Seam.

JBoss also has a bunch of other technologies that are worth getting excited about, some of which I hope to have a couple of posts up on soon. Watch for me to cover Seam and GateIn, as I am building an application with them right now.

Earthquake?

Wednesday, February 10th, 2010

Last night, my wife and I were woken at 4AM by what we thought for sure were just high winds. But 20-30 mph winds don’t cause the house to creak and you to feel a small, but real sense of motion. Turns out there was an Earthquake last night in Northwestern Illinois, about 30 miles from where we live. Only a 3.8 on the Richter scale, but I still must say I’d never thought I would experience an earthquake in the Midwest. Wild.

Oracle-Sun deal gets approved by EU

Thursday, January 21st, 2010

Finally.

via CNET

More on the Sun/Oracle Saga

Friday, November 13th, 2009

The EU officially opposed Oracle’s acquisition of Sun earlier this week, and it looks like a fight is going to break out. Will there be anything left of Sun before the dust settles?

Welcome to the blog of:

Matt Campbell