To raise and fix issues, you can post tickets to Bugzilla. This is where patches should go, so they don't get lost. If you have an alternate patch, you can append that to the same ticket.
If you strongly believe in an issue, you might have to lobby for it. This is often the case in open source. On another project, I had to make several followups over a two-week period before getting a three line patch committed. It's just the way things work on volunteer projects.
Bugzilla, the DEV list, and CVS are the only media that the committers use to develop Struts. Both Bugzilla and CVS are programmed to post changes to the DEV list, so everything that happens is reflected here.
See also
http://jakarta.apache.org/struts/using.html
http://jakarta.apache.org/site/getinvolved.html
http://jakarta.apache.org/struts/faqs/helping.html
-Ted.
Richard Tomlinson wrote:
Hi,
I've got a number of issues that I'd like to raise regarding feature requests with suggested fixes. Can someone inform me of the best way to go about this? I'd like to know what the process is to suggesting, raising and fixing features and problems so that they can be destined for the next release.
I'd like to initially tackle the following issues:
o html:errors tag - Add the ability to specify the maximum number of errors to display rather than displaying all available errors.
o html:link - Improve the way it handles multi-module support. My previous message regading module support was unanswered.
o Adding ActionMessages/ActionErrors from a specified resource bundle - I saw a patch for this that unfortunately didnt address the issue correctly (Bug 7892)
o The addition of a ReloadableActionServlet to be used for development purposes. I take note of the comments seen before regarding reloading and sync'ing requests so it would be useful for ONLY development purposes. The gain in productivity is substantial when its possible to reload without restarting the container and a reloadable ActionServlet should be included in the distribution. From a simple implementation it appears that there are clean-up problems needing to be addressed with the tiles factory and request processors being left in invalid states but still present in the ServletContext. I'm also interested in support of real-time changes to modules without re-loading config to facilitate the use of CMS products in a large production environment.
Comments please.
Regards Richard Tomlinson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
