cvs commit: jakarta-struts/doc acquiring.xml announce.xml download.xml
martinc 2004/09/19 23:28:44 Modified:doc acquiring.xml announce.xml download.xml Log: Final site updates for 1.2.4. Revision ChangesPath 1.25 +15 -37jakarta-struts/doc/acquiring.xml Index: acquiring.xml === RCS file: /home/cvs/jakarta-struts/doc/acquiring.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- acquiring.xml 12 Sep 2004 06:22:29 - 1.24 +++ acquiring.xml 20 Sep 2004 06:28:43 - 1.25 @@ -24,27 +24,13 @@ development builds. All downloads are available to the general public at no charge and are distributed under the a href=http://apache.org/licenses/;Apache License/a. /p - -p -Apache downloads are now mirrored. -When you follow either the Binary or Source link, -please select your preferred mirror and then click on the link -to the strongStruts/strong download. -/p - -a name=Releases/aul - -li -!-- +ul + li a href=http://struts.apache.org/download.cgi; -strongStruts Binary and Source Code Distributions - Struts 1.2.2 is the best available version/strong/a --- -strongStruts General Availability Release - Jakarta Struts 1.1 is the best -available version/strong - [a href=http://jakarta.apache.org/site/binindex.cgi;BINARY/a] - [a href=http://jakarta.apache.org/site/sourceindex.cgi;FULL SOURCE/a] -/li - + strongStruts Binary and Source Code Distributions - Struts 1.2.4 is the best available version/strong +/a + /li /ul - p strongIn addition to a Struts distribution,/strong you will need to ensure that you have downloaded and installed all of the @@ -61,28 +47,20 @@ /section section name=Development Builds href=Milestones + +p +The latest emdevelopment build/em of Struts is available in a convenient +binary distribution and also with complete source code. +/p p -The latest emdevelopment build/em of Struts is -available in a convenient binary distribution and also with complete -source code. +Development builds are being reviewed for quality by the Struts community. +When a build is judged ready for prime time, it is promoted to General +Availability status and may be made the Best Available release. /p p -Development builds are being reviewed for quality by the Struts community. -When a build is judged ready for prime time, it is promoted to -General Availability status and may be made the Best Available release. +With the recent promotion of Struts 1.2.4 to General Availability, there +are no more recent development builds at this time. /p -ul -li -a href=http://cvs.apache.org/dist/struts/v1.2.4;Struts Development -Builds - Not rated General Availability - Struts 1.2.4 (Alpha) -is the most recent./a -/li -li -a href=http://cvs.apache.org/repository/struts/jars;Struts Development -Repository (Maven) - Not rated General Availability - Struts -1.2.4 (Alpha) is the most recent./a -/li -/ul /section 1.4 +21 -4 jakarta-struts/doc/announce.xml Index: announce.xml === RCS file: /home/cvs/jakarta-struts/doc/announce.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- announce.xml 31 Aug 2004 17:23:09 - 1.3 +++ announce.xml 20 Sep 2004 06:28:43 - 1.4 @@ -3,7 +3,7 @@ properties author email=[EMAIL PROTECTED]Ted Husted/author -author email=[EMAIL PROTECTED]Martin Cooper/author +author email=[EMAIL PROTECTED]Martin Cooper/author titleAnnouncements/title /properties @@ -11,9 +11,26 @@ section name=Announcements -h4 id=a2004083131 Augusy 2004- Struts 1.2.2 (General Availability)/h4 +h4 id=a2004091919 Sep 2003 - Struts 1.2.4 (General Availability)/h4 p -The Apache Struts team is proud to announce the next release of Struts 1.1. +The Struts team is pleased to announce the release of Struts 1.2.4 for +General Availability. This release includes significant new +functionality, as well as numerous fixes for bugs which were reported +against the previous release, and supersedes the earlier 1.1 version +as the latest official release of Struts from The Apache Software +Foundation. +/p +p +The binary, source and library
Re: [Apache Struts Wiki] Updated: JavaBeans
[EMAIL PROTECTED] wrote: Date: 2004-09-19T22:25:41 Editor: MartinCooper [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: JavaBeans URL: http://wiki.apache.org/struts-admin/JavaBeans no comment Change Log: What is wiki.apache.org/struts-admin/ ? Is there a place where issues, like JavaBeans, are discussed that have only privileged access? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com I don't really like your approach and don't want to see such an Action added to a Framework like Struts. Here's a few comments why: A big part of the reason I posted this was to see if this was something people thought should be included, so I very much welcome your opinion and thank you for it. * Struts is database-independent. People don't necessarily use plain JDBC. Fair point, but that was the reason I wrote it to work from a database as well as the file system. While the production app I use this in does work from a database, that's obviously not always the way it's done in every case. In addition, although I didn't put this in the comments, but I speficially broke out the getDBConnection() method so that a developer could override it to handle whatever method of DB access they use. True enough, that doesn't remove the JDBC code from the rest of the Action. * You are getting anything you need for accessing your DB from the request, including SQL, username, password, i. e. it would probably have to be included plain text in some JSP. Bad thing... Yes, true, but as my comments stated, I did it this way because I couldn't do it the way I wanted on my own, which is to have most, if not all, of the parameters as attributes of the action tag. I'd still like to keep the ability to use what comes with the request because then you could do things like have a single ImageServerAction that just accepts the query portion with the request with the rest coming from the Action mapping for instance, you could do: img src=/myapp/ImageServerAction.ma?clientid=123 That way, maybe the user can select a client to work with, just insert the ID in the JSP code and your all set with a dynamic logo maybe (this example is exactly what I do in my production app). * I don't like JDBC in Actions. What about separating controller from business logic and database access? I agree in general 100%. However, I wouldn't consider something like this to be business logic per se, and therefore JDBC in the Action is less offensive to me than it otherwise would be. * Your approach is not very flexible. You may not always want to read the data completely into memory before writing it to the response. Yep, someone else pointed this out to me. I hadn't considered that. If for no other reason than performance and server resource utilization, I need to refactor the code to stream the BLOB object. * BTW, it's a good idea to call response.reset() and, if possible, to set the content length before writing to the OutputStream. The content-length was an oversight on my part... My production code DOES do that, but when I re-wrote it to post here I neglected to add that line. My bad, as the young folk say :) Streaming files back to the reponse is really nothing special, and it's not exactly a Struts-specific thing. A simple Booch utitlity class would serve the purpose. I don't argue that. My only point with this was that since this is a common enough activity that many Struts users do, it might be a good candidate for being built-in to Struts, at least to deal with the 95% of cases that it can deal with in a generic way. My response to Craig's comments tie in with this discussion as well, he raises an interesting possibility... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: RFC: BLOBAction]
I agree with Reinhard's reasons that something this specific to particular data access mechanisms might not be appropriate as a part of the core framework. That being said, questions about downloading binary data come up often enough that something like this would make a dandy example application. In that case, maybe I should spend today just using this as the basis for a sample app. I still think that it's a common enough thing that having it built-in to Struts, assuming it's generic enough to handle 95% of the cases that come up, would be a good thing. But I posted this precisely to get opinions on whether people agree with that or not, so if the concensus is that no, it doesn't belong in the core, I'd be just as happy to contribute a sample app (I've had fun using Struts and it has served me well, so anything I cna contribute back would make me happy). Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction and Struts Bloat
There are some things that I certainly agree with michael on and this is one of them. I think ( and i'm not alone in thinking this ) that struts needs a complete overhaul. At present the only reason I use it is because all the existing tooling supports it. eg m7 nitrox, WSAD, MyEclipse etc etc etc If the spring tooling was as mature as this I would use it instead. The project has a reputation for inflexibility, complexity and a lot of unnecessary inheritance. These are all hangovers from EJB with it's multiple interfaces and fixed inheritance approach with the associated difficulties of testing, slow development cycle etc. Struts has done a superb job in the past otherwise it wouldn't be so popular and there is a fantastic pool of talent in the struts development team but it does seem like you are loosing mind-share. If this were not the case there wouldn't be so many copy cat web MVC frameworks springing up. Perhaps it is time for an overhaul of struts. Rather than moving your codebase to subversion perhaps you should leave your 1.* development on CVS and start a completely new attempt for your 2.* series on a fresh server. I do think that struts is a great product and I am a big fan of it's tag libs and the MVC approach in general but I do think that it may be time for a rethink Everything is going POJO, attributes are the way forward. 1.5 will mean that collections are no longer unknown bundles of objects. A lot of people also want AOP features like declaritive behaviour and easier testing. People also want things to be more flexible and have shorter development cycles. I've been a developer for 6 years now. Programmed in about 5 languages and still I find the slowest part of the development cycle is handling the presentation layer with it's multiple reloads etc. I mean i could write a desktop application now with remoting to do the same job quicker than i could write the web interface. That doesn't seem to be the promise offered when people first started developing web applications. And I remember that far back. One thing that I am certainly not suggesting and I want to make this clear is that I am not suggesting that anyone fork the codebase. There is certainly too much clutter surrounding the project at present. It's better if you make it easier to do the difficult stuff rather than vice versa and having everything but the kitchen sink thrown in there doesn't make it any easier. --b approach On Mon, 20 Sep 2004 06:31:24 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Open source and painting are connected in someways. The biggest mistake of the amateur painter is to keep adding colors when the painting is done. The result is always that murky, dark, ugly, look. Likewise, open source, filled with people with egos, sometimes does not know when something is done, finished, damed good and certainly good enough. I have a real concern that Struts is going to continue to be bloated with what are not Struts, not part of the framework, but what are instead really very useful uses of Struts. DispatchAction and its progeny are just one example of this. I would suggest that such offerings would better be managed in a separate application called something like Struts Patterns or Struts Best Practices. Perhaps such classes could be released as classes and either maintained (or preferrably not) independent of Struts? I would hope that by the term bloat I don't convey that such classes are not wonderful ideas and their authors are stellar citizens. It just seems to me that a framework ought to be maintained as a FRAMEWORK and that allowing USES OF THE FRAMEWORK to become part of the framework is a groundwater mistake. Generally, I think it might be better if the actions package were distributed outside Struts proper. As a framework, there comes a time when something like Struts is done, and we need to move on to other things except diligent maintainence and creating clever uses. My present predeliction is to save what presently exists, clean it up by jettisoned what is not needed, and to watch for good ideas that might arise in uses. This is just a thought. There needs to be, I think, a clear separation of Struts patterns or clever uses of Struts and Struts itself. I would suggest that something formal be instituted. Thanks for your ears/eyes on this. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Migrate Struts to Subversion
Who is taking the lead on this? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 20, 2004 12:57 AM Subject: Re: [PROPOSAL] Migrate Struts to Subversion The 1.2.4 build is now GA, so I think we're a Go for the SVN migration. Please let us know when the CVS repo is frozen, so that nobody makes changes after the snapshot is taken. -- Martin Cooper On Fri, 10 Sep 2004 15:38:16 -0400, Don Brown [EMAIL PROTECTED] wrote: Ok, I'll wait until 1.2.3 goes GA. Anything I can do to help? Don Martin Cooper wrote: On Fri, 3 Sep 2004, Don Brown wrote: I propose we migrate our current CVS repository to Subversion as soon as the infrastructure team is available to assist, giving at least a week to ensure all outstanding CVS commits are made. A test Subversion migration has already been created and tested with positive feedback. This proposal does not necessarily require a decision on the future directory organization of the Struts source code as it is very easy to move/add/delete directories with Subversion. The tool cvs2svn - http://cvs2svn.tigris.org/ - will be used to preserve all CVS history, tag, and branch information. +1 on converting to SVN. On the timing, I'd like us to wait for one week after Struts 1.2.3 goes GA (assuming it does), so that we're sure we don't need to quickly roll a 1.2.4. (I know a different SCM shouldn't make any difference, but I'd rather play it safe since we have a bad GA release out there right now.) If all goes smoothly, that would make the switch-over date 9/17. (Vote goes out on 9/7, vote lasts for 3 days, add a 1 week safety margin to make sure 1.2.3 stays GA.) I am willing to be the POC for the migration and handle all communications with the infrastructure team. Cool. You'll probably want to read the instructions that Fitz put together at: http://www.apache.org/dev/cvs2svn.html -- Martin Cooper Subversion: http://subversion.tigris.org Subversion guide for CVS users: http://svnbook.red-bean.com/svnbook/apa.html Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: JavaBeans
Date: 2004-09-20T13:20:02
Editor: KrisSchneider [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: JavaBeans
URL: http://wiki.apache.org/struts/JavaBeans
no comment
Change Log:
--
@@ -1,16 +1,7 @@
##language:en
-== Template for Help Pages ==
-Text.
+#pragma section-numbers off
-=== Example ===
-{{{
-xxx
-}}}
-
-=== Display ===
-xxx
-
-This is test
-
-
-This is test1
+= Official Resources =
+[http://java.sun.com/products/javabeans/index.jsp JavaBeans Home Page][[BR]]
+[http://java.sun.com/products/javabeans/docs/spec.html JavaBeans Specification][[BR]]
+[http://java.sun.com/docs/books/tutorial/javabeans/index.html JavaBeans Trail of the
Java Tutorial]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: JavaBeans
On Mon, 20 Sep 2004 06:00:06 -0700, Michael McGrady [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Date: 2004-09-19T22:25:41 Editor: MartinCooper [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: JavaBeans URL: http://wiki.apache.org/struts-admin/JavaBeans no comment Change Log: What is wiki.apache.org/struts-admin/ ? Is there a place where issues, like JavaBeans, are discussed that have only privileged access? It's simply the path to the page when I'm in wiki admin mode. I deleted that page because it had nothing but garbage on it, and had been that way for quite some time. The message you saw was the result of that deletion. Interestingly, deleting the page seems to have sparked its re-creation with some useful content. Maybe I should try deleting some other pages... ;-) -- Martin Cooper Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[struts-chain] What's up with CatalogConfiguratorPlugin
Why is this class in a directory called 'legacy'? Is there some plan to configure this plugin in another manner? Is there somewhere else I should be looking for code that provides this functionality? TIA, sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31293] - javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31293 javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 21:36 --- Niall, Thx, that worked - my suggestion is to add a not in this respect to http://struts.apache.org/userGuide/configuration.html#resources_config - e.g. something along the line: init-param application must be set in the web-xml, otherwise you'll get javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-chain] What's up with CatalogConfiguratorPlugin
At 5:01 PM -0400 9/20/04, Sean Schofield wrote: Why is this class in a directory called 'legacy'? Is there some plan to configure this plugin in another manner? Is there somewhere else I should be looking for code that provides this functionality? Legacy refers to making the Chain function identically to Struts 1.1 (and looking forward, i'd say probably with 1.2.x). I think that the idea of using a Plugin specifically to configure the chain is legacy because plugins depend on the Servlet API and Chain is trying to minimize dependency on the Servlet API. This is also the justification of the split between the Abstract* commands and the o.a.s.chain.servlet.* commands. I started using Chain after that code was cut, so I could have it wrong. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Bloat: Framework
Looking over Struts 1.2, I see that my ImageButtonBean, an idea discarded for improvements some time ago, made it into the Struts framework. This re-ignites my thoughts placed into another context and which I think are worth putting under a heading which might engender some response. So, here is a last try to get people to address the question. If we continue to put mere uses into the framework, things will get even odder. ImageButtonBean had little testing and was but a germ of an idea. It spread quickly because the problem was pressing to people. But, that does not make it a good solution. In fact, it is a fairly poor solution. Discussions with people on the Struts user list led to definite improvements. In those discussions, people shared some of their ideas which are better than this. ImageTagUtil was a far better solution for that problem in almost every respect. But, now ImageButtonBean is in the framework and will have to be their for sometime. That is not good, in my opinion. Open source and painting are connected in someways. The biggest mistake of the amateur painter is to keep adding colors when the painting is done. The result is always that murky, dark, ugly, look. Likewise, open source, filled with people with egos, sometimes does not know when something is done, finished, damed good and certainly good enough. I have a real concern that Struts is going to continue to be bloated with what are not Struts, not part of the framework, but what are instead really very useful uses of Struts. DispatchAction and its progeny are just one example of this. I would suggest that such offerings would better be managed in a separate application called something like Struts Patterns or Struts Best Practices. Perhaps such classes could be released as classes and either maintained (or preferrably not) independent of Struts? I would hope that by the term bloat I don't convey that such classes are not wonderful ideas and their authors are stellar citizens. It just seems to me that a framework ought to be maintained as a FRAMEWORK and that allowing USES OF THE FRAMEWORK to become part of the framework is a groundwater mistake. Generally, I think it might be better if the actions package were distributed outside Struts proper. As a framework, there comes a time when something like Struts is done, and we need to move on to other things except diligent maintainence and creating clever uses. My present predeliction is to save what presently exists, clean it up by jettisoned what is not needed, and to watch for good ideas that might arise in uses. This is just a thought. There needs to be, I think, a clear separation of Struts patterns or clever uses of Struts and Struts itself. I would suggest that something formal be instituted. Thanks for your ears/eyes on this. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Bloat: Framework
Michael McGrady wrote the following on 9/20/2004 7:52 PM: I have a real concern that Struts is going to continue to be bloated with what are not Struts, not part of the framework, but what are instead really very useful uses of Struts. DispatchAction and its progeny are just one example of this. I would disagree with some of this. Since a DispatchAction can't really stand on its own (unlike the commons packages do) I really think it belongs part of Struts. I don't see any reason not to give people the options from within the framework (I no longer like to use DynaForms but I'm not really opposed to them being an option). On top of this, if I was new developer I would be quite frustrated if I had to go find a ton of optional packages just to accomplish some common/useful things. I actually don't really find Struts that bloated. The jar isn't that big, so I'm confused what the concern is? What is it that you find being introduced that is currently bloating struts? Over the past two(maybe more?) years there haven't even been that many 'major' changes to Struts (a nice bunch of improvements but no major bloat that I can see). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] New: StrutsUpgradeNotes11to124
Date: 2004-09-20T17:46:39
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsUpgradeNotes11to124
URL: http://wiki.apache.org/struts/StrutsUpgradeNotes11to124
no comment
New Page:
= Upgrading Struts 1.1 to Struts 1.2.x =
== jars ==
I guess its obvious to say you need to replace the jars, but the one people might
forget is the new commons-validator.jar for version 1.1.3 of validator.
Also if you want to start using the new '''validwhen''' validation rule, then you will
need to deploy the antlr.jar as well.
== tlds ==
Remember to deploy the new versions of the tld files for struts tags. If you don't you
won't be able to use the new tag attributes added.
'''NOTE''' The uri's in the struts tlds have changed from jakarta.apache.org/struts to
struts.apache.org - however this shouldn't have any impact (see below)
Tag libraries can be configured in one of two ways:
'''A.''' If you have configured the tag libraries using entries in the web.xml (see
[http://struts.apache.org/userGuide/configuration.html#dd_config_taglib User Guide])
then these should continue to work.
'''B.''' If you have used the simplified deployment allowed by Servlet 2.3 onwards
(see [http://struts.apache.org/userGuide/configuration.html#dd_config_taglib_23 User
Guide]) then this should also continue to work as versions of the tld's with the old
uri have now been included in the struts.jar (and struts-el.jar). Its recommended that
for new development that you use the new uri
Struts 1.1 {{{ %@ taglib uri=http://jakarta.apache.org/struts/tags-html
prefix=html % }}}
Struts 1.2.x {{{ %@ taglib uri=http://struts.apache.org/tags-html
prefix=html % }}}
== validator.xml ==
Change the dtd declaration at the top to refer to the dtd for validator 1.1.3
!DOCTYPE form-validation PUBLIC
-//Apache Software Foundation//DTD Commons Validator Rules Configuration
1.1.3//EN
http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd;
== validator-rules.xml ==
Upgrade to the new version of validator-rules.xml.
== struts-config.xml ==
Its not absolutely necessary but you should upgrade to the 1.2 version of the dtd
(Note that as well as the version number changing so has the url to struts.apache.org).
!DOCTYPE struts-config PUBLIC
-//Apache Software Foundation//DTD Struts Configuration 1.2//EN
http://struts.apache.org/dtds/struts-config_1_2.dtd;
If you do upgrade to the 1.2 version dtd then there are a couple of attributes which
have been removed and you will need to remove them from your struts-config:
*debug has been removed from the controller element.
*dynamic has been removed from the form-bean element
Also the 'contextRelative' attribute in the forward element is now
considered deprecated and a new 'module' attribute added.
== ActionError(s) and ActionMessage(s) ==
There is some confusion over ActionError and ActionErrors and whats deprecated.
'''A.''' ActionError '''IS''' deprecated and should be replaced by ActionMessage.
'''B.''' ActionErrors '''IS NOT''' deprecated. The Struts committers would have liked
to have deprecated ActionErrors but because too much of core API depend on it (such as
the ActionForm's validate method) it hasn't been. However it may be in the future and,
where possible, you should now use ActionMessages in place of ActionErrors.
== Custom Tags and Validation ==
Many methods in org.apache.struts.util.RequestUtils and
org.apache.struts.util.ResponseUtils are deprecated. Replace RequestUtils.* and
ResponseUtils.* with org.apache.struts.taglib.TagUtils.getInstance().*
Replace org.apache.commons.validator.ValidatorUtil with
org.apache.commons.validator.util.ValidatorUtils.
== init-param web.xml configuration ==
A number of the of ''init'' parameter entries (i.e. init-param) in the web.xml were
marked as ''deprecated'' in the Struts 1.1 release and have been removed in Struts
1.2. A list of the ''init'' parameters which have been ''removed'' is given below
(refer to the [http://struts.apache.org/userGuide/configuration.html User Guide] for
more information on Struts configuration):
* '''mapping''' - see note on '''configFactory''' below
* '''debug''' - replaced by [http://jakarta.apache.org/commons/logging/guide.html
Commons Logging]
* '''bufferSize''' - moved to controller element in the struts-config.xml
* '''content''' - renamed to '''contentType''' and moved to controller element in
the struts-config.xml
* '''locale''' - moved to controller element in the struts-config.xml
* '''maxFileSize''' - moved to controller element in the struts-config.xml
* '''nocache''' - moved to controller element in the struts-config.xml
* '''multipartClass''' - moved to controller element in the struts-config.xml
* '''tempDir''' - moved to controller element in the struts-config.xml
* '''application''' - now '''parameter''' in the message-resources
DO NOT REPLY [Bug 31320] - pre-filled form values no longer work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31320. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31320 pre-filled form values no longer work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 03:14 --- If you have a problem, the convention in Struts is to ask questions on the user list first. I pointed this out to you politely in Bug 31293 when I closed it (although its probably my own fault as I continued to help resolve your issue rather than ignoring it as I should have done). There are good reasons to ask questions on the user list: * more people who could help you * it can help others to avoid the same problem Additionally since the previous two problems with upgrading you posted (Bug 31291 and Bug 31293) were both not bugs then my guess is this probably isn't either. As you haven't asked on the user list I'm closing it as invalid - if it does turn out to be a bug then you can always re-open it. Niall P.S. When you post to the user list, I suggest you include more information than you have here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: BLOBAction
I'd been thinking about something in between. How about an Action that does all the drudge work, but leaves the details to the implementor? Something, perhaps, like this: http://www.apache.org/~martinc/struts/DownloadAction.java This provides easy solutions for downloading files from the file system, resources from a web app, or a completely custom solution, if you don't like either of those. -- Martin Cooper On Mon, 20 Sep 2004, Craig McClanahan wrote: On Mon, 20 Sep 2004 09:57:00 +0200, Reinhard Nägele [EMAIL PROTECTED] wrote: Streaming files back to the reponse is really nothing special, and it's not exactly a Struts-specific thing. A simple Booch utitlity class would serve the purpose. I agree with Reinhard's reasons that something this specific to particular data access mechanisms might not be appropriate as a part of the core framework. That being said, questions about downloading binary data come up often enough that something like this would make a dandy example application. Reinhard Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
