Raible Designs

Thoughts on MyFaces 1.2 vs. JSF RI

Yesterday, MyFaces 1.2 was released. I took the opportunity to upgrade AppFuse Light and found it surprisingly easy to do so. The only issue I ran into is my testing logic no longer works. I haven't had a chance to dive deeper into trying to fix the problem, but I did check the code in.

Since I'm using Facelets with MyFaces, I figured it should be possible to run my app on Tomcat 5.x. No dice. I tried replacing MyFaces with Sun's RI (version 1.2_04) and voila! - it works.

From what I learned yesterday, it appears that MyFaces 1.2 will only run on a container that supports JSP 2.1. Sun's RI, on the other hand, will run on a Servlet 2.4/JSP 2.0 container. I don't know if Sun's RI is doing things properly, but it doesn't seem like Servlet 2.5 is required (which is kinda nice IMO).

You might ask why I care about JSP 2.0 vs. JSP 2.1? In reality, I don't. However, if I were to mix and match Struts 2 and JSF in the same application (using the Struts 2 JSF Plugin), I'd like to do it on a JSP 2.0 container. Why? Because OGNL (the EL in Struts 2) uses the pound sign (#) for expressions and JSP 2.1 hijacked that. Until the Struts team fixes that, I'm stuck on JSP 2.0. The workaround (disabling EL for all JSPs) doesn't seem like a good option to me.

Java Web Frameworks and XSS

In preparation for my talk at OSCON next week, I've been doing some research on cross-site scripting and how good Java web frameworks handle it. I'm disappointed to report that the handling of XSS in Java web frameworks is abysmal. First of all, the JSP EL doesn't bother to handle XSS:

With JSP 2.0 you can use the following to emit the description of a "todo" item:
${todo.description}
That's pretty nice. What happens when someone has entered a description like this?
<script type="text/javascript">alert('F#$@ you!');</script>
Well, it executes the JavaScript and pops up a nice little message to you.
...
My question is this: Why in the world did the expert group on the JSP 2.0 JSR decide to make not escaping XML content the default for EL expressions, when they made the opposite decision for c:out?

(Emphasis mine) If a company/developer wants to make sure their JSP-based code is not susceptible to XSS, they have two choices (as I see it):

• Do lots of code review to make sure <c:out> is used instead of ${}.
• Hack the jsp-compiler/el-engine to escape XML by default.

The good news is #2 doesn't seem to be that hard. I pulled down commons-el yesterday, added a hack to escape XML, re-jarred and put it in Tomcat 5.0.25's classpath. This actually worked and I was impressed it was so easy. However, when I looked at Tomcat 6, commons-el is no longer used and now there's a "jasper-el.jar" in the lib directory. I don't mind modifying another library, but what's the difference between jasper-el and commons-el?

Of course, the whole problem with JSP EL could be solved if Tomcat (and other containers) would allow a flag to turn on XML escaping by default. IMO, it's badly needed to make JSP-based webapps safe from XSS.

On a related note, there's a couple of web frameworks that I've found to be susceptible to XSS: namely Spring MVC and Struts 2. For Spring MVC, its <form:input> and <form:errors> tags are vulnerable. For Struts 2, OGNL expressions are evaluated, which is way worse than XSS and actually allows you to shutdown the JVM by putting %{@java.lang.System@exit(0)}" in a text field.

Even though it was surprising for me to see the issues with Struts 2 and Spring MVC, I'm somewhat glad they exist. If I hadn't discovered them, I might blissfully think that Java web frameworks aren't susceptible to XSS. However, it appears they're not only susceptible, but no one is really thinking about XSS when developing these framework. To further prove that theory, the Spring MVC and Struts 2 teams are aware of these issues, have been for quite some time - yet they've done nothing in the form of releasing upgrades or patches.

Seems kinda strange doesn't it?

The Security Annotation Framework

Spotted on the Acegi Security mailing list several weeks ago:

A few weeks ago, I started an open source project (Security Annotation Framework) which addresses annotation-based, instance-level access control for Spring applications. It is also based on Spring 2.0's extensible XML authoring features. You can find more info at

http://sourceforge.net/projects/safr and http://safr.sourceforge.net

The framework was created during a project in 2006 and is now available under the Apache 2.0 license. It's a generic framework focused on processing security annotations on Spring beans as well as domain objects (which typically aren't managed by a Spring application context) and can be used to enforce access decisions for domain object instances. It can be used with any authorization provider and is not specific to Acegi. However, I plan to include an example how to use the SAF with Acegi authorization soon. Furthermore, it supports inheritance of annotations from base classes and interfaces.

What do you think about SAF? Are annotations a better way of implementing ACLs on domain objects?

Spring Web Flow and JSF

Keith Donald has a nice and long writeup on Spring Web Flow 1.0.3's stellar support for JSF:

One important area where our integration is growing is with the Java Server Faces (JSF) community. Beginning with Spring Web Flow 1.0.3, our JSF integration is on-par with what the Spring community expects, and delivers what JSF developers in the trenches need most. This blog will illustrate the integration enhancements to show you the difference Spring Web Flow is making for JSF developers.

One of the most interesting parts of the post is a few paragraphs down:

Basically, Web Flow solves every problem this pour soul experienced with JSF's basic navigation capabilities. As one of our leading users noted, Web Flow can be used as a complete replacement for JSF's default "forward-centric" navigation model.

It's also interesting to note that ideas from SWF could be incorporated into JSF 2.0:

I'd also like to take this opportunity to encourage those already using Spring Web Flow in a JSF environment to speak out about your experience?send me an email, leave a comment here, write an article on JSF central, tell leaders in the JSF community about your experience. Your real world experience can help influence the direction of the JSF 2.0 specification in a time where the specification lead has asked for community feedback. Interface21 has been extended an invitation from Ed Burns, the JSF specification lead, to be a part of the JSF 2.0 expert group, which is a recognition of Web Flow's contribution as an innovative JSF extension. We have accepted that invitation and are excited about helping channel whats proven to work in the area of navigation and state management on a general basis back into JSF 2.0, while continuing to chart new territory and remaining usable in any environment.

Are you using SWF with JSF? If so, have your experiences been good or bad? I'm sure Keith would love to hear about them either way.

I think it's interesting to note that both Interface21 and JBoss are doing a lot to build solutions to JSF's problems. Is there money to be made from supporting JSF? In reality, you have to like what both companies are doing: they're building solutions to overcome the shortcomings of JSF and they're contributing those solutions back to the community for free. Even cooler is the fact that both companies are trying to get their solutions into the next version of JSF. This benefits everyone as far as I'm concerned.

What about those of you using Spring Web Flow with Spring MVC or Struts? How is it working for you?

I recently integrated Spring Web Flow into my current project using the Spring Webflow Plugin. In the past, I've used SWF with Spring MVC and JSF, so the Struts 2 Plugin seemed a bit odd. I guess I'll know more once I start using it more.

This brings up a good question - do you think it's better to create a page flow (i.e. a shopping cart) without Spring Web Flow first, and then refactor? Or do you think it's easier to use SWF from the beginning? My gut feeling is to start w/o it because you may not need it. Then if you do need it, you'll understand the problems it solves. What are your thoughts?

JSF still sucks?

Granted, this post about how painful JSF is is almost 6 months old, but I think it's still mostly true.

Want to compare times? More than three man-weeks have been spent fixing silly JSF navigation problems. A full CRUD AJAX interface with Spring MVC and prototype in the same project took four days, and there was no previous experience with Spring MVC.

If you're going to use JSF, I highly recommend Facelets or Shale/Seam. However, those are mentioned as well:

The default view technology is JSP, even when no one in the real world would recommend it; instead, use Facelets, or Clay, or some other non-standard framework. Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'.

IMO, Facelets is very easy to learn. If you know how to program JSPs with JSF, you should be able to use Facelets in under an hour. When we converted AppFuse's JSF flavor from JSP to Facelets, rarely did the body have to change - we just had to change from taglibs to XML namespaces.

When you are not working with persistent data (if you are living in a cave or developing wizard interfaces) there are two scopes to store model state: the session context, which raises concurrency issues and is not recommended by the Faces community, and the conversation/process/whatever context, which is not standard and imply installing shale or seam to put even more lipstick on the pig.

There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".

Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.

If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard. If it was a de-facto standard, that'd be another story.

Of course, you could also help improve JSF 2.0. But that's not scheduled for release until late 2008. I'm sure 2 or 3 commentors will claim we'll all be using Rails or Grails by then.

Zero Configuration in Struts 2

Struts 2 has a nifty zero configuration feature. However, it's only useful for registering actions, not for automatically registering results. In other words, you still have to use an @Result annotation to tell your action what page to dispatch to. To use default view names instead of requiring @Result, you can use the Codebehind Plugin. Also, did you know Struts 2 will autowire your Spring dependencies? It's pretty slick.

What does this all mean? It means you can write your Struts 2 application without writing any XML. Of course, you can still use XML to tweak behavior, but with these plugins enabled, you won't have to.

IMO, these plugins should be combined into a single zero configuration feature.

Here's how you can enable Struts 2's Zero Configuration feature in AppFuse 2.0:

1. Add a packageNames parameter to the "struts" filter in your web.xml:
   

   <filter>
       <filter-name>struts</filter-name>
       <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
       <init-param>
           <param-name>actionPackages</param-name>
           <param-value>com.company.newapp.webapp.action</param-value>
       </init-param>
   </filter>
   

2. Add the Codebehind Plugin as a dependency in your pom.xml:

   <dependency>
       <groupId>org.apache.struts</groupId>
       <artifactId>struts2-codebehind-plugin</artifactId>
       <version>2.0.6</version>
   </dependency>
   

3. Add a struts.codebehind.pathPrefix constant in struts.xml for your default pages directory:

   <constant name="struts.codebehind.pathPrefix" value="/WEB-INF/pages/"/>
   

That's it - now you can code away without configuring anything!

How does this compare to other web frameworks in AppFuse? Tapestry has a similar feature, but Spring MVC and JSF don't. Spring MVC still requires you create a bean definition for Controllers and JSF requires you write a chunk of XML for each managed bean. Of course, if you know how to do something similar with Spring MVC or JSF, please let me know.

Message Driven POJOs by Mark Fisher

Last night, I attended the New England Java Users Group to see Mark Fisher talk about Message Driven POJOs. This was the first JUG I've been to (outside of Denver's) where I was an attendee instead of a speaker. It was interesting to see how they do things. They have one main speaker who speaks for two hours. After the first hour, they have a break, offer pizza and do a raffle. Then the speaker continues. They require you to "register" at least 48 hours before the meeting starts. This is because the meeting is held at Sun and they (apparently) need to do it for security purposes. They actually checked my ID and made sure I was registered at the door. After I passed their verification test, I received a name tag. While I like Denver's Basic Concepts followed by Main Speaker setup, I liked that this JUG meeting was over at 8:15. Below are my notes from the event.

Topics in this Session: Overview of JMS, Spring's JmsTemplate and implementing a Message Driven POJO.

Goals of JMS: provide a vendor-neutral abstraction for accessing Message Oriented Middleware from Java. It provides for enterprise messaging systems what JDBC provides for relational databases. See Wikipedia's definition of JMS for more information.

The API is what insulates your code from the JMS implementation you're using. The JMS implementation will use a message broker to communicate between servers. Tonight, Mark will be using ActiveMQ in his examples. He plans on doing most of his presentation in Eclipse because he's been spending 14 hours per day in PowerPoint revamping Interface21's training courses (I don't miss that at all).

The JMS Message is the central object to JMS. There's various types of messages, TextMessage, ObjectMessage (I missed the rest). Two types of JMS Destinations are available: Queues and Topics. A JMS Session is used to create messages as well as producers and consumers. Examples calls:

• session.createTextMessage(String)
• session.createConsumer(dest)
• session.createProducter(dest)

A JMS Connection is obtained from a JMS ConnectionFactory. The ConnectionFactory is typically accessed by a JNDI Lookup.

JMS is most commonly used for internal application communications (not public facing).

Templates are common in the Spring Framework and are used to simply API usage. Their main goal is to reduce boilerplate code (resource management, try/catch, etc.). Examples include JdbcTemplate, JpaTemplate, JndiTemplate, TransactionTemplate and (you guessed it) JmsTemplate. Spring also translates exceptions to consistent runtime hierarchies. In addition to one-line methods, Spring's templates supply callbacks that alleviate try/catch blocks - but give you full power of the API.

JmsTemplate has a couple of capabilities: it handles acquisition and release of resources and translates checked JMS Exceptions to a parallel hierarchy of RuntimeExceptions. It's also capable of converting a payload to the corresponding JMS message type with a MessageConverter strategy. Lastly, it provides convenience methods to allow sending asynchronous messages.

Now Mark is showing us how you configure a ConnectionFactory, Queue and JmsTemplate in a Spring context file. The first couple of beans only take 3 lines of code to configure, the 3rd one takes 4 because it has a dependency on the first two. Pretty easy configuration if you ask me. After composing bean definitions, Mark created a JUnit test and called jmsTemplate.convertAndSend() to send a message in 2 lines of Java code.

To receive messages with JmsTemplate (pre Spring 2.0), you could use synchronous receive calls: receive(), receive(Destination) and receive(String). There are also receiveAndConvert() methods.

In Spring 2.0, they added the ability to do MessageListener containers to enable asynchronous reception in a non application server environment. Implementations include SimpleMessageListenerContainer, DefaultMessageListenerContainer and ServerSessionMessageListenerContainer. The DMLC adds transactional behavior, and the SSMLC hooks into the server's SPI. Spring's MessageListenerAdapter enables the delegation to a POJO for handling the payload.

For the next 1/2 hour or so, Mark wrote a bunch of Java and XML to create a simple Trader application. About the same time, I got managed to get an internet connection from somewhere and started browsing the net and answering e-mail. Every once in a while I looked up to see Mark's code - it all looks very simple and straight forward. In Spring 2.1, a <jms:*> namespace will be added to simplify the XML configuration.

For those of you out there using Spring's JMS support - are there any issues you've run into? Are you using it in production? It's always pimped as "awesome", so I'm looking for pain points that folks might encounter when using it.

Related: Spring's JMS Documentation and ActiveMQ's JmsTemplate Gotchas.

[TSE] Keynote: The Bigger Picture with Adrian Colyer

We've seen a lot of things over the last few days, but what about the big picture? It's not just about the Spring Framework anymore, but there's also a lot of sub-projects: SFW, SWF, SWS, S-OSGi. Then there's Enterprise services: clustering, persistence, messaging and scheduling. Industry trends: SOA, Web 2.0/RIA, RAD stacks.

Agenda

• Spring portfolio: unifying themes, fitting the pieces together (by layer) and future direction
• Facing the feature: my boss says I need a SOA, from auto-suggest to RIA and the quest for ever-increasing productivity

[Read More]

[TSE] Spring-OSGI with Adrian Colyer

One of the first questions people ask about OSGi is "what the heck is it?"

Most people don't even know what it is. OSGi stands for Open Services Gateway initiative. From the very beginning, it was designed to be lightweight and dynamic. This is the major difference between it and other containers. It's always been designed to have things added and removed. Now it's tagline is: "The Dynamic Module System for Java".

It's designed to allow you to partition a system into a number of modules (a.k.a. bundles). There's strict visibility rules (similar to protected and private). There's a resolution process (dependencies are satisfied) and it understands versioning.

It's dynamic! Modules can be installed, started, stopped, uninstalled and updated - all at runtime.[Read More]

[TSE] The Holy Grails of Web Frameworks with Guillaume LaForge

Under the hood, Grails uses Spring MVC. It has support for "flash scope" between requests.

I find it funny that flash scope is so popular these days, we've had this in AppFuse for four years. However, web frameworks didn't add native support for it until it had a name (provided by Rails). To be fair to Struts Classic, they had support for it before Rails was even invented.

Rather than JSPs, Grails uses Grails Server Pages, which look much like JSPs. Grails uses SiteMesh by default and allows you to easily change the layout used with a meta tag.

<meta name="layout" content="main"/>

Most of the dynamic attributes in a GSP are rendered using the various "g" tags. There's dynamic taglibs for logic (if, else, elseif), iterating, linking, ajax (remoteFunction, remoteLink, formRemote, submitToRemote), form (select, currencySelect, localeSelect, datePicker, checkBox), rendering (render*, layout*, paginate), validation (eachError, hasError, message) and UI (i.e. richtexteditor). [Read More]