InfoQ

News

Struts and Shale (JSF) Finally Part Ways

Posted by Floyd Marinescu on Jul 04, 2006 11:13 AM

Community
Java
Topics
Web Frameworks
Tags
Shale ,
Struts ,
JSF
After a heated discussion on the Struts-Dev list about the future of Struts and Shale,  it has been announced late last week that Shale will become it's own top level Apache project, instead of a sub-project of Struts.

Shale began as a proposal for Struts 2.0's migration to JSF, but the Struts community itself never got fully committed to JSF itself which takes a component-based instead of action based approach to web development.  Shale thus became a subproject  to Struts to provide a JSF alternative, where it has been in develompent for almost 2 years and is now approaching its first stable release.  

The discussion on the Struts list began with Don Brown proposing unification: "Struts would be the single framework the world would see.  It would contain support for Action-based, JSF-based, and hybrid applications. "   Struts & Shale founder Craig McClanahan (who is also the main proponent for Shale) later responded quite bluntly: "the bottom line is that, in 2006, I have philosophical differences with action oriented frameworks (in the sense of what we see available today) as the right long term answer to designing new Java based web applications -- Struts or WebWork or whatever. "  Craig went on:  "for new developers, I would much prefer to compete with SAF2 than to cooperate with it. If that means a (hopefully amicable) divorce, then so be it."

In response to this, Ted Husted wrote: "If that is the case, then the next question would be whether Shale would be a better fit as a top-level ASF project, a subproject of MyFaces, or somewhere else entirely? " The discussion then had most of the WebWork, Struts, and JSF personalities weigh in with some proposing integration and others suggesting that parting ways while cooperating where it makes sense being the best approach. 

The outcome was Shale finally parting ways and becoming it's own project.  Shale will no longer benefit from the incredible power of the Struts marketing brand, but the community itself has voted as the Struts community overwhelmingly is in favour of continuing as a modern action oriented framework via migration to WebWork 2.3.

This over all news is good both for Struts and JSF developers, as the industry will not have clarity and also both camps will have greater freedom to evolve separately.

Interestingly, the over all debate possibly revealed some of the fundamental conficts of interest between the java development community and the java vendor community,  with Craig himself stating in one post that "Struts Action Framework 2 is a much better (technical) approach to the problems that Struts 1.x targeted," but earlier making the true motivations behind JSF obvious:
I want to focus on attracting a much larger audience of developers who are *not* O-O professionals, whose idea of "code reuse" is cut-n-paste, and who might actually prefer to use tools (SAF2's fundamental architecture is pretty much untoolable, even if someone were motivated to spend the effort to build tooling around it).

Related news: InfoQ.com/jsf
Missing the Buck by Jacob Hookom Posted Jul 5, 2006 3:10 AM
Re: Missing the Buck by Floyd Marinescu Posted Jul 5, 2006 8:19 AM
Re: Missing the Buck by Jacob Hookom Posted Jul 5, 2006 8:31 AM
Passing the Point by Corby Page Posted Jul 5, 2006 9:41 AM
Re: Passing the Point by Alexandre Poitras Posted Jul 5, 2006 11:50 AM
Re: Passing the Point by Adam Winer Posted Jul 5, 2006 12:14 PM
Re: Passing the Point by Don Brown Posted Jul 5, 2006 12:42 PM
Re: Passing the Point by Craig McClanahan Posted Jul 7, 2006 12:12 AM
Re: Passing the Point by Craig McClanahan Posted Jul 7, 2006 12:19 AM
  1. Back to top

    Missing the Buck

    Jul 5, 2006 3:10 AM by Jacob Hookom

    http://weblogs.java.net/blog/jhook/archive/2006/07/saf2_and_shale.html

  2. Back to top

    Re: Missing the Buck

    Jul 5, 2006 8:19 AM by Floyd Marinescu

    Hi Jacob, We are all for driving traffic to peoples blogs (yes InfoQ has actually gotten big enough in the month since it's launched that it can do that), but it would be more polite (and possibly more effective for you) to also comment in this thread to express your point as well as link off to your blog. Thanks for participating. Respectfully, Floyd

  3. Back to top

    Re: Missing the Buck

    Jul 5, 2006 8:31 AM by Jacob Hookom

    ...to also comment in this thread to express your point as well as link off to your blog.
    I'll take note of that in the future :-) Respectfully, the blog does point back to and mentions InfoQ.com.

  4. Back to top

    Passing the Point

    Jul 5, 2006 9:41 AM by Corby Page

    I like Jacobs's suggestions on collaboration. He says that both SAF2 and JSF should:

    • Use the same annotations to describe validation constraints
    • Utilize the standardized JPA/EJB for RAD
    • Use the same variable/context mechanism, such as the EL-API
    • Action signatures are a no-arg method that return a String
    • Standardized business component concepts
    • Use lower-level interceptor concepts from EJB that aren't deployment specific
    • Continue using common annotations
    I think that WW2 has nailed the action framework stuff, and I'm very happy implementing my actions with it. However, it is taking a lot of awkward missteps into the AJAX component space, and I get jealous of JSF's ability to pick and choose third party components to drop into the UI. I would consider "sprinkling" JSF into my WW2 stuff per Don's suggestion. But as Jacob notes, there are still enough unnecessary incompatibilities between the frameworks that it is too much of a pain in the ass to do so. JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context. In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over.

  5. Back to top

    Re: Passing the Point

    Jul 5, 2006 11:50 AM by Alexandre Poitras

    JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
    The problem is people absolutly want to put a label on JSF. After having worked with it, I can say JSF is a nice platform to work with without using any tools. But some people aren't comfortable with OO and prefer to use RAD tools. Those 2 facts aren't exclusive. From what I understand, Craig didn't say JSF was only superior in a tooling context but that he is looking to attract people coming from VB or Delphi. It doesn't mean JSF is a dirty solution. Not at all. To work with JSF, tools support isn't essential but available if you want it.

  6. Back to top

    Re: Passing the Point

    Jul 5, 2006 12:14 PM by Adam Winer

    We designed JSF first as a solid, component-centric framework, and second as a framework for tools. Whatever the marketing folks did with that (or what Craig is quoted as saying) is not so much my concern. I'm still baffled that the fact that we actually thought about tooling in the first version is somehow a negative thing in anyone's mind - but no one ever suggested on the expert group that JSF was or should be a tooling platform. (I'm also amazed that anyone would claim that any framework - JSF, Hibernate, WebWorks, etc., is somehow best without tooling.) I agree entirely with Jacob's suggestions for collaboration among the frameworks - and JSR 299 looks like a fine place to work through many of these issues. Splitting up and going our separate ways, and leaving it at that, seems like a poor route for all of our users.

  7. Back to top

    Re: Passing the Point

    Jul 5, 2006 12:42 PM by Don Brown

    When I started the thread on Struts dev, my goal was to unify the two groups, not provoke a "divorce". My point was JSF is a solid component framework, and Struts 2 is a proven controller, and the two can and should work together seamlessly. In a perfect world, there would be an action-based controller JSR that could optionally be used with JSF components, and both JSR's would use the same EL, annotations, validations, localization, etc. The Struts 2-style controller is much more powerful than the JSF servlet, and supports other types of views and workflows. On the other hand, JSF, in my opinion, has the better component framework and can handle complex, event-based components, encouraging a component marketplace. It was said that JSF was a view technology that had to define some controller capabilities to get by, so why not replace that controller with a Struts 2-style MVC controller, and let JSF get back to what it is best at?

  8. Back to top

    Re: Passing the Point

    Jul 7, 2006 12:12 AM by Craig McClanahan

    JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.

    Sigh ... that is an incorrect misconception of what I am actually saying, which can be summarized very succinctly:

    • JSF apps can be hand authored just as easily as apps in your favorite action oriented MVC framework.
    • JSF was, *in addition*, designed to make it easy to support with tools.
    • The proof is in the pudding ... besides the existing IDE support for hand authoring JSF apps that is equivalent to what you'll see for frameworks like Struts, you also get to choose from IDEs focused on visual development if you like that approach.
    Craig

  9. Back to top

    Re: Passing the Point

    Jul 7, 2006 12:19 AM by Craig McClanahan

    In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over.
    You might want to think about whether the kind of vendor support you see for JSF today is even technically feasbile for your favorite action oriented framework. Supporting graphical help in updating configuration files is pretty easy (and commonly available for frameworks like Struts 1 today). Supporting development with visual components, on the other hand, is not particularly easy when there is no visual component model, let alone libraries of components that correspond to that model. NOTE - it may well be that you are not won over by this ... and that's fine. In particular, if you like action oriented frameworks, you can't go wrong with Struts 2 ... it is a very elegant evolution of this paradigm. But, I'm thinking that the number of people who can appreciate that elegance is a heck of a lot smaller than the potential number of developers whose lives could be made better by a framework that doesn't require them to understand that elegance in order to benefit from it. Craig

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.