BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Struts and Shale (JSF) Finally Part Ways

Struts and Shale (JSF) Finally Part Ways

Bookmarks
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

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Missing the Buck

    by Jacob Hookom,

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Re: Missing the Buck

    by Floyd Marinescu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: Missing the Buck

    by Jacob Hookom,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ...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.

  • Passing the Point

    by Corby Page,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Passing the Point

    by Adam Winer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Passing the Point

    by Don Brown,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Re: Passing the Point

    by Craig McClanahan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: Passing the Point

    by Craig McClanahan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT