Craig McClanahan Announces Struts and JSF Integration Position

Discussions

News: Craig McClanahan Announces Struts and JSF Integration Position

  1. Many have have wondered at what the future holds for Struts, now that an early access release of JavaServer Faces is available. Craig McClanahan, JSF Spec Lead and Lead Architect for Struts has recently commented on the subject. Craig is working on an integration library for JSF and Struts 1.1 that will allow migration to JSF without major code changes to existing struts apps.

    Read Craig's email on Struts + JSF integration.
    Source: http://www.application-servers.com.

    See Craig McClanahan in his Hard Core Tech Talk (half way down the page), taken at Java One 2001.

    Threaded Messages (31)

  2. Informative, and mostly positive!
  3. I've used struts now on two large projects, and it alone has tons of good stuff. The combination of the JSF and Struts looks to be a very powerful framework, with lots of good choices for the front end renderring. Very cool.

    -Newt
  4. This will give struts an advantage as far as JSF is concerned. I wonder if the other web app frameworks such as webwork are going to push to Integrate with JSF?
  5. Specifically, I would like to hear anything on the integration of WebWork and JSF. Any comment ?
  6. I think that a good open source portal server combined with a deep library of open portlets will give much needed momentum to J2EE. If you add to that an easy to use visual portal editor (portlets drag and drop style) you have a terrible competitor for .net in easy to use, but at unbeatable price.
  7. I couldn't agree more!. I'm doing a Jetspeed project right now but I get the feeling that I have to graduate for my Jetspeed exam first in order to be more productive. I hope that the Portlet API gets stable soon and that there wil be an Eclipse plugins whith some default portals to choose from that can be customized to my needs.
  8. Check out Liferay Enterprise Portal, it's integrated with Struts and is a good J2EE open source portal with a bunch of useful portlets.
  9. I surprised we haven't heard from the Tapestry contingent yet...
  10. Be careful what you wish for, you may just get it.

    I've found a way to mate the Tapestry render process to the JSP render process this will be the focus of 2.3, due in a few months (2.2 is just about ready with a release candidate); you'll be able to use a JSP instead of a Tapestry HTML template, but still have free reign to use Tapestry components mixed with JSTL, JSF or other taglibs.
  11. I'm surprised by this announcement, after reading the JSF spec, it seems like Struts is no longer relevant when JSF becomes the standard. JSF seems to supercede all the things we loved about struts, what is the need for action forms if we now have server side components, what does struts provide us?
  12. Even if many struts addicts won't like it, it basically means leaving struts behind.

    Craig McClanahan is talking more about transition from Struts to JSF than about integrating it. Integration is only needed for step by step transition, which is imho a good idea.

    Craig: >>>
    it's time for us to start migrating to the standards, which gives us the time to focus on extending Struts in other directions in the future.
    <
    The ingegration is providing an easy path upwards (some might disagree ;-) ), but the package is only working for Struts 1.1. So what is going to happen to struts 1.0 apps?
  13. From the frying pan into the fire...[ Go to top ]

    This is really a joke. If you have two inadequate frameworks, hey, why not integrate them. I always found that
    struts is so trivial (but with very good marketing and branding) that it is almost worthless. The tag libraries are more of a burden than a relieve actually. And about JSF: There has been much said about it in prior threads.
    You can find my opionion at http://www.iternum.com/developer/ui/faces.jsp
    Sigh! Really Craig should concentrate on making JSF a relevant framework and not worry about marrying it with some legacy apps - or we will find ourselves coding .NET rather sooner than later.
  14. From the frying pan into the fire...[ Go to top ]

    struts is really a joke on top of another joke .. more precise: a thin wrapper of a joke. Does anybody out there really believe, state machines are state of the art? Working with struts feels like programming in basic without using functions and local variables.

    MVC in struts is another joke. For what do I need to separate model and view, if the outcome is a model that feels like a bag of workarounds for all the struts inabilities and bugs?

    Holger

  15. From the frying pan into the fire...[ Go to top ]

    Struts is a wonderful framework for me. It's save me time and a clean way of coding web apps. In fact, Struts apps is much better then the jsp alone. Also, if you architect the right way then Struts and Asp.Net are very similar. Struts has alot of functionalities but Asp.Net is more productive if you using the Studio.NET. Any of you out there using Eclipse to debug Struts please let me know.

    Think people who criticized Struts because they don't know Struts at all.
  16. Holger, I agree with you: IMHO Struts is far too complex for its rather small benefits. I do not consider it superior to a custom controller servlet approach, optionally combined with JSTL as tag library. The well-defined struts-config.xml might be well-suited for tool support. But basically, writing a Struts action is as much work as writing a custom controller servlet, and mapping each action in struts-config as much as work as mapping each controller servlet in web.xml.

    You can easily handle form beans without Struts ActionForms. You can use Jakarta Commons BeanUtils for populating your beans. And you are free to use any existing bean without the need to derive from ActionForm, you can even use more than one bean per form if you want. The only drawback that I can see is that you have to code the form including form bean getters yourself instead of using Struts tags, but that is not too hard using JSTL and its expression language and even easier with direct EL support in JSP 2.0.

    ActionForward definitions can be replaced by init parameters for the forward URLs of your custom controller servlet. Global forwards, if you need them, can be put into context parameters. For convenience, a controller servlet super class with an abstract "performAction(HttpServletRequest)" method that returns the chosen forward URL is just a few lines of code. Every "action" is a subclass of the controller servlet that overrides "performAction" and gets mapped via a standard servlet mapping.

    IMHO Struts contains numerous definitions and helper classes that don't make sense in a Servlet 2.3 + JNDI resources + JSTL environment, like DataSource support (use your container's JNDI instead) or the application resource bundle (use JSTL i18n instead). Why bother with all this stuff if you can also use custom controller servlets with just a single base class to care about? And this simple approach does not limit model and action implementation in any way, in contrast to Struts with its restrictive form beans.

    A word about WebWork as an alternative to Struts: My basic arguments still apply, although its API is simpler. WebWork's action concept is noticeably different to Struts': Its actions are both "form beans" and "actions" in the same class, and they are not bound to servlet environments. The latter makes WebWork still too elaborate for my taste, as I prefer to achieve reusability by delegation to dedicated business logic classes in my web actions. Finally, WebWork's EL is nice but superseded by JSTL's (and JSP 2.0's) EL.

    All things considered, I currently choose neither Struts nor WebWork but the Keep It Simple and Stupid approach, and possibly JSTL. I guess JSF won't change that, as it does not seem to provide enough benefits that are worth the extra complexity.

    Juergen
  17. Just remember that Struts is from a time when there was no JSTL, and all the flow between pages was hardcoded into the JSP page. You may think there's no reason to use it anymore, since most of its features were integrated in the standard package (and even more with JSF), but there's still much legacy code and much developers trained, and a path of transition sure is needed.
  18. Hi

    I really love Java and J2EE as well.

    I am the manager of the software development department of a large savings bank.
    Two years ago we've decided to migrate everything to J2EE, one year ago every web application to STRUTS.

    Since this time I have the impression I'm always running behind the current specifications...and implementations.

    J2EE 1.1 , 1.2 , 1.3...EJB 1.0 1.1 2.0 and now you guys are telling me Struts is out of date...and JSF is the thing I should use ?

    At the moment I'm training a lot of developers in STRUTS and now..!?

    Guys the big advantage of MS$ is you don't have to learn every month a new technology or specification...

    Oliver

    Oliver.Lauer@sk-koeln.de
  19. From the frying pan into the fire...[ Go to top ]

    <quote>
    Guys the big advantage of MS$ is you don't have to learn every month a new technology or specification... </quote>

    I totally disagree with this. As with anything else, learning and improvement are part of the evolutionary process. Probably you still have tapes at home, although meanwhile people use CDs, MDs, MP3s etc...Microsoft is no exception, on the contrary. For example, Visual Studio 6 came with Visual Interdev which had some built-in "controls" gnerating a spaghetti of VB and JavaScript...It took them 1 year to suggest that it's not a good idea to use it and projects should convert to "manual" MTS-aware components if they want to achieve scalability. Then the entire thing with the DNA architecture came out, and by the time they finished popularizing it's concepts, the droped it all together because .Net was the next focus.

    Yes, as people are still doing VB6 projects today, in the same way you can still develop your Struts-based framework for your needs and migrate only as it makes sense. And in terms of people skills, you cannot learn programming as a cook-book and then repeat the same tasks over and over again. If they learnt Struts, they know for sure its pluses and minuses, and will be more than happy to learn a technology which is similar but fills in these gaps.
  20. From the frying pan into the fire...[ Go to top ]

    <quote>
    J2EE 1.1 , 1.2 , 1.3...EJB 1.0 1.1 2.0 and now you guys are telling me Struts is out of date...
    </quote>
    Oliver,
    Ignore the struts bashers out there. For all it's faults it still is the most widely used and popular framework out there. It still is the best way to acheive a high level of productivity under the JSP/Servlet environment.
    I agree with your statement about MS products. MS products let the developer acheive a high level of productivity. True, they may not be technically elegant but at least they get the job done quickly.
    I wouldn't worry about keeping up with the specifications or struts going out of date very soon. At the glacial pace that the Java Community Process moves it will be at least a year before anything worthwile comes out of JavaServer Faces.
    Regards
    Ravi
    PS Before I get flamed for saying something good about MS, I want people to know I am a java developer. MS does some things well and the Java world will be better if we learn from them.
  21. Hmm... I guess you didn't live through the days of Com, Com+ Ole Servers, Active X etc. All the same technology branded differently seemingly every month, but causing tremendous confusion. If you think Java/J2EE is tough, try getting a handle on .NET

    -Shon
  22. From the frying pan into the fire...[ Go to top ]

    I'm not sure where to begin so I will keep it simple.

    I personally find your solution less desirable and less elegant, especially the larger and more complex the web app gets. And I can't understand why you think Struts isn't simple. Its simplicity is one of the very things that makes it attractive. I also like Struts additions like Validator and Tiles, both of which are very useful.

    I respectfully disagree with your assertion that writing a Struts action is as much work as writing a custom controller servlet. Are you kidding? This and other things you mention can be done in the blink of an eye, especially with today's Struts tools.

    Struts will migrate to the use of JSTL and will play nicely with JSF. Have you seen the recent EL tag contribution to Struts? But then again, Struts can play well with just about any tag library (or web UI). Just as an example, we developed a tag library that provides multi-device support for Struts with no trouble at all.

    For those of you using Struts or investing in its use, I wouldn't worry about it going away any time soon. I also wouldn't worry about it becoming obsolete. It will continue to incorporate the latest technologies and provide a simple, standard framework that saves you time and money without busting your existing apps. Couple this with its large user community and tool support, and I think it is a great choice.

    That being said, there are other quality frameworks out there that are also good choices (WebWork being one of them). This choice is a very good thing IMHO.
  23. From the frying pan into the fire...[ Go to top ]

    <quote>
    I respectfully disagree with your assertion that writing a Struts action is as much work as writing a custom controller servlet. Are you kidding? This and other things you mention can be done in the blink of an eye, especially with today's Struts tools.
    </quote>

    IMHO you are actually overestimating the effort of writing a custom controller servlet (or a custom controller JSP, containing just logic and no markup) and associated views. Especially given the patterns I have outlined, using a thin base class and Jakarta Commons BeanUtils.

    I have led web development teams working on complex Java-based application for more than 2 years, at 2 companies. The KISS approach works nicely and is more maintainable than you might think. There is a need for a lead developer that cares about patterns and code quality, though, but there should be one in a serious dev team anyway.

    Many people just use Struts for form handling and bean population, completely without tools because they want to focus on code. For them, the KISS approach would be much simpler as there would just be the controller base class and one single method of BeanUtils to care about, beyond the basic Servlet, JSP, and possibly JSTL specs.

    Now there's the similarity to EJB's usage patterns: Many developers really don't need any particular EJB features, thus business logic in plain Java classes accessing JNDI resources and JTA UserTransactions would be more appropriate.

    Struts may be simple, but IMHO not simple enough for average applications as I don't even see a need for a full-blown framework here. On the other hand, I do appreciate the choice: Struts and WebWork are fine, it's just that the need for them is overrated. So I think there's nothing wrong, neither with choosing them nor with sticking to the KISS approach. Choose whatever suits your needs and your personal taste.
  24. From the frying pan into the fire...[ Go to top ]

    i really seem to miss your point with struts: Struts really is exactly what you describe - glueing together a set of standards to fill in some gaps intentionally left blank by the specs. Of course you can do this without struts - but, as you pointed out, you usually end up with the same functionality (base-classes, forwards being coded in servlet.xml instead of struts-config.xml, parameters you have to agree upon, a custom tag-library for repeating tasks) - so maybe it makes more sense to talk about struts as a rather good instantion of a "pattern" of the model2-approach. If you implement this pattern by yourself, you usually end up with something in the line of struts - and you usually end up with missing some nice little features (automated repopulation of forms, validation with regex, sub-apps, even some rudimentary tool-support) that of course can be achieved in many other ways, but let's face it: In the end you have to do it anyway, so why not use struts, it just helps you to be *a little* faster.

    I'm now in the third project, where we started without struts for various dubious reasons and everytime we ended up with developing some private, little model2-Framework: In the end they look more and less the same with only subtle differences...
  25. From the frying pan into the fire...[ Go to top ]

    I actually tend to agree with you when developing very simple web applications (doesn't include what I think of as normal apps). But in my experience (and humble opinion), teams often end up moving beyond simple web applications. And let's not forget changing requirements. Once this happens, your approach will begin to break down. What you will then end up doing is creating something like Struts or one of the other frameworks, with the exception of little documentation and developer support.

    So unless you are doing something *really* simple, why reinvent the wheel? I don't buy the argument that Struts is overkill, because what little overhead you have with it will pay off easily. And for those frameworks that are more complicated, investing just a little time up front to gain scalability, reusability, etc. could really save your bacon one day.

    That is my opinion of course, but it is based on a lot of experience with both experienced and unexperienced teams. I certainly respect yours as well, so I guess we will just have to agree to disagree. :-)
  26. <quote>
    IMHO <snip/> <insert>blah, blah, blah</insert>
    </quote>

    Are you saying that you write a custom controller servlet for every application you develop? Isn't that a little redundant redundant?

    I think you're missing (at least) one point about Struts that makes application maintenance easier: the ability to alter the application flow by editing the struts-config.xml file. This makes altering application behavior quite easy without being disruptive.
  27. 1. Custom Servlets vs. Action Classes:
    If you notice that
    a. the Action class perform() method signature includes HttpServletRequest and HttpServletResponse and
    b. The Action classes are instantiated only once and should be designed to be multi-thead-able (like avoiding instance vars)
    The inference is that the Action class is just a variation on the servlet theme. Thus the "amount of effort of coding a custom servlet vs. action" question is moot.

    2. Runtime reflection vs. compile time reflection
    Struts uses runtime reflection to copy CGI vars in the request into the corresponding bean.
    Typical containers usually expand the <usebean: setProperty "*"> tag at compiletime of the JSP and then compile the intermediate .java file, making this more efficient at

    These apart, I find the layer of indirection introduced between physical-resource-names and logical-resource-names very useful.
    IMHO, the very concept of an open framework for Java based web apps is a good one and Craig deserves credit for making such a framework widely available and accepted.

    Regards,
    Bharath.
  28. <quote>
    Are you saying that you write a custom controller servlet for every application you develop? Isn't that a little redundant?
    </quote>

    Actually, no: There's one custom controller servlet (aka action servlet) per Struts action, if you directly compare the approaches. The thin common controller base class is reusable across projects.

    My main point is that writing such an action servlet is not necessarily harder or more elaborate than writing a Struts action. Additionally, you are not restricted in any way: You can instantiate and populate any number of arbitrary beans (via Jakarta Commons BeanUtils one line method calls), do any type of validation (not hard to implement in Java without explicit tools) and put any number of custom error messages in the request or session.

    Filling the forms in the view and showing the error messages is not hard either, not even with plain JSP but especially not with JSTL. IMHO you don't need a dedicated tag library for that, and error messages often need special handling that a standard errors tag is not capable of.

    <quote>
    I think you're missing (at least) one point about Struts that makes application maintenance easier: the ability to alter the application flow by editing the struts-config.xml file. This makes altering application behavior quite easy without being disruptive.
    </quote>

    I'm not sure how often it is possible to change the application flow just in the deployment descriptor. Normally, you will write a new action or change an action, so there's code change involved anyway. IMHO the power of declarative approaches exists but it is overrated.

    Anyway, as I have already stated in a previous post, it's easy to use declarative forward URLs with the KISS approach too: Define standard servlet init parameters, or context parameters for global URLs, and use them in your action implementations instead of hard-coded URLs.

    All things considered, I consider MVC a pattern. There are many valid ways to implement that pattern for web applications, including Struts and WebWork. And we will see what JSF will deliver in the end.

    I just want to demonstrate that you can implement clean MVC including declarative options with basic guidelines and very simple tools: standard servlet mechanisms, 1(!) very thin common base class, and possibly JSTL. No-frills and code-oriented, but I consider that a plus. If you want RAD tool support, you have to look elsewhere: a Struts/JSF combo, possibly?

    BTW, thanks for the feedback to everyone! I enjoy lively discussions :-)

    Regards,
    Juergen
  29. From the frying pan into the fire...[ Go to top ]

    First, statement of bias: I like Struts, it's the embodiment of KISS. However I have nothing against the creation of a custom MVC approach so long as it's designed by engineers that understand the implications and risk involved in going your own way. Going your own way often means "messy", but it depends on the team leads and schedule pressure.

    Now, Juergen says:

    "Normally, you will write a new action or change an action, so there's code change involved anyway. IMHO the power of declarative approaches exists but it is overrated."

    With things like EJB, I agree. With struts, no.

    For example, I found it to be a relatively minor exercise to create generic "object editor" actions to handle the CRUD operations involved with any object graph. It also was simple to create a generic "object list" pagination engine. This is particularly useful in record or document-oriented information systems, such as book keeping, job orders, material management, inventory, e-commerce, etc., and allows developers to focus on the tougher nuts to crack instead of basic patterns.

    After creating the generic actions, all that would be required would be a custom JSP for a particular object graph and an editing of struts-config. Those who are into runtime-UI generation (overkill I think, but not always) could even eliminate the custom JSP page.

    With regards to Karl and Holger:

    Struts is so trivial as to be worthless? I will suggest it's simple and consise. Is that a negative thing, as you suggest? Holger, would you please enumerate what bugs in Struts 1.0 you are referring to?

    I'd like to learn why you feel programming in Struts is so primitive, and why (for example) state machines are somehow an inferior model of abstraction for screen flow. Is it that you're looking for rich workflow? Is there an alternative framework (in or outside of Java) you could point me to that offers this to your satisfaction? For example, Biztalk, MQ Workflow, etc. are these better? How?

    Or if you're referring to a custom framework, could you briefly enumerate some of the concerns that you've dealt with in these frameworks?
  30. From the frying pan into the fire...[ Go to top ]

    Stu,

    I agree that Struts is simple and concise - in much the same way if-then-else is simple and concise as well.
    I did not run into many bugs but then again it is so simple (or primitive) that you would not expect a lot of
    bugs. At the current point - as pointed out earlier in this dicussion - I think - struts addresses a problem that no longer really exists.

    Also, Struts does not defines the things you really end up looking for when developing, one of the main things is that it does not provide any really usable event model, does not support form handling very well and does not look very good in rapid prototyping. You may argue - and you are right - that it is not what it is intended for, but it is IMHO one the biggest issues in server side java development at the moment, especially if you look at the state of .NET development.

    The basic problem with state machines on the web is, well, that HTTP is a stateless protocol. There are strategies to deal with it *and* get an excellent frontend/MVC model, but I have to come across many and I have not yet seen any in a full blown product or API.

    The ability to provide something like this for Java server side development is probably vital. We are trying to do something along that line at the moment (http://www.iternum.com/i3test).

    As for struts, of course it does at least one good thing: It gives development at some methodology as well as provides some structure for the software that is created,
    while it is relatively small and easy to understand.
    For a lot of projects this still is a big step forward.
    However one might very well argue that this indicates more of a unsatisfactory state of software development (and developers) as a whole.
  31. I agree- Struts does not help[ Go to top ]

    From my experience with delivering a struts application, it does not help in development time or maintainability. We would have been better off sticking to the core MVC 2 architecture of Sun. This is standard, will be supported in the comming years and is much more maintainable. It puts more emphasis on good design practice as you are freer to do stupid stuff. But I would argue that if you hav been let loose on this kinda coding you should have a good feel of what is sensible.
  32. "And about JSF: There has been much said about it in prior threads. You can find my opionion at http://www.iternum.com/developer/ui/faces.jsp " -- Karl

    That's the most lucid critique of JSF I've read. The web page makes several insightful gripes, but the two I find most damning are:

    1) "One of the biggest drawbacks of the JSF specification is that it does not seem to provide support for wiring pages together in a declarative way, preferably within the JSP page itself. It also lacks the ability to create simple workflows let alone stack them together."

    That's a gaping hole. One of the requirements of the design project for Sun's J2EE Architect certification is to produce behavioral diagrams of a web application's inter-related use cases. Fine, but if a web framework (such as JSF) lends little or no support for use cases, then the implementation exercise of elaborating code from design is unstructured -- too tedious, error prone, and lacking in readability and maintainability -- rather like assembly coding.

    2) "For example, the [proprietary] event driven model makes it very easy to nest forms within a page inside other forms and allow to submit or to update the full dataset or just a subset of the data while retaining the full input of the user. This will not work with the current JSF specification since by definition all component validations must be successful for an update to occur."