Discussions

News: Article: Struts 1.1: Should I Upgrade?

  1. Article: Struts 1.1: Should I Upgrade? (20 messages)

    A new article on upgrading to Struts 1.1, by John Yu, has been posted on TheServerSide. This article describes the new features found in Apache Struts 1.1 beta and the impact of migration from Struts 1.0 to Struts 1.1. It also offers advice on the migration decision and the upgrade process.

    Read "Struts 1.1: Should I Upgrade?"

    Threaded Messages (20)

  2. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    my vote is yes. 1.1 seems pretty stable to me. using all the time now.
  3. This stuff sounds really interesting. I'm wondering how it will integrate with the Java Server Faces initiative. 1.1 will make it hard to argue with the previous sharing of Strut's xml file, with the new subapplications structure.

    The subapplications concept is very similar to BEA WebFlow's concept of namespaces. Validator objects, etc. The Dynamic FormBeans is pretty cool too.

    Thanks,
    Steve
  4. Don't forget the declarative error handling. Pretty useful, and quite customizable if you ever want to provide your own error handler.

    Laurent
  5. Sounds good, i will start with 1.1 now
  6. For anyone using Expresso Framework and as
    an article writer myself on TheServerSide.com

    Struts 1.0.2 is the MVC inside Expresso Framework 4.0
    at the mo. Me [Peter Pilgrim] and Michael Rimov are
    going to look at upgrading to a Struts 1.1 beta 2 or later
    when we have branched the Expresso Framework CVS
    between 4.1 and 4.2.

    I think a lot of the changes will be moving the code
    ExpressoActionServlet.java into a
    ExpressoRequestProcessor.java making our
    custom action servlet smaller. We also might have to
    look at the TilesRequestProcessor as well since
    I used Tiles myself before.

    As the article "Best Practice with Expresso Framework"
    not all a lot changes with Struts 1.1 but we have to
    see what surprises the upgrade spring on us.

    That's all folks!

    Peter Pilgrim

    www.xenonsoft.demon.co.uk/whatsnew.html

  7. I was wondering about "Multiple Sub-applications" stuff in Struts 1.1. Is the main reason to use that feature to split one big struts-config.xml into multiple little ones? In our company we have used XDoclet in our projects and it seems to do the similar thing - there's no actual struts-config.xml file to maintain since all tags are located in the source files (our Ant-script auto-generates the actual xml file). Has anybody else done this with success?
  8. Mmmm, not sure this is a good idea. Having your configuration file split into several pieces among different classes might turn the configuration of the framework into a nightmare. IMHO one good point of this type of framework is precisely to have one main configuration file where all the components are wired together, so that the whole thing remains flexible. Having to dive back into the code whenever the configuration has to be changed looks pretty embarassing to me. Maybe I'm wrong and the xdoclet tags you are using are quite customizable ? Let me know !

    Laurent
  9. We also use XDoclet for generating struts-config.xml. I think this is great, since this is a file you update quite frequently. With multiple developers you never need to worry about who's got struts-config.xml checked out. All information about your action is right there in the piece of code you're working on.. It's also alot easier to just write a line of javadoc code than 5 lines in some XML file.
  10. A Matter of Preference[ Go to top ]

    This is really a matter of preference.

    We don't worry about who has the config files checked out, because we develop with small teams and merge changes. Merging is almost always unnecessary, though, because we can now split the application into multiple configuration files based on function. Pretty cool.

    As for messing with XML, who does that anymore? There are a number of good Struts tools already available (some of them two-way in nature), and they do an excellent job of managing and validating these files (as well as components and accessory files) for you. We also like the fact that we don't have to even touch the classes for some changes that we make. That is, after all, one of the benefits of splitting this information into config files.

    Multiple config files is just one of the welcome features. We have also found 1.1b2 to be pretty stable.

    Ah, look at that! Another security update for Windows. I guess I should go install it. Bye bye...
  11. A Matter of Preference[ Go to top ]

    Yes, it may be easier to use some tool to do the config-file editing. Actually the main reason we are using the XDoclet for Struts stuff is because we use it also for EJB generating. What tool are you using, Struts Console? What are the good and bad features of it?
  12. A Matter of Preference[ Go to top ]

    Actually, we have a tool called ObjectAssembler that does this and more. I would be interested in your opinion of it if you get a chance to try it out.

    ObjectAssembler

    You will also find a number of other Struts tools with varying levels of support on the Struts site.

    We are considering supporting XDoclet as an alternative for components, because it has become very popular recently. So when creating an EJB, as an example, you would choose traditional or XDoclet. Our assembly workspace would then manage the component differently depending on your choice. Obviously, we would also need tighter Ant integration for this as well. That way, you have a choice based on your preference.

    Anyway, your opinions in this matter are very welcome!
  13. Hi Janne,
    Could you help me in generating struts-config.xml for struts action and form classes using XDoclet.
    I tried with samples of xdoclet but unable to see form-bean tags in the strus-config.xml.
    Could you send me some samples which will clarify my doughts.

    Please help me in this regard.

    Thanks & Regards,

    V.K.Kasturi.
    email:-venkatak@tanning.com
  14. I was wondering about "Multiple Sub-applications" stuff in Struts 1.1. Is the main reason to use that feature to split one big struts-config.xml into multiple little ones? In our company we have used XDoclet in our projects and it seems to do the similar thing - there's no actual struts-config.xml file to maintain since all tags are located in the source files (our Ant-script auto-generates the actual xml file). Has anybody else done this with success?




    hi ,

    I need to implement the same concept in my project. can any body give one sample application
  15. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    Has anyone tried this with WebSphere 4.0?
  16. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    Yeah, I've been testing Struts 1.1b2 with Websphere 4.03 and it works fine.
    Any precise fears ?

    Laurent
  17. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    I'm the author of the article. I'd like to answer a couple of questions raised in the discussion:

    1. Struts & JSF (JSR-127):

    The Struts community is well represented on the standard. Craig McClanahan, JSF's Spec Lead, is also one of the primary designers of Struts. AFAIK, JSF's Expert Group has paid extra attention on interoperability with Struts. Based on the draft spec, I'd believe the integration is very doable. The dust will probably be settled more in a couple months once JSF is finalized.

    2. Multiple subapps and XDoclet

    I haven't used XDoclet extensively myself. My understanding is using XDoclet is a compile-time approach while using multiple subapps is a runtime approach. Both are valid techniques. As Bill put it, it's a matter of perference.

    3. Struts tools

    As for Struts tools, you may want to take a look at Camino, my company's visual modelling tool for Struts.
  18. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    I've used 1.02., 1.1b1, 1.1b2, and some of the nightly release builds. 1.1b1 seems to work fine in my app with Tomcat 4.0.4, but I've had troubles using it with WL6.1. 1.1b2 seems to work fine on WL6.1, but the logic:iterate indexing feature is broken in that release.
    However, I've discovered that everything seems works fine for me in the nightly build dated 9/3.
    In any case, 1.1 is definitely a major improvement.

    -Carl
    www.xfi.com
  19. I gave a Struts 1.1 presentation at the Atlanta Java Users Group (AJUG) this month. Although I didn't explicitly cover upgrading, I did talk about the 1.1 features in some detail. You can download the presentation here:

    http://www.ajug.org/meetings/download/struts.pdf

    Chuck Cavaness
  20. Article: Struts 1.1: Should I Upgrade?[ Go to top ]

    One important new Struts feature that John doesn't mention in the article is the "struts-nested" tag library. It enables recursion in JSPs while still conforming to the Model 2 architecture.

    Let's say you want to dynamically build and present and tree structure on your page. Without the "struts-nested" tag library, you had to either embed Java code in your JSP or put HTML in your Java action or a custom tag. With the "struts-nested" tag library that comes with Struts 1.1b2, you recursively use JSPs to do the job.

    See <http://www.keyboardmonkey.com/next/Primer_partOne.jsp?content=yesplease> for an example. Unfortunately, the current Struts documentation on the "struts-nested" tag library is not very helpful.
  21. DispatchAction upgraded[ Go to top ]

    In case you didn't know...

    The article warns that DispatchAction had not yet been upgraded from perform() -> execute() and that a bug had been logged in the Struts bug database.

    The current Struts JavaDoc indicates that execute() has been added to DispatchAction, as of 9/22/2002.