[Apache Struts Group] The Apache Struts group is pleased to announce that Struts 2.0.8 is available as a “General Availability” release. This release has over 60 bug fixes and improvements since 2.0.6! New Features include:

• Cookie Interceptor - Inject cookie with a certain configurable name / value into action.
• Restful2ActionMapper - Allow automatic id setting from Restful2ActionMapper.
  [MORE]
  Kudos to my confrere Rainer Hermanns for cranking out this release!

My friend and fellow Struts Committer Ian Roughly has brought out the first Struts 2 book, which is available both as a PDF and as a conventional printed book. Kudos, Ian, kudos!

“Starting with Struts2“ is aimed at those who are new to Strut2, and those familiar with MVC frameworks but unfamiliar with Struts2. It provides everything you need to know to get up and running using Struts2, and can be used as a starting point to explore the more intricate features of the Struts2 framework. Topics include architecture and configuration, how to implementing actions, and supporting infrastructure such as validation and internationalization. Also included are productivity tips, providing a practical introduction on how best to use the framework.

Right now, I’m working against a hard June 30 deadline, but I made time to at least skim the PDF. The book looks great. At 122 pages, it’s a small book that doesn’t try to replicate the online Struts 2 documentation. Instead, the book is a perfect complement to the Struts 2 website. It fills in the gaps and should make it much easier for web developers to “hit the ground running” with Struts 2.

You can bet that I’ll be ordering a printed copy to add to my collection of Struts books. It’s an incomplete collection: I only have twelve. But I’m very glad to make Ian’s book lucky #13.

In other Struts 2 news, my compadre Don Brown is busily preparing a release of Struts 2.0.8. The beat goes on …

Sofware engineer might be the best job in America, but when you tally them up, most web application developers still need to use, on a regular basis, a stunning array of technologies.

1. Desktop operating system
2. Telnet or Remote Desktop
3. Server operating system
4. Email
5. Web Browser
6. Internet Relay Chat or Instant Messenger
7. An IDE (Eclipse, Visual Studio, Aptana) or programmers editor
8. Image editor
9. HTML
10. CSS
11. JavaScript
12. DOM
13. HTTP
14. HTTPS
15. XHR (XMLHttpRequest)
16. Cookies
17. POP / SMTP
18. High-level language (Java, C#, Ruby, …)
19. XML
20. Unit testing framework (xUnit, TestNG)
21. SQL
22. DBMS (MySQL, SQL Server)
23. Data access framework (Hibernate, iBATIS)
24. Web server
25. Web container
26. Web services (SOAP, JSON RPC)
27. Server pages (JSP, ASP, PHP)
28. Page testing framework (Selenium, Mercury, WebCanoo)
29. Ajax Library (Dojo, YUI)
30. Web framework (Struts, ASP.NET, Rails)
31. Repository (SVN, CVS)
32. Wiki
33. Issue Tracker
34. Office sofware (Word, Excel, PowerPoint)
    And that’s not even counting readng, ‘riting, and ‘rithmetic!

Agile programming in India writes:

_

“I hear alot about open source, everything is open source, how people write code on mailing list and Apache and all that… but I ask dear reader, how do they manage to fix BUGS? When many people write code it is hard and you need a methodology, but open source tell us that we don’t need methodology, any person can change code? How does this work? I know, they are good, but no methdology? Open source needs a plan. A new plan. It is not agile enough. you want to insert problems in my code, boy?! Go, join open source mailing list! NO good.”

_
Most people who work on open source projects are professional programmers who use the products at work. The individuals in the Apache HTTPD group contribute to the web server because they each use the server at work. The same goes for most any open source project.

Very few open source projects let any one change the code, in the way that Wikipedia lets any one change an entry. (And even Wikipedia is locking some entries down now.) Anyone can submit a patch, but an established “committer” has to decide whether to apply the patch.

How do you get to be a committer? Easy: Act lke a committer. File tickets, submit patches, and post to the mailing list. (But most of all, submit patches!) Once the group sees that a developer knows what he or she is doing, usually, someone in the group will offer write access. But you have to prove yourself first.

As to methodology, most projects use tools like mailing lists, commit logs, issue trackers, and wikis to discuss the code and apprise everyone of every change we make. For more about open source infrastructure, see The Open Source Secret Sauce

The framework defines several constants that are used to identify common result use cases, such as, ERROR, INPUT, FAILURE, LOGIN. NONE, and SUCCESS.

When an application has common result cases of its own, such HELP, MENU, or CANCEL, the application should define additional constants to represent various result types.

The use of constants reduces programming errors, increases cohesion, and also documents an application’s common result types.