DigitalJoel

2010/02/13

Spring Roo and JSF 2?

Filed under: development — Tags: , , , , , , , , — digitaljoel @ 2:07 pm

In my latest project we’ve been playing with Spring Roo.  You can read all about the advantages of it on that site, but the gist is that it creates your entities and JPA persistence code for them.  It will also configure your database connection, generate unit tests, generate a JSP/JSTL based UI with all of the Spring MVC controllers, and selenium tests for it.  It will also optionally integrate Spring Web Flow into the mix.  It’s basically a web based CRUD application in a box.

I spent the last 3 days trying to figure out how to use JSF 2 in Glassfish 3 with a Roo generated application.  Much of this pain may have been caused by my lack of experience with JPA and Spring, but here are a few of the difficulties I faced.

  • JSF 2 is not well supported in eclipse yet, whereas Netbeans 6.8 has excellent JSF 2 support.
  • All of the entities created by Roo just have properties.  All of the getters, setters, and other methods are all included in aspect files and compiled into the entity through AspectJ.  The AspectJ plugin for eclipse takes care of this if you have weaving enabled.  Guess what… There’s no aspect based plugin available for Netbeans, so you get a ton of compile problems in your Roo generated project if you try to open it within Netbeans.
  • The Roo projects are all maven based.  I have yet to see really good success with any maven integration within Eclipse.  Netbeans maven integration is spot on.  For the past 2.5 years I’ve been developing within Eclipse and simply doing all of the maven stuff from the command line because it’s much simpler than dealing with Maven in Eclipse.
  • JSF can’t be used to call Spring MVC controllers.  The Spring MVC controllers generated by Roo are nice.  They are simple and clean, and having them managed by Roo is just that much better.  Unfortunately, Spring MVC is stateless, whereas JSF is stateful, so calling any Spring MVC controller from JSF without using Spring’s Web Flow just doesn’t work.
  • JSF 2 can’t be used in the current version of Spring Web Flow.  Even though a sub component of Web Flow is Spring Faces, the current version of Spring Faces only supports JSF 1.x.  As soon as I put Spring Faces in the classpath, my JSF 2 app wouldn’t render any .xhtml files for me.  Removing Spring Faces from the classpath allowed me to render .xhtml with JSF 2.
  • The transaction type specified in the Roo generated persistence unit is RESOURCE_LOCAL.  Glassfish 3 told me I had to use JTA.  I believe Roo can generate a jndi based data source, which I haven’t tried yet.  I ended up manually modifying the persistence unit (after a lot of time on Google) to be jndi based and have the JTA transaction type.  Unfortunately, this means that all of the Roo generated unit tests fail.  I suspect if I had Roo generate the jndi data source then the unit tests would also pass, so hopefully this issue was self inflicted.  Update: I created a simple project with a jndi datasource.  Unfortunately, all of the unit tests fail.   There is some information in the (closed as won’t fix) bug at https://jira.springsource.org/browse/ROO-311 It would be nice if the unit tests that are created for Roo would use the Spring SimpleNamingContext (and I may be just making stuff up now because I don’t know a lot about Spring/JNDI stuff) or something to allow the unit tests to run if the persistence setup uses jndi.

So why would I continue in my endeavor to use JSF 2 with my Roo project, and where do I go from here?

We are trying to make development as easy as possible for the designers.  They have next to no Java experience at best and just want to tweak styles, layout, and images.  I believe JSF can do a great job of giving us that separation.  I can get the controls working in the form, and they can move them around and do whatever they want with them.  Also, with the composite components in JSF 2, we should be able to make some very nice reusable components for the designers to use in our application.  Finally, many of those components we should be able to share with other projects in the company.

So what is the solution to all of the above problems?

  • Education.  Obviously learning more about JPA and Spring will make the whole journey a little easier for me.
  • Separate projects.  If we have all of the domain model in one maven project, and have the web based UI in another (which is how it really ought to be anyway) then the java developers can use Eclipse or STS for their IDE and get the AspectJ support, and the web designers can use Netbeans 6.8 for the JSF 2 project and get the great support there.  Because the domain model will simply be a jar dependency for the web project all of the aspect based methods will be compiled into the class, meaning we won’t need any Aspect support within Netbeans.

What would it take to get a JSF 2 UI generator into Roo?

  • The Roo team has released a nearly 100 page document about Roo.  Unfortunately, all of the parts about how to implement a new addon for Roo are marked as TBC.  There’s precious little detail on the web too.  Unfortunately, I’m not quite ready to dive into the source code to try to figure it out.  So, a simple Roo addon isn’t quite there.  Update: The only reference I found regarding writing your own Roo addon is at http://www.slideshare.net/desmax74/spring-roo-internals-javaday-iv and the slides leave a lot to the imagination of the reader.
  • Rumors in the Spring forums are that Spring Faces is going to be a new top level project, freed from the grasp of Spring Web Flow, and that the next version (due in June 2010?) will support JSF 2.  I was quite excited to use Web Flow with JSF 2 for the bean management relating to flows.  For instance, a new whatsit wizard that spans multiple pages and manages the scope of the new whatsit bean.
  • Because JSF doesn’t work so well with Spring MVC without Web Flow, and Web Flow won’t support JSF 2 until Spring Faces is split out and both Web Flow and Spring Faces release their next version I believe it’ll be months at best before we see any JSF 2 capabilities within Roo.  The only way it could happen sooner is if someone dives into the Roo source code and creates a third-party addon that will generate JSF 2 controllers and xhtml pages.

So, there it is.  At least 3 days of pain, trial and error, and research all wrapped up in one blog post.

Advertisements

5 Comments »

  1. Thanks for the comments.

    For Roo 1.0.0 we focused on delivering a high-quality Spring MVC REST-based user interface. This is because request-response applications are the most common type of application we’ve been seeing people build with Spring as well as other RAD tools. In Roo 1.1.0 you’ll find we’ve taken the MVC approach to the next level, with extensive refactoring and improvement of the JSPX view template model. In fact I think many people who prefer server-side component-based web development might even come back to request-response once they see how nice JSP can be (yes, I used to really dislike JSP too, but after seeing our next-generation JSPX model it’s hard not to give it another serious look).

    JSF support has been requested and is being tracked as http://jira.springframework.org/browse/ROO-516. You might like to vote for the issue there, so we can track community interest and you can receive updates. We have been working with an external contributor to assist them with writing a Roo JSF add-on, but I am unsure of its present status. We have also recently hired another member of the Roo team and he has extensive JSF experience. As such we have more internal capacity and skills to implement JSF should there be sufficient community demand (expressed via votes for ROO-516). We will continue to work with external parties who are developing JSF support, though, of course.

    Concerning Roo’s documentation, it is true that we need to finish this off. I stopped writing the add-on sections due to time and also the plans to improve add-on discovery and distribution in the next major version. We will get to it, I promise. 🙂

    In relation to NetBeans support, it is our hope that NetBeans eventually adds full support for AspectJ inter-type declarations just as Eclipse enjoys via AJDT. This would benefit both the NetBeans community and the AspectJ community. Note that Roo does not require any specific IDE support. We only need AspectJ to be supported by the IDE. Other projects like Roo (of which there is one at Apache, for example) will also be able to work in NetBeans if this AspectJ support were matured. It is interesting that IntelliJ’s http://youtrack.jetbrains.net/issue/IDEA-26959 issue already has some 33 votes, so I hope for full AspectJ support in IntelliJ soon. We at VMware are very happy to assist the NetBeans plugin developers on AspectJ support, just as we have offered to the IntelliJ plugin developers.

    Thanks for your interest in Roo. We appreciate your thoughts.

    Cheers

    Ben Alex
    Lead, Spring Roo
    VMware

    Comment by Ben Alex — 2010/02/15 @ 11:44 pm

    • Ben, thank you very much for your input on my ramblings about the Roo project. It’s interesting to get some inside information.

      Regarding ROO-516, I had already voted even before writing this blog post. I wasn’t sure if it would be appropriate to promote that issue here, so I just left it out.

      As for Netbeans vs. Eclipse, the lack of AspectJ support in Netbeans isn’t _really_ your problem, but it’s nice to see that you have made so many efforts to help it happen. Obviously, the other option would be to get better JSF 2 support in Eclipse, so we can’t lay all the blame on the Netbeans folks. 🙂

      Thanks again for your input. I’ll be interested to see where the Roo project goes next.

      Sorry for the delay in getting your comment posted. It wound up in the spam folder for some reason.

      Comment by digitaljoel — 2010/02/17 @ 5:57 pm

  2. Hello DigitalJoel, thanks for your entry. I had the pleasure of seeing Rod demo Roo first hand at a conference recently, and about two minutes into it I thought: “this needs to support JSF”. I’ve been mentoring a friend of mine on a Kenai project to do just that. You can see it at http://roofaces.kenai.com/ . This project is still in the very early stages, so any help is much appreciated.

    I encourage you to vote for JSF support in SpringRoo. I just did.

    Thanks for the blog entry!

    Comment by Ed Burns — 2010/02/18 @ 2:11 pm

    • Thanks for the pointer to roofaces. That looks like it could be an interesting project.

      I’ll be interested to see where the Spring Faces and Webflow projects go in the near future. I think they could make it easier to use the existing Roo infrastructure to build a JSF application. That said, my little bit of experience with vanilla JSF 2 with regular annotated managed beans has been a joy compared to JSF 1.x, so roofaces may add considerable value on its own.

      In any case, thanks for the comment, and yes, I’ve already voted on ROO-516.

      Comment by digitaljoel — 2010/02/18 @ 2:29 pm

  3. For JSF support on STS / Eclipse check out JBoss Tools : http://www.jboss.org/tools/download

    Comment by Hendy Irawan — 2010/03/04 @ 5:24 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.