Maven Build (Re: Struts Change Tracking)
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Even though Maven isn't our primary build mechanism, Joe, It's been a while but was it you or someone else that had a bunch of Maven build changes to check in after 1.2.0 went out the door ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compartmentalization of Modules (was Re: [18111] et al)
Joe Germuska wrote: At 3:30 PM -0500 1/20/04, Edgar P Dollin wrote: If the use of modules is truly to split struts-config.xml files, then isn't it simpler to just use comma delimited configuration files in web.xml? Well... yes. Some times you just do things the way you've always done them until someone points out a good alternative. Actually, on a current project, we're using modules for more than that, but still don't have the sense of strict compartmentalization that comes with the original module design. The multiple modules is mostly just a way to have multiple unknown action configs -- we might be able to use the relatively new wild-card mappings along with a list of config files to get what we need, but this is a temporary approach for prototyping, so it will probably be moot sooner than later. I still wouldn't mind someone's description of a case where strict separation of modules is necessary, just so I'll recognize it if I ever come across it myself. Maybe it's just a matter of taste, as I prefer to build for permissiveness than restriction (as noted in the other thread about requiring form beans for the html:form tag.) I always thought that the design of Modules had two seemly opposed goals: 1) To write essentially independent modules page navigation, etc... 2) but that can share session data that is produced. If a module is not meant to be reused then maybe multiple configs would be a better solution. The independence comes in page flow, and being aware of the other applications. The questions is how can be design Modules so they reduce spagetti code in both page flow and java code. What we need is the equalivent of Unix pipes or Web Filters Maybe the default module can be used to the same effect, acting as the glue. Using the main module to forward requests back and forth might be a little overhead in programming maintance. It would also keep the messy dependancies in just one module the default. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compartmentalization of Modules (was Re: [18111] et al)
Ted Husted wrote: Like James, I've been counseling teams to go multiple struts-configs rather than modules, because of the issues with cross-linking and sharing resources between modules. If we go ahead with the patch to html:link, to match the other changes we made this week, then I wouldn't have to steer people away from modules. As it stands, I believe the most common use case is that large teams want to use modules as part of a divide-and-conquer strategy. I'd suggest that we go ahead an apply these remaining patches, so that we support sharing of resources and linking between the named modules and the default module. If someone comes up with a patch to make the contextRelative tag attribute configurable or immutable, then we can apply that too. My one concern is that contextRelative is a verbose attribute name and potentially confusing. From one perspective, the module is the current context :). It really means to say applicationContextRelative, but that's impossibly long for an attribute name. We went the 'application' naming route before, why not just stick with a single term module, and call it moduleRelative ? Which is what is is, 'relative to the current module. While I'm at it, how about if we turn the attribute around and deprecate contextRelative=true in favor of modular=false? So we'd have things tags html:img page=/assets/logo.gif modular=false / instead of html:img page=/assets/logo.gif contextRelative=true / As mentioned, once we mop this up, I believe we can roll 1.2.0. :) -Ted. - 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: Action Config wild cards -- why not use regular expressions?
Joe Germuska wrote: Since Struts already depends on jakarta-oro, is there a reason not to use it for doing pattern-based mapping, rather than the home-grown methodology that's in the current builds? I don't have a use case for it yet, but since I was a perl hacker before I came to Java, I speak regex reasonably fluently, so it seems to me more useful to have the full power of regular expressions available. I have a few questions about simulating the ~= operation in ORO and Javascript for the validator code, but I'll save those for later. If there are strong feelings in favor of the status quo, I think it would be easy enough to make matcherClassName a property of ModuleConfigImpl and support pluggable matchers. I guess technically, only Validator depends on jakarta-oro; I might be persuaded that that's a reason to keep from adding it to the core, maybe... I doubt anyone could object on the basis of performance, unless they create a benchmark to support the claim it's much slower. Anywhere we can simplify the logic and eliminate duplication is a good thing. Joe Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Niall Pemberton wrote: I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reports
Paul Sundling wrote: I was looking at the maven reports and they're pretty interesting. One thing I found interesting was the report that shows duplications. There is a large number of classes that only differ in which class they extend. One large grouping of that is in the nested taglib classes. In the example below you'll see that the only differences are the import line and extends clause. It seems there should be some design pattern to where all the duplicate code could be refactored into one location. Of course, I couldn't think of one right away myself. Would the IoC stuff that's been mentioned help here for instance? Yes, I noticed the same thing. I believe AOP might address this. I believe Struts could benefit from using AspectJ. and collecting solid use cases would be a good starting point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/tiles-documentation/examples/tiles footer.jsp
I'll restore the copyright, I misunderstood the CLA. However, its removal was based on a precedent of when Ted had copyright Ted Husted in his code, and had to remove that copyright. Martin Cooper wrote: Is there a reason for removing Cedric's copyright? As I understand it, based on the language in the CLA, Cedric is entitled to keep his own copyright there, if he so desires. -- Martin Cooper On Wed, 7 Jan 2004 [EMAIL PROTECTED] wrote: rleland 2004/01/07 13:14:40 Modified:web/tiles-documentation/common footer.jsp web/tiles-documentation/examples/tiles footer.jsp Log: remove Cerdics personal Copyright and leave only Apache Copyright Revision ChangesPath 1.3 +1 -3 jakarta-struts/web/tiles-documentation/common/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/common/footer.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- footer.jsp 29 Dec 2002 21:20:52 - 1.2 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.3 @@ -2,9 +2,7 @@ div align=center font color=#023264 size=-1 -em Copyright copy; 2000-2003, Apache Software Foundation /em - br -emand Cedric Dumoulin/em +em Copyright copy; 2000-2004, Apache Software Foundation /em /font /div html:img page=/images/struts-power.gif align=right border=0/ 1.2 +0 -2 jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- footer.jsp 6 Jul 2002 01:13:50 - 1.1 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.2 @@ -2,8 +2,6 @@ div align=center font color=#023264 size=-1 em Copyright copy; 2001, Apache Software Foundation /em - br -emand Cedric Dumoulin/em /font /div img src=%=request.getContextPath()%/images/struts-power.gif align=right border=0 - 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]
Re: cvs commit: jakarta-struts/web/tiles-documentation/examples/tiles footer.jsp
Martin Cooper wrote: Is there a reason for removing Cedric's copyright? As I understand it, based on the language in the CLA, Cedric is entitled to keep his own copyright there, if he so desires. Changes have been reverted. You probably won't see an update since I did a cvs join. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestOptionsTag1.jsp
[EMAIL PROTECTED] wrote: * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. This is clearly an old apache 1.0 license instead of 1.1, note the Apache Group instead of the Apache Foundation in the wording. Use the License.txt in the top level of struts as a template. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Ted Husted wrote: OK, here's what we have I would say release, we are using a x.y.z numbering scheme. Noteing in the limited release that this should be considered an Alpha until further testing says otherwise. Also to ask others not to announce this on other lists until it has been voted Beta/GA or better. I believe Joe said though all unit test ran they **didn't** all pass, I believe it was like 66% passed. As an aside on the unit tests, I pulled all other Struts releases CVS, 1.1 Beta 2, RC 1, RC2 and ran our current unit tests against the source and they all failed at some point. That was using the same version of cactus used to test 1.2.0 -Rob * Release notes updated * Issues w/o solutions marked LATER * Webapps tested on TC 4.1 (one issue) * JUnit tests run In the Validator example, we're suppose to be able to change selected validations for a county just by overriding a form in a formset. This doesn't work unless you respecify the entire formset. I fixed the example, but we should decide if this is suppose to be a supported feature or not. Here's what we don't have * Webapps tests on TC 3.3a (next) * Patches/fixes applied for 11 issues http://tinyurl.com/ysx3x * Cactus tests run (under Ant) I can't get Cactus running under Ant either, though Joe says they run under Maven. If the Cactus tests are truly broken under Ant: Do we want to call that a showstopper? If so, do we want to workaround that by taking the Cactus tests out of the buildfile for now, as we are moving to Maven anyway, and have Joe apply his Maven-Cactus patch. I could apply the patches sometime this week, but I'm leary of doing so when I can't get the Cactus tests to run on my own. If we resolve the Cactus thing quickly, do we want to release what we have as 1.2.0 (w/o the 11 patches), with the intention of rolling 1.2.1 in January, or wait and do this after Christmas? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
David Graham wrote: --- Don Brown [EMAIL PROTECTED] wrote: On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote: snip / What kind of Spring Framework classes would you want to use in Struts 2.0? The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. The major design difficulties are abstract away the request and response objects from the controller actions, and also configuration of any other front-end objects you need along the way. To a certain extent Commons Chain and its context leads the way regarding the former. I see Spring as helping Struts be better structure its internal components, specifically using a BeanFactory implementation. It would not replace struts-config in any way or even be exposed directly the a Struts application. The struts-chain request processor implementation makes it easy for Struts apps to plug in IoC frameworks themselves. I totally agree Struts shouldn't become some generic IoC framework, hence my suggestion of using Spring. The reason I think IoC is important for Struts 2.0 is for easier unit testing, more componentized development, easier to plug in alternate implementions of components like file upload, better dependency management, less object references, and easier for the advanced user to extend Struts in interesting ways. Notice these advantages are targeted for Struts developers and advanced Struts users. The IoC topic deserves its own thread. Spring is bloated. It contains a DAO layer, JDBC helper library, Web MVC framework, IoC support, etc. I don't think we should be lugging around Spring inside of Struts. Spring is broken up into 4 jars and we might only need spring-beans.jar which is 119KB, even spring.jar is only about 694KB. In comparison commons-collections has grown to 785KB, groan, which is about the same size. There are also non-technical aspects of Spring that have lowered my opinion of it. Ok, I'll bite.. If we want IoC inside of Struts we should look at something lighter weight like HiveMind. The last version of hivemind I have from CVS built to 195K. I believe that size isn't the only factor ot consider. I am not bothered by the Jar size of spring since only those classes that are used will be loaded into the JVM. We should look at how it would fit our proposed usage of IoC just as you suggest below. I'd also like some focused concrete examples of how IoC would benefit Struts internals before we decide to go that route. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Ted Husted wrote: If we use the current Validator 1.1.1 JAR, and it becomes the final release, then we could vote on whether Struts 1.2.0 can also be a final or General Availability release. If you recall I believe we came to consensus on struts-dev that Validator can't go Beta or GA w/o being released via Struts, otherwise it wouldn't get enough testing IMHO to even warrant a vote being called. If this Validator 1.1.1 JAR does not make final, then the best we could do is mark ours would be beta (since it has a beta dependency). In the second case, once Commons Validator 1.1.1 does go final, we could just tag and roll Struts 1.2.1 and then vote on that. (Or, if the change between the Commons Validator 1.1.1 RC and final were trivial, we could just patch the distribution.) Regardless of what happens with the Validator, I would be (pleasantly) surprised if Struts 1.2.0 did make the General Availability grade. All I really want to do now is tap the keg on 1.2.x. The mean number of milestones for a Jakarta stable release seems to be five or six. So, it would not be unusual for us to get 1.2.4 before hitting a General Availability grade. -Ted. [EMAIL PROTECTED] wrote: Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - 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]
[ANNOUNCE] Commons-Validator 1.1.1 released
Commons Validator 1.1.1 is now available for testing. Please refer to http://jakarta.apache.org/commons/validator/tasks.html that details the changes that have taken place since the 1.1.0 release. Downloads: http://jakarta.apache.org/~rleland/ValidatorAlpha/1.1.1 Just a reminder : The release process is following the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Rob
Re: [VOTE] Joe Germuska as a Struts Committer
Martin Cooper wrote: Joe has been involved in the Struts community for some time now, and has been a great contributor on the -dev and -user lists, as well as in the bug database. I believe Joe would be a great asset to the team, and that it's time we invited him to join us as a Struts committer. Here's my +1. Here is my +1, I had emailed Joe 2 months ago about being a Committer because of his Maven expertise but he demurred at the time, and wanted to prove himself first. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is the next release?
Ted Husted wrote: I believe as soon as the next Validator ships, we could go ahead and roll 1.2.0. It may or may not be GA material, but we should get it out there where the community can decide. I'll start working on it next weekend. I want to review the docs a little to make sure they are up to date then cut a release. There were a couple of good suggestions in Bugzilla that David fielded but those could wait for a 1.1.2 release. -Ted. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is the next release?
Ted Husted wrote: Craig R. McClanahan wrote: Another thing Remy does for Tomcat (which I *really* appreciate) is keeps a running change log (summary, not detailed) in the release notes for each version. That way, everyone can get a quick summary of what's changed. So, I'm working on one of these now for 1.1-1.2.0. I pulled the CVS log messages down in XML via Ant (with Don Brown's help), and I'm now looking at munging that into the format Tomcat is using. Maven already creates a changelog for struts when a site:generate is performed. I am sure it would also work with a sub-target just for changelog. -Ted. - 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]
Japanese/Asain/Russian/Arabic Struts Committers Needed (Was: Re: TagUtils.encodeURL performance)
There is also Internationalization of domain names, and ultimately URL's http://www.faqs.org/rfcs/rfc3492.html -Rob yasuhiko yoshikawa wrote: I do not think always passing UTF-8 as character encoding type is right behavior. As far as I can tell, there is no such requirement to mandate(or even recommend) UTF-8 as character encoding type in the HTML4 specification (and relevant RFCs). A while ago, I submitted a patch that enables the encoder to take character encoding name as second parameter. I see no reason why the character encoding is done with UTF-8. I am glad you spoke up, We need (1 or more) an Japanese/Asian/Russian/Arabic Struts Committers, because they will have supporting the i18 in their best interest. If an Asian/Russian/Arabic developer(s) started making regular contributions, then after a while(3 - 9 months) we would know that that person would be a valuable committers, and they might be nominated. The qualities that would increase the likely hood that I would nominate them as a Committer are: through : (attach diff patches against Nightly builds) (Test patches throughly) persistent (make noise) so as to make sure patches are applied. semi-fluent: in written english (able to clearly describe a problem, and solution in written english) skelling (Spelling ;-) ) is not important ! flexible : willing to discuss different approaches with other developers/committers, and arrive at a good solutions regardless of whose Ideas they are. centered :They know that its ok to make mistakes, and learn from them. We normally like to gradually add new committers. Do you know of anyone that might want to step up ? What is the Bug report number ? Have been tested by Japanese users ? These could be rolled into the 1.2.1 release, which could cut be made to address this problem. Using UTF-8 as character encoding type works only if the html documents sent from the application are encoded in UTF-8, but many i18n applications use 'native' character encodings (like Shift_JIS, Big5, EUC-KR etc) instead, for variety of reasons. The issue was recently discussed on the mailing list of Japanese struts user's. And we found that, for example, html:link tag's parameter populating functionality has been unusable for many of us because it ignores the response's character encoding and uses UTF-8 to get the bytes for url encoding. --- Robert Leland [EMAIL PROTECTED] wrote: Pierre Maury wrote: The patch would need to be usable with different encoding types. Why? The Java 1.3 version doesn't accept an encoding type and we always pass UTF-8 to the 1.4 version. This memory storage seems like a small price to pay for the improvement, but I would like to hear from other commiters. I'm not a big fan of this because there are much bigger performance optimizations to be had in other layers of a Struts app but I won't stop anyone from applying a clear and *tested* optimization. David -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 Resurrected
Ted Husted wrote: AFAIK, it's a decent milestone already. :) I believe to get it ready for prime time as a General Availability release will mainly be a matter of updating the documentation. But, the best way to generate some interest in doing that may be to publish a milestone release. Also, to make the GA grade, all dependent libraries would also have to be GA grade. From what Rob says, we want to use the latest Validator build now. So, a Commons-Validator 1.0.3 release would help in that regard. The current Validator 1.1.0, and a 1.1.1 release could certainly be done. I am leaving home at 4 am tomorrow for the weekend, and hesitate over doing a last minute release T e d : If I understand the X.X.X release convention, a Vote doesn't have to be held for a release to occur but only to qualify it as Alpha/Beta/GA ? Is that correct? If that is so I could just stay up tonight and do a release and we would vote on the quality at a later date, once it has been a bit. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 Resurrected
Brandon Goodin wrote: When are submitted patches going to be reviewed and incorporated? There seems to be several out there that are useful. Which patches are you suggesting, and have you tested any of them yourself or have any comments about suggested solutions ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TagUtils.encodeURL performance
Pierre Maury wrote: The patch would need to be usable with different encoding types. This memory storage seems like a small price to pay for the improvement, but I would like to hear from other commiters. -Rob Hi, I think there is a performance issue with org.apache.struts.taglib.TagUtils.encodeURL(String). Attached to this mail, four java classes that demonstrate and solve the problem. You may run EncoderTest to compare the timings of the original struts code with a faster encoder. On my computer encodeURL takes about 0.2ms. This does not look like a big issue, but encodeURL is called by computeUrl for each parameter name and each parameter value. The web site I'm working on displays products lists. There an average 3 links per product and 20 products per page + 20 other links. Each of this links takes four parameters. Total encodeURL time per page amounts to : (3*20+20)*(4*2)*0.2 = 128ms ! At the same time, the struts action + the JSP page takes about 200ms. The attached encoder is at least 50 times faster. By using this encoder on my application, the troughput was greatly improved. If you are interrested, I can submit a patch Pierre Maury - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stable nightly build including ValidWhen change?
Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: When we release 1.2.0, it will be the current nightly build, Except that's still based on non-released versions of the commons packages, right? Shouldn't a 1.2.x Struts release be based on the most recent releases of the commons JARs? The commons-validator 1.1.0 was released it just wasn't a GA grade jar. The version in CVS would be a GA Quality, which I could/would release. My take is that we release 1.1.1 validator and use it for struts 1.2.0. The concensis on the struts-dev list was that Validator really needs a struts release before it could be voted of Beta/RC quality(i.e. announced on the struts-dev and struts-user but no where else) list, because there may be less than 10 people using it standalone. More may be using the nightly version. -Rob
Re: 1.2.0 Resurrected
Ted Husted wrote: T e d : If I understand the X.X.X release convention, a Vote doesn't have to be held for a release to occur but only to qualify it as Alpha/Beta/GA ? Is that correct? If that is so I could just stay up tonight and do a release and we would vote on the quality at a later date, once it has been a bit. -Rob Yes, if we were able to include a validator 1.1.1 and it later went to GA, then our release could go to GA too. Though, I wouldn't be optimistic about 1.2.0 going GA, but anything's possible :) We could also just do a 1.2.1 once the Validator 1.1.1 was out too. My personal goal is to just tap the keg on 1.2.x, so we can get in the habit of releasing more often. The Validator 1.1.0 has a bug that shows up a fatal bug in TC 3.X but not in 4.X Agreed, go ahead and use c-v 1.1.0, though if no one objects I'll do a release of validator and if it comes out in time you have the option of using that instead. The only stumbling block now is that I need to change my public key to use stronger encryption so Martin doesn't get a 'warning' from my signed files. -Rob -T. Robert Leland wrote: - 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]
[Nightly Build] Validator
Craig: The Nightly build of Struts(Nov 24th) has a version of Validator from Nov 8th, could you update the of commons-validator build to pickup the latest changes? These changes deal with not validating disabled fields. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24909] New: - add new tag for css stylesheet linking
Ted Husted wrote: If there are no objections on technical grounds, I would favor adding it. You can do this sort of thing with rewrite, but it's clumsy and counter-intuitive. +1,. It's a hole in the html tags, and a good fit. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven patch
Tim Chen Thanks, these have been applied ! -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Result][Vote]Disable bugs for Struts 1.0
+5 votes no 0 votes no -1 votes. I'll send an email to ifrastructure to close all Struts1.0 categories. 1.0 Beta 1 1.0 Beta 2 1.0 Beta 3 1.0 Final 1.01 Final 1.02 Final We should probably also close Struts 1.1 Beta 1, Beta 2 at least but lets start with the 1.0 ones first. http://www.enhydra.org -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: [Vote]Disable bugs for Struts 1.0 I would like to propose disabling filing of NEW bugs for Struts 1.0, I know BugZilla 2.16.3 can do this not sure about 2.14.2 Bugs filed against 1.0 are a waste of time for committers and for reporters. Only bugs filed against 1.1 final, or the nightly builds have any hope in being addressed. If there were patches included with the reciently reported 1.0 enhancements, I might feel differently. As it is NEW Struts 1.0 BugZilla reports are just Noise that I filter out. -Rob - 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]
[Vote]Disable bugs for Struts 1.0
I would like to propose disabling filing of NEW bugs for Struts 1.0, I know BugZilla 2.16.3 can do this not sure about 2.14.2 Bugs filed against 1.0 are a waste of time for committers and for reporters. Only bugs filed against 1.1 final, or the nightly builds have any hope in being addressed. If there were patches included with the reciently reported 1.0 enhancements, I might feel differently. As it is NEW Struts 1.0 BugZilla reports are just Noise that I filter out. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecating DiskMultipartReqwuestHandler and friends
Martin Cooper wrote: Hi folks, Any objection to deprecating DiskMultipartRequestHandler and its associated classes? This was the default file upload handler in Struts 1.0, but was replaced by CommonsMultipartRequestHandler for 1.1 and beyond. It was, and is, buggy, and I'm sure nobody has any interest in maintaining it now that we're using Commons FileUpload to do the heavy lifting. Just asking up front so that I don't have to go back and remove a boatload of deprecations if it turns out that somebody wants to keep it. ;-) ++1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where and when will we use org.apache.struts.config.ModuleConfig
This is a struts-user list question. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-example/tour.htm
James Mitchell wrote: Tests: I'm spending some time this weekend trying to fix the cactus tests. New Struts Example: I'll do my best to get this done quickly. I'm planning a total rewrite. I would also like to add a few more pieces of functionality that (if for nothing else) show off all or most of the 1.1 enhancements. The required web.xml's changed between 1.3 1.4.1 for the redirects, so these might need to be addressed. What we have under conf/ isn't quite right. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Self Describing Business Objects :
This is question that is best asked on the users list as it has noting to do with struts futire development. [EMAIL PROTECTED] wrote: I will be working on porting a company framework (and hopefully open source it) from ASP/VB (yack!) to Java. The idea of the framework is quite simple. It is a framework for buiding administration screens like update/search edit user but it has some interesting features : The Business objects a described in xml ie : entity nameuser/name tableusr/table attributes namefirstname/name label EN labelFirst Name/label /EN . /attributes attributegroups attributegroup nameLabel/name attributes attributefirstname/attribute attributesurname/attribute /attributes /attributegroup attributegroup nameEdit/name attributes attributefirstname/attribute attributesurname/attribute /attributes /attributegroup etc.. /entity The Business Object xml descriptor has enough information for display it as well as updating it. AttributesGroups allow for list views and edit views of the object. Another component of the framework is the PageFlows that are made up of Actions that use these Business Objects to get the info for these views like Edit User. Most of the time you do not need to write code at all, we have also written a editor for the Business Objects and the Pages Flows. So at the end of the day the html of genernated by the framework from the xml descriptor and the persistence is also done from there. So doing administration screens are very quick. ie : days instead of weeks. The some code can be used for web front ends as well as guis. I was wondering it there is anything else out there like this or are there ways on doing some intergration of this with Struta and Hibernate and Cocoon? Mike The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorised. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. - 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: Maven test run
Steve Raeburn wrote: In the spirit of rolling up sleeves, this is the result of a very quick look at Maven: http://www.apache.org/~sraeburn/maven/index.html Super. You could use xdocs/images/struts-blue.gif which fits the background color, and feel free to delete the other logo's under xdoc/images I was just trying different effects out. -Rob I'll keep playing with this for now, because it's not fit to be checked in yet and I've only built the core /src/share files. There's also more work to do in configuring the various reports. Don't expect all the links to work, or any of the reports to be correct (though already, some of them look useful). Steve - 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: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
James Mitchell wrote: I thought that one of the Forrest Committters said that the Forrest plug-in for Maven is most likely broken ? Most of us have given (or at least hinted at) our opinions, so let's give a show of hands: Mavenization: [X] +1 - I am in favor of using Maven for build/dist/test/etc. [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using Maven for build/dist/test/etc. Forrestization: [X] +1 - I am in favor of using Forrest for site generation. [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using Forrest for site generation. Other: [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea. (If I left out any, please add them) One question I have about all this, (and please forgive me if I missed it in any of the messages in this thread) how does using either approach affect the generation of the .tld from our source? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 7:18 PM Subject: Re: The Forrest Option On Wed, 1 Oct 2003, Craig R. McClanahan wrote: snip / ducks We can even add Forrest-based generation to our current Ant-based build scripts :-). It's just an external tool, after all. /ducks Actually it is very easy to do, using a forrest entity which imports forrest targets. The only setup needed is to install forrest and set FORREST_HOME. All the same ant targets used now to build the site can be used to build forrest. If the Forrest route was accepted, I planned to do this from the start. Don There's only so much time we each have to spend on Struts. I'd rather not spend much time learning the build process. David 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] - 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: The Forrest Option
David Graham wrote: The Forrest features Don mentioned aren't significant to me and I'm already familiar with Maven so I'm leaning towards Maven but I really don't care as long as the build is as easy as maven jar or equivalent. But please let's not try to maintain multiple build processes. I was looking at the Forrest archives and it looks like they are in the early stages of creating a build system. Until that time then it we have the choices of Maven, Maven + Forrest, or Forrest + Ant. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
Don, I have one request and that is to leave the existing maven files in place since they do currently generate a web site with the reports. Craig R. McClanahan wrote: Don Brown wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Looking at the potential here, I'm inclined to suggest we accept Don's offer to help set this up -- although perhaps at first in a standalone directory structure that can be undone if we discover that we don't like it. One advantage is that we can do it without having to migrate the build system to Maven first. As for skins, I sure like the Avalon/Tigris or Krysalis examples, and sure wonder why the Forrest developers chose the native style they ship with, when they could do something as nice looking as either of these. But, if I understand what you're saying, skins is essentially a runtime (when you're generating the HTML) choice; we don't have to make an irrevocable decision at any point in time. Don 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]
Re: The Forrest Option
The whole Maven idea came because we felt the build process of ant struts-legacy was broken or needed some serious work. If Don wants to put energy into redoing our site's look and feel that then here is my +1. Just know we are still left with the original problem. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: Don, I have one request and that is to leave the existing maven files in place since they do currently generate a web site with the reports. I must be confused with the several projects I'm working on. So, Maven is already setup in Struts to run the builds? If so, why are we going to add Forrest to the builds? Why not just start building the site and distro with Maven? The site was about like what Don had the front page, along with javadoc(current+legacy), clover reports, PMD, changelogs. In fact it had all the features that the commons validator does, check it out: http://jakarta.apache.org/commons/validator/index.html What was needed was to tie in the userguide, and other more detailed docs, which should have been straight forward, but I have so little time now. What wasn't setup in the builds was the sub-projects of contrib, etc... David Craig R. McClanahan wrote: Don Brown wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Looking at the potential here, I'm inclined to suggest we accept Don's offer to help set this up -- although perhaps at first in a standalone directory structure that can be undone if we discover that we don't like it. One advantage is that we can do it without having to migrate the build system to Maven first. As for skins, I sure like the Avalon/Tigris or Krysalis examples, and sure wonder why the Forrest developers chose the native style they ship with, when they could do something as nice looking as either of these. But, if I understand what you're saying, skins is essentially a runtime (when you're generating the HTML) choice; we don't have to make an irrevocable decision at any point in time. Don 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] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute
Chris Gastin wrote: James: All Taglib tests are failing on me right now. I am getting the following errors, and I don't know if it is because of the situation at hand or my local environment setup. That is why I was going to wait for everthing to get ironed out concerning the taglib unit tests. Unit tests for code other than taglib are working fine, and passing. I am going mess with it later tonight, and see what I can figure out. It's not your setup. About a month ago I tried the tests on 1.1 Final, RC-1, Beta 3, ... All those tests also failed. They didn't fail at one time. I tried upgrading to cactus 1.5beta1 and hit some other snags. You might be able to roll back to cactus 1.3. Again that isn't a real solution, but may be good enough for your needs. Chris Gastin - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:56 PM Subject: Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute You can get around the unit test issue by either: - Comment out the sections of the tests that are failing or - Directly reference the ones you want tested Either way would only be a temporary solution, but it would help you move along until we iron out what's going on. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:30 PM Subject: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:30 --- I did some user testing of the tag, and it seems to be working, but I will add unit test once the unit test issue is resolved. - 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]
Re: The Forrest Option
Don Brown wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. I prefer Maven because it provides builds, testing, QA tools, and site generation in one tool. The repository of binaries makes building a distribution or maven enabled site as easy as typeing, 'maven' for new users. Changing the look/skin is straight forward, though as I say below I wouldn't invest alot of time tweaking it. My main question to the items below is 'which of these features would we use for the struts site' In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML Maven has been doing this for a while now.. - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) Maven currently handles RRS, Docbook, and a few other formats, including the ability to take a preexisting framed html like JavaDoc and take it apart and assemble it again with a .maven wrapper. What's the wiki thing, and why do you think that would be usefull ?. Could you give an example how multiple XML sources would be aggregated and used as a single source. How is this capability an advantage for the struts web site. - Power and features of Cocoon including charting, web services integration, scripting support, etc. Charting is nice. What types of charting do we get for free or almost free that would help with our site. I believe Maven can provide charts about bugs reports, which I don't EVEN want to see ;-). How does web services/scripting fit into our needs? Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. I am assuming this plugin uses the maven xml doc files and generates forrest docs ? To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Maven does this. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. We only need one look, though I don't like the default Maven look, but not enough bothering changing it. We may customize it but we won't be changing it dynamically. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Don -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Web site updates
Craig R. McClanahan wrote: Ted Husted wrote: Steve Raeburn wrote: Done. The ASF thanks you for your help and support =:) Hey anybody going? I won't make it this year, but I'm starting to think about 2004. I'm going, and speaking on Tuesday 11/18, 5:00pm-6:00pm about Struts. I'm also tasked to speak on a couple of panels about Open Source at Comdex, which is also happening in Las Vegas the same week. Regarding the archived 1.02 docs - there doesn't seem to be a link to them anywhere. Shall I add one? We should probably remove those now. Also, we don't have the current release (1.1) docs on the site which might be confusing for some users. Do we want to maintain docs for the current version as well, and add appropriate links? That approach was mainly an artifact of the extended 1.1 incubation period. =:) We might now want to fall back to the original approach of just featuring the nightly build on the website. Hopefully, we can get the Cactus tests sorted out soon and start the 1.2 march, to help support the new Validator release. Fixing the nightlies is on my TODO list ... promise! :-) Looking at the Cactus logs there is a StandardManager[/test] IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.StringTokenizer java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.StringTokenizer I am not sure exatcly containg class is causing this. That is happening, this is running cactus 13-1.4.1, TC 4.1.27. I know the unit tests worked under cactus 1.5beta1, I will try upgrading to the newest version then down grading to 1.3. -Ted. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp
James Mitchell wrote: Well, I was in the middle of a reply on another thread (about this), so I'll just put it here instead. With the latest changes I just committed, the tests pass on Tomcat 3.3.x However, I still cannot get them to pass on 4.0.x or 4.1.x. It seems that the container (in both cases), while running on port 8080 in my configuration, thinks it is running on port 80, which is causing the bean:include tests to fail. I'm not sure where in the configuration of the tests that we need to make changes or if that's even the problem, so I'm still checking into it...just thought I would drop a quick note. Thats what I discovered when I filed the bug report originally. Since no one replied to teh reports I figured it was me. At first I suspected the token substitution that I had did so that none of the server.xml files would have to be hard coded. However looking at the generated files under target/test/tomcat41 they look ok. Look at the cactus logs do you see the serialization error message ? So I am glad to see we're both having the same problem :), but unhappy about that also :( -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Chris Gastin [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 10:49 PM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp James: You committed the following file: * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag1.js p. * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag2.js p. Are these unit tests working for you. I am trying to find at least one taglib unit test that works,so I can determine if it my local environment or or the tests which are blowing up. I am not to familiar with Cactus, and its setup. Thanks, Chris Gastin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 29, 2003 7:49 PM Subject: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp jmitchell2003/09/29 17:49:11 Modified:web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp Log: Update taglib tests. I suspect that many of the failures are due to changes in whitespace output (or lack of it). Revision ChangesPath 1.4 +16 -64 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag1.js p Index: TestErrorsTag1.jsp === RCS file: /home/cvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErr orsTag1.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TestErrorsTag1.jsp 10 Mar 2003 17:29:52 - 1.3 +++ TestErrorsTag1.jsp 30 Sep 2003 00:49:11 - 1.4 @@ -34,10 +34,7 @@ My Errors go here:html:errors/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:default_errors_header -default_errors_prefixMy Errors Text -default_errors_suffixdefault_errors_prefixMy Errors Text 2 -default_errors_suffixdefault_errors_footer + My Errors go here:default_errors_headerdefault_errors_prefixMy Errors Textdefault_errors_suffixdefault_errors_prefixMy Errors Text 2default_errors_suffixdefault_errors_footer /bean:define /logic:equal @@ -68,10 +65,7 @@ My Errors go here:html:errors bundle=alternate/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:alternate_errors_header -alternate_errors_prefixMy Alternate Errors Text -alternate_errors_suffixalternate_errors_prefixMy Alternate Errors Text 2 -alternate_errors_suffixalternate_errors_footer + My Errors go here:alternate_errors_headeralternate_errors_prefixMy Alternate Errors Textalternate_errors_suffixalternate_errors_prefixMy Alternate Errors Text 2alternate_errors_suffixalternate_errors_footer /bean:define /logic:equal @@ -101,10 +95,7 @@ My Errors go here:html:errors/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:default_errors_header_fr -default_errors_prefix_frMy Errors Text (fr) -default_errors_suffix_frdefault_errors_prefix_frMy Errors Text 2 (fr) -default_errors_suffix_frdefault_errors_footer_fr + My Errors go here:default_errors_header_frdefault_errors_prefix_frMy Errors Text (fr)default_errors_suffix_frdefault_errors_prefix_frMy Errors Text 2 (fr)default_errors_suffix_frdefault_errors_footer_fr /bean:define /logic:equal @@ -132,10 +123,7 @@ My Errors go here:html:errors bundle=alternate/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:alternate_errors_header_fr
Re: XHTML Web site updates
Robert Leland wrote: Craig R. McClanahan wrote: Ted Husted wrote: Steve Raeburn wrote: Done. The ASF thanks you for your help and support =:) Hey anybody going? I won't make it this year, but I'm starting to think about 2004. I'm going, and speaking on Tuesday 11/18, 5:00pm-6:00pm about Struts. I'm also tasked to speak on a couple of panels about Open Source at Comdex, which is also happening in Las Vegas the same week. Regarding the archived 1.02 docs - there doesn't seem to be a link to them anywhere. Shall I add one? We should probably remove those now. Also, we don't have the current release (1.1) docs on the site which might be confusing for some users. Do we want to maintain docs for the current version as well, and add appropriate links? That approach was mainly an artifact of the extended 1.1 incubation period. =:) We might now want to fall back to the original approach of just featuring the nightly build on the website. Hopefully, we can get the Cactus tests sorted out soon and start the 1.2 march, to help support the new Validator release. Fixing the nightlies is on my TODO list ... promise! :-) Looking at the Cactus logs there is a StandardManager[/test] IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.StringTokenizer java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.util.StringTokenizer I am not sure exatcly containg class is causing this. That is happening, this is running cactus 13-1.4.1, TC 4.1.27. I know the unit tests worked under cactus 1.5beta1, I will try upgrading to the newest version That should have been 'works under cactus 1.3' then down grading to 1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Results] Struts to depend on Validator 1.1.0
Steve Raeburn wrote: Sorry Rob, I meant to respond but got distracted after reading your message. FWIW, a belated +1 :-) BTW, why isn't Validator 1.1.0 available in the normal download location? I was trying to follow the same procedures as struts by only making unqualified releases have limited availability. In reflection since it's standalone users are so few that may or may not have been a good idea ! -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Short Term Plan] Struts to depend on Validator 1.1.0
Ted Husted wrote: Robert Leland wrote: Over 99% of commons-validator usage is through struts. In fact it may be 100%. I feel the only way to really promote commons-validator to Beta status is to make the nightly build of struts depend on the 1.1.0 version which has released in Augustand been designated an Alpha. This being the case, we might also roll a Struts 1.2.0 release after the dependency changes, so as to expose the updated validator to the widest possible audience. I don't believe the nightly build is up to GA standards yet. I expect that we will need to better document migrating from 1.0/1.1 with deprecrations to 1.2 without deprecations. But the best way to do that might be to run a milestone and see what people ask about. That would be very helpfull ! Of course, we can always do a 1.2.1 once the Commons-Validator 1.1.x is GA. So, we wouldn't have to make any heroic efforts on the 1.2.0 release. Just a milestone of Struts with this dependency change. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New feature process
Don Brown wrote: What is the process when adding a new feature (in this case, wildcards for action mappings)? Create a Subject: [Proposal] wild cards for action mappings. Use lazy Consensus. At least 3 +1 votes, no -1 votes. There is a doc somewhere that says when to use each type of vote. Also I thought we already discussed this and it's addition was approved ? Do we wait until a release is ready to update the documentation or update it when the feature goes in? I would say nightly Docs should always match the nightly source Also, I couldn't really find a changelog. If you have maven you can now build the top level struts documentation which includes a generated change log. Do we just use bugzilla to track new features? If so, should an enhancement request be made before a feature gets added? No. If this information is already on a webpage somewhere, I apologize in advance :) I would like to know that answer also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept patches to make html taglib more extensible
Sgarlata Matt wrote:
I hope it's OK for a non-committer to start a vote. I know this has been a
contentious issue, so I would like to clearly outline my plan for making the
html taglibs more extensible and I would like a vote before I go to all the
trouble of coding, updating documentation, resolving bugfixes, answering
questions, etc.
DESIRED FUNCTIONALITY
The ability to cleanly extend the Struts tags. The tags are so good that
when an application-specific requirement arises, it's much more desirable to
extend from the Struts tag and keep tie-ins with ActionForms and such than
it is to go off on your own.
PROPOSED SOLUTION
The solution is two parts. Please vote separately for each part of the
solution.
A) Instead of accessing instance variables directly, use getters.
snip from=BaseFieldTag.java
if (accept != null) {
results.append( accept=\);
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append(\);
}
/snip
If someone wanted to override the accept attribute so that it was always
equal to foo then they would be able to do so. A better use case would be
overriding the onclick method so that it does something special like display
a calendar popup. Getters are actually already used in some places (e.g. -
prepareMouseEvents in BaseHandlerTag), so really this is just doing an audit
on the code to ensure getters are used consistently throughout the taglib.
Use case for Part A:
I built an implementation
of Matt Kruse's JavaScript calendar widget based on the Struts tags a few
weeks before Matt made his own implementation, so I have some experience
doing this. As some brief background, the widget is a text box and a
corresponding calendar icon. When you click on the calendar icon a popup
appears where you can choose the date. When you click on the text box
(which is what overrides a Struts tag) you want onfocus to automatically
call this.blur() so that the user can't enter text into the textbox (that's
the calendar popup's job). So in my subclass it would be nice to override
the getOnfocus() method instead of overriding the entire
renderIForgetWhatItIsCalled() method. Of course in this particular instance
getOnfocus() is already being used instead of onfocus being accessed
directly, but I think this behavior should be consistent for all attributes.
+1. always good practice.
B) Add a new renderExtraAttributes() method that gives people the chance to
throw non-standard HTML into their tags that extend from Struts tags.
snip from=BaseFieldTag.java
results.append(\);
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());
matts-idea
results.append(renderExtraAttributes());
/matt-sidea
return results.toString();
/snip
Use Case for Part B:
Unfortunately I still can't think of a good HTML 4.01 compliant use case for
renderExtraAttributes(), but here is a weak try at it.
No solid use case will allways get my -1. I don't want to see
unnecessary methods added just because
they might somehow prove useful. I will vote for adding a method that
will be used for a specific purpose.
I like the idea of this hook, and I don't personally care if it is valid
HTML 4.01 is produced or not,
that is YOUR choice! Because if you NEED to do this you're going to do
it anyway, just not as easily.
Also when you say invalid HTML 4.01
do you mean specific to say IE 6.0 or
do you mean just adding additional HTML which isn't really invalid?
If my other
suggestion of having the render() method call getters instead of directly
accessing instance variables is used, then renderExtraAttributes() becomes
more important. If it is not provided and someone wants to stick in some
non-HTML 4.01 compliant HTML, what they will do is override something like
the getSize() method so that it correctly renders the size and then sticks
in the understandard HTML. This is a nasty hack but you know a programmer
will choose that over duplicating an entire render() method.
If you made it this far, thanks for reading this long email ;) I know I've
posted much of this before in several different messages, but hopefully this
consolidation is useful.
Matt
-
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: cvs commit: jakarta-struts/src/share/org/apache/struts/util ActionMappingMatcher.java WildcardHelper.java
[EMAIL PROTECTED] wrote: mrdon 2003/09/28 18:24:21 Added: src/share/org/apache/struts/util ActionMappingMatcher.java WildcardHelper.java Wouldnt this be better placed in the action package ? Would any other package other than action ever use these ? If not then these classes could have package scope access. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util ActionMappingMatcher.java
[EMAIL PROTECTED] wrote: mrdon 2003/09/28 20:23:30 Modified:src/share/org/apache/struts/action RequestProcessor.java Added: src/share/org/apache/struts/action ActionMappingMatcher.java Removed: src/share/org/apache/struts/util ActionMappingMatcher.java I forgot to mention, most of the Struts source code uses the OLD Apache 1.0 license, even though it is labeled version 1.1. Take a look at the License.txt in the top level of Struts, this is the correct wording al code should be using. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Results] Struts to depend on Validator 1.1.0
4 +1's 0 -0,-1 Craig, If you could upgrade the nightly build to use Struts 1.1.0 it's located under http://jakarta.apache.org/~rleland/ValidatorAlpha/ This version is backward compatible, so it could be used for tonight's build. We will start upgrading the struts source Sunday night. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.1 unittest suite problem
James Mitchell wrote: Sorry for the late response. I finally got some time to take a look at this and after fixing a few problems related to cactus configuration, I finally got the tests to run. Unfortunately, a few minutes and 665 tests later it bombed on the ErrorsTag tests. It seems we (committers) have been making changes without running the test suite to ensure that everything is kosher. I wish I had the time to spend getting these back in order, but I just can't commit (no pun intended) to it right now. Thanks. Putting food on the table and spending time with your family is definately more important ! -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I extend a Struts tag?
Paananen, Tero wrote: Can somebody tell me which is the best way to do this? Oh boy :) There was a long discussion not so long ago about the problems with extending the tags (not limited to the Struts tags, btw) on this list. If you do want to extend a tag, try to use the nightly source distribution. It has been refactored some to improve this situation. You're stuck with copy-and-pasteing TextTag.doStartTag() into your new tag, then sprinkling your modifications in there. -TPP
[Short Term Plan] Struts to depend on Validator 1.1.0
Over 99% of commons-validator usage is through struts. In fact it may be 100%. I feel the only way to really promote commons-validator to Beta status is to make the nightly build of struts depend on the 1.1.0 version which has released in August and been designated an Alpha. I propose that this Sunday Sept 28 th that we switch over to the 1.1.0 version of Validator, then quickly release Version 1.1.1 which has had additional numerious improvements in it's Javascript validation. Othewise I honestly see how Validator 1.1.0 is ever going to get enough usage to ever be promoted to beta status. Reactions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Short Term Plan] Struts to depend on Validator 1.1.0
David Graham wrote: Only ActionError was deprecated, not ActionErrors. We still need to use ActionErrors because the ActionForm.validate() method returns an instance of that class. ActionMessage should be used instead of ActionError though. Eventually we'll need to add a method that will allow us to deprecate ActionForm.validate(), just as Action.execute() deprecated Action.perform(). The only reason I haven't done that is I couldn't think of a good name maybe valid(), validateForm(), doValidate(), checkFields(), checkForm() ... ??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
Yes, This has been brought up many times over the last 3 years, and probably has been implemented several times extending the Struts tags. I am not opposed to such a feature, and would support it, though other committers might not. The key argument against it is that it would transform the html tags into a non-standard implementation. The html tags are ment to be a thin module aware layer over the browsers tags, and nothing more. That is why we don't have a Calender tag or Date chooser tag. Though I suppose if you really --knocked our socks off !-- with a spiffy implementation it could become part of Struts. I believe since we still support Netscape 4.X series browsers, a read-only attribute has not been added. Since struts is trying to get out of the JSP tag business since 40-50% of our bugs are there. which subtracts from our limited time for the core framework. You might consider contributing the tag to http://struts.sf.net -Rob Chris Gastin wrote: Has anyone considered a feature which toggles between an editable form element and read only text / static text. I find myself developing JSPs where depending on the Use Case fieldA could be an editalbe text box (input name=fieldA value=My Text Value /) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2 (My Text Value) on the same jsp. Presently I am using the logic:equal/logic:equal tags. Which get really messy. Here is some sample code. logic:equals name=actionForm property=myFieldEditable value=true html:text name=actionForm propertymyField / /logic:equal logic:equals name=actionForm property=myFieldEditable value=false bean:write name=actionForm propertymyField / /logic:equal It would be nice to add an attribute to the current tag libraries, which is a boolean, and does this toggling for you. Here is what I am envisioning If actionForm.myField = My Text Value; This tag html:text name=actionForm propertymyField readOnlyText=true/ would output My Text Value. Where html:text name=actionForm propertymyField readOnlyText=false/ the following tag would output input name=fieldA value=My Text Value / As you can imagine this would not be a huge undertaking to add this feature to the current tag libraries in struts. I could use this feature, and I am sure other could too. I am willing to contribute my time to the development effort. I am not stuck on the attribute name readOnlyText, and would welcome suggestions. Does this sound like a good idea, and if the answer is yes, what is the next step. Chris Gastin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
Sgarlata Matt wrote: Has anyone ever discussed adding a general-purpose attributes attribute to the html tag library to support non-standard HTML like this? For example, Yes, it was vetoed by several committers. Search the archives. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: Yes, This has been brought up many times over the last 3 years, and probably has been implemented several times extending the Struts tags. I am not opposed to such a feature, and would support it, though other committers might not. The key argument against it is that it would transform the html tags into a non-standard implementation. The html tags are ment to be a thin module aware layer over the browsers tags, and nothing more. That is why we don't have a Calender tag or Date chooser tag. Though I suppose if you really --knocked our socks off !-- with a spiffy implementation it could become part of Struts. I believe since we still support Netscape 4.X series browsers, a read-only attribute has not been added. As you know, we don't support browsers we support standard specifications. Yes, and the decisions on what specfication to support relies largely on what browsers are out there. Since we last talked about this Mozilla 1.X has been released which supports the read-only attribute so users on Unix systems can benefit from its use. Best of all large slow moving corporations, Goverments, with Unix systems to support are moving Mozilla/Netscape 6.2 as a standard. So I it seems that having this workaround isn't as needed as it once was. Now if we could only get rid of all the JSP 1.1/Servlet 2.2 containers so struts can move to supporting JSP 1.2/Servlet 2.3.. -Rob The tags are coded to the XHTML 1.0 and HTML 4.01 standards which do support a readonly attribute on input fields. The html:text tag supports a readonly attribute which seems to be the easiest way to accomplish the requested feature. http://jakarta.apache.org/struts/userGuide/struts-html.html#text
Forking Struts taglibs[ was Re: Editable Fields V/S Static Text]
Edgar P Dollin wrote: If the tags were structured differently so they were easier to extend without breaking when new releases of struts come out these issues might not come up. Of course, I myself have resigned myself to this issue since the tags are such a political football on this list. Edgar If we aren't meeting a real need that you have, there is nothing stopping interprising developer(s) from forking the struts taglibs and hosting that on source forge. This is open source after all ! A little healthy competition is good. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
David Graham wrote:
--- Sgarlata Matt [EMAIL PROTECTED] wrote:
OK, here's another idea. I searched the archives for it and couldn't
find
it.
How about two simple changes:
1) Add a new renderExtraAttributes() method that gives people the chance
to
throw non-standard HTML into their tags that extend from Struts tags.
I am -1 on the Struts tags supporting any non-standard HTML including
providing the suggested hook method. Like Java itself, Struts aims to be
a cross-platform tool. Adding support for non-standard HTML undermines
that goal and promotes non-interoperability.
Is it really the Struts tag library's mantra to dictate that the tags
should not be modified
externally to gain needed functionality ? By not providing hooks,
wheather these are the
correct ones or not, isn't very developer friendly. A framwork can be
developer friendly,
and well designed at the same time.
And It's not that the tags would be producing non standard HTML 4.01,
it's that they would/could
add composite functionality over and above standard HTML that would
still be 4.01 compliant.
I agree with what several other committers, that if developers want to
step up
and show that they will help support those tags I'll vote for the
ability to support these abilities,
inside the struts tags not just the hooks.
-Rob
I can't count the number of times I've been frustrated by webapps that
require a particular browser that I'm not using. I absolutely don't want
one of my favorite tools to support that kind of development.
Here
is a snippet from BaseFieldTag.java:
snip
results.append(\);
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());
matts-idea
results.append(renderExtraAttributes());
/matt-sidea
return results.toString();
/snip
The use cases for this are (a) to support the readonly attribute and
At least the html:text tag already supports readonly. Are there other
tags (where readonly is allowed) that are missing it?
http://jakarta.apache.org/struts/userGuide/struts-html.html#text
David
(b)
to
support the attributes extension that was shot down for inclusion in
the
out-of-the-box Struts html tags.
2) Instead of accessing instance variables directly, use getters. (I'm
not
sure if this will cause problems with the EL versions of tags...
thoughts
anyone?)
snip
if (accept != null) {
results.append( accept=\);
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append(\);
}
/snip
If someone wanted to override the accept attribute so that it was always
equal to foo then they would be able to do so. A better use case would
be
overriding the onclick method so that it does something special like
display
a calendar popup.
I apologize in advance if this has been discussed before. ([OT] I
really
wish there was an easier way to search the archives. I have resorted to
googling them, but it's still a pain.)
Matt
Re: Editable Fields V/S Static Text
Chris Gastin wrote: Rob: I am not an contributer, but I am a young developer. I am willing to step up and support these abilities in the struts tags Great ! I have come to believe that young/single developers older/grown kids/empty nesters developers are better situated to be Open Source developers. The guys with a families don't seem to have as much free time. So do what you have time for and enjoy the process, you'll learn allot ! Chris Gastin -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide installation.xml
[EMAIL PROTECTED] wrote: Index: installation.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/installation.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- installation.xml 9 Sep 2003 17:49:18 - 1.33 +++ installation.xml 11 Sep 2003 09:49:37 - 1.34 @@ -35,7 +35,8 @@ a Java2 (version 1.2 or later) Java Development Kit implementation for your operating system platform. A good starting point for locating Java Development Kit distributions is - a href=http://java.sun.com/j2se;http://java.sun.com/j2se/a./li + a href=http://java.sun.com/j2se;http://java.sun.com/j2se/a. + To build Struts, Java 1.4.2 or later is recommended. /li Why was 1.4.2 specified ? It builds fine with 1.3.1, 1.4.0 1.4.1, just tried it. It sounds like it won't work with the other JDK's, could we soften this ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What happened to the taglib attribute listings?
Steve Raeburn wrote: I've posted a patch to the struts.xsml stylesheet. Ted could you do the honours? BTW, I'm not sure what needs to be done to update the live site and if it's something I could or should be doing. I'd be happy to make the updates if someone lets me know how. The site docs talk about using CVS to update. And most of the apache sites, www.apache.org, xml.apache.org, ... do look like they use CVS, since there are CVS directories under those directories. However, very few of the jakarta.apache.org web sites look like they use use CVS, no CVS directories, except for, struts-el So I would say just use 'scp' to send the war file over, an unzip. For the longest time I was e-mailing my self stuff, cause I hadn't read all the docs :-} ! -Rob Steve -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: September 11, 2003 12:03 PM To: Struts Developers List Subject: RE: What happened to the taglib attribute listings? I'll take a look at this now. I'm sure it's nothing major. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: September 11, 2003 11:48 AM To: Struts Developers List Subject: Re: What happened to the taglib attribute listings? If it's not something we can fix right away, I'll post a copy from an earlier build. David Graham wrote: That's a definite bug in the build. Those pages are worthless without the attribute descriptions. David --- Kris Schneider [EMAIL PROTECTED] wrote: The tag doco pages,I'll tak a look at this for example: http://jakarta.apache.org/struts/userGuide/struts-html.html used to include tables listing each of the tags' attributes. Was there a conscious decision made to remove that information or is there just some bug in the build? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What happened to the taglib attribute listings?
Ted Husted wrote: Right now, we use scp to either send up the files or a WAR to burst. This requires karma to jakarta.apache.org, which root no longer hands out as a matter of course, but should be available for the asking. Every thing was moved to ONE machine minatar (sp ?), cvs, web site etc... It's no longer necessary to have access to multiple machines. Just scp to cvs.apache.org. The Jakarta site2 project uses a system where you can checkout the HTML pages from CVS, but that still requires access to j.a.o. -Ted. Robert Leland wrote: Steve Raeburn wrote: I've posted a patch to the struts.xsml stylesheet. Ted could you do the honours? BTW, I'm not sure what needs to be done to update the live site and if it's something I could or should be doing. I'd be happy to make the updates if someone lets me know how. The site docs talk about using CVS to update. And most of the apache sites, www.apache.org, xml.apache.org, ... do look like they use CVS, since there are CVS directories under those directories. However, very few of the jakarta.apache.org web sites look like they use use CVS, no CVS directories, except for, struts-el So I would say just use 'scp' to send the war file over, an unzip. For the longest time I was e-mailing my self stuff, cause I hadn't read all the docs :-} ! -Rob - 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: XHTML Web site updates
David Graham wrote: Contributors List I think it's important to keep the contributors list on those pages because it's a recognition of volunteers' effort. I agree that it gets in the way so maybe the list should be at the bottom of the page in a smaller +1, absolutely it's through those patches and code contributions that keeps Struts going sometimes. font. It would also be nice if it wasn't one long list of names but had columns to make it shorter. That is probably easier said than done though. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Saving messages in the session
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: Use Cases: I am not familar with the particular use cases where the ActionMessage needs to hang around in the session. So these suggestions might not fit. The main reason I've seen on the user list (and the reason I need it) is to redirect to a success/error page and display messages. Storing them in the request only works for forwards. Questions: Would managing the life cycle through the struts-config.xml, like the ActionForm work ? Maybe, do you have more details on this idea? or How about a PlugIn that has the ability to schedule a cleanup of a session variable after a configurable amount of time ? The method that reads the message from the session would need to be syncronized. This doesn't have to be a plugin. This gave me a different idea. What if the ActionMessages had a used flag that is set to true the first time its messages are accessed. The RequestProcessor would have a new processCachedMessages method that would check the flag and remove from the session as needed. This seems more responsive than a periodic cleanup and we wouldn't have to cache HttpSession objects which may not be safe/legal. Also, I think placing the cleanup in the RequestProcessor guarantees that it is performed rather than relying on Actions to do the cleanup. That is MUCH simpler and RESPONSIVE than the scheduler ! So we are consistent on the 'state' flag names like -used- Bug 18022, talked about wrapping the ActionForm with another class when it was returned from the createActionForm method. It would have two attributes: -recycled-, and ActionForm. It would be nice if the terms -used-, and -recycled- fit a theme. Since the code hasn't been written yet, your at liberty to pick that theme. -Rob Comments? David -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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: XHTML Web site updates
It also works for me. From a CVS update. I am using Xerces 2.5/Xalan 2.5 JDK 1.4.2_01 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java
[EMAIL PROTECTED] wrote:
David,
I thought you were going to back this out ?
-Rob
dgraham 2003/08/19 16:20:46
Modified:src/share/org/apache/struts/action Action.java
Log:
Added version of saveMessages() that saves them into the session
instead of the request.
Revision ChangesPath
1.67 +33 -8 jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- Action.java 2 Aug 2003 21:12:16 - 1.66
+++ Action.java 19 Aug 2003 23:20:45 - 1.67
@@ -431,15 +431,16 @@
}
-
/**
* Save the specified messages keys into the appropriate request
* attribute for use by the lt;html:messagesgt; tag (if
* messages=true is set), if any messages are required. Otherwise,
* ensure that the request attribute is not created.
*
- * @param request The servlet request we are processing
- * @param messages Messages object
+ * @param request The servlet request we are processing.
+ * @param messages The messages to save. codenull/code or empty
+ * messages removes any existing ActionMessages in the request.
+ *
* @since Struts 1.1
*/
protected void saveMessages(
@@ -454,9 +455,33 @@
// Save the messages we need
request.setAttribute(Globals.MESSAGE_KEY, messages);
-
}
+
+/**
+ * Save the specified messages keys into the appropriate session
+ * attribute for use by the lt;html:messagesgt; tag (if
+ * messages=true is set), if any messages are required. Otherwise,
+ * ensure that the session attribute is not created.
+ *
+ * @param session The session to save the messages in.
+ * @param messages The messages to save. codenull/code or empty
+ * messages removes any existing ActionMessages in the session.
+ *
+ * @since Struts 1.2
+ */
+protected void saveMessages(
+HttpSession session,
+ActionMessages messages) {
+
+// Remove any messages attribute if none are required
+if ((messages == null) || messages.isEmpty()) {
+session.removeAttribute(Globals.MESSAGE_KEY);
+return;
+}
+// Save the messages we need
+session.setAttribute(Globals.MESSAGE_KEY, messages);
+}
/**
* Save a new transaction token in the user's current session, creating
-
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: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java
David Graham wrote:
--- Robert Leland [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
David,
I thought you were going to back this out ?
The conversation was left with me proposing a solution and asking for
Martin's thoughts on it. He hasn't responded so I haven't backed it out.
Saving messages in the session is a commonly requested feature (and one
that I need) so I think it needs a solution.
If the solution can automatically clean up after itself, no matter what
scenario that is thrown at it, then I am +1.
If there is *--any--* usecase where the session can be left with the
messages still in the session, then I am -1.
What ever goes into the session must be explicitly managed, which is
usually handled from
the struts-config.xml, such as the ActionForm lifecycle.
-Rob
Action.saveMessages() that
saves them in the session is part of that solution. The other, is a class
I wrote called SingleUseActionMessages that only returns its messages one
time. I can commit SingleUseActionMessages if it's needed or we can come
up with a better solution.
David
-Rob
dgraham 2003/08/19 16:20:46
Modified:src/share/org/apache/struts/action Action.java
Log:
Added version of saveMessages() that saves them into the session
instead of the request.
Revision ChangesPath
1.67 +33 -8
jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- Action.java 2 Aug 2003 21:12:16 - 1.66
+++ Action.java 19 Aug 2003 23:20:45 - 1.67
@@ -431,15 +431,16 @@
}
-
/**
* Save the specified messages keys into the appropriate request
* attribute for use by the lt;html:messagesgt; tag (if
* messages=true is set), if any messages are required.
Otherwise,
* ensure that the request attribute is not created.
*
- * @param request The servlet request we are processing
- * @param messages Messages object
+ * @param request The servlet request we are processing.
+ * @param messages The messages to save. codenull/code or
empty
+ * messages removes any existing ActionMessages in the request.
+ *
* @since Struts 1.1
*/
protected void saveMessages(
@@ -454,9 +455,33 @@
// Save the messages we need
request.setAttribute(Globals.MESSAGE_KEY, messages);
-
}
+
+/**
+ * Save the specified messages keys into the appropriate session
+ * attribute for use by the lt;html:messagesgt; tag (if
+ * messages=true is set), if any messages are required.
Otherwise,
+ * ensure that the session attribute is not created.
+ *
+ * @param session The session to save the messages in.
+ * @param messages The messages to save. codenull/code or
empty
+ * messages removes any existing ActionMessages in the session.
+ *
+ * @since Struts 1.2
+ */
+protected void saveMessages(
+HttpSession session,
+ActionMessages messages) {
+
+// Remove any messages attribute if none are required
+if ((messages == null) || messages.isEmpty()) {
+session.removeAttribute(Globals.MESSAGE_KEY);
+return;
+}
+// Save the messages we need
+session.setAttribute(Globals.MESSAGE_KEY, messages);
+}
/**
* Save a new transaction token in the user's current session,
creating
-
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]
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: David, I thought you were going to back this out ? The conversation was left with me proposing a solution and asking for Martin's thoughts on it. He hasn't responded so I haven't backed it out. Saving messages in the session is a commonly requested feature (and one that I need) so I think it needs a solution. If the solution can automatically clean up after itself, no matter what scenario that is thrown at it, then I am +1. If there is *--any--* usecase where the session can be left with the messages still in the session, then I am -1. What ever goes into the session must be explicitly managed, which is usually handled from the struts-config.xml, such as the ActionForm lifecycle. I know of two options: 1. Add a remove attribute to html:messages so it will remove the messages when it's finished rendering. 2. Use something like SingleUseActionMessages which will remain in the session until overwritten but will only return messages once. Option 1 wasn't popular under the tags-shouldn't-alter-session-state philosophy. Option 2 does leave the messages in the session but they're harmless after the first use. I don't care which one we go with but storing messages in the session *is* a needed feature so we do need a solution. It is quite cear from what Martin stated that option 2 also does meet the requirements, nor mine. Until a satisfactory solution can be enginered the method needs to be removed* , now.* There have been two -1's on this. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Saving messages in the session
Use Cases: I am not familar with the particular use cases where the ActionMessage needs to hang around in the session. So these suggestions might not fit. Questions: Would managing the life cycle through the struts-config.xml, like the ActionForm work ? or How about a PlugIn that has the ability to schedule a cleanup of a session variable after a configurable amount of time ? The method that reads the message from the session would need to be syncronized. This doesn't have to be a plugin. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts web site [was: Re: Conversion of web site docs to XHTML]
Ted Husted wrote: Joe Germuska wrote: It will be some mildly tedious work to move the current doc to xdocs, but nothing too bad, and if they are valid xhtml, it will be much easier. The documentation is all XML now. Steve was just tweaking the XLS. There's a bit of HTML/XHTML in the sample applications, but that's trivial and probably wouldn't be a Maven issue anyway. Yes but most likely the some of the element names would need to change, or we write an XSLT to translate. I would vote to rename the elements. In the interm we could modify our stylesheets to look for the new element names. I'm no expert, but I'll be happy to help where I can. It can be a little frustrating to push an existing CVS structure into Maven conventions (I tried to do it for SnipSnap and really got stuck, but their build is pretty funky.) It's a breeze when you start fresh (like maybe Struts 2.0...) So it sounds like that since Maven is also a build tool, we not only have to address the web site/documentation content but bring CVS in line. I more an issue of setting the right variables in project.xml. I have already set the source and test xml variables I am strongly in favor of moving to maven now, and will help where I can. The effort involved is much less than adding many of the features listed for Struts 2.0 Unless someone is of the opinion that moving the Struts CVS to Maven conventions is a no-brainer, perhaps the consensus should be to consider Maven for any *new* Struts product installations (CVS/website combinations). This could include + A new CVS/website for the taglibs + A new CVS/website for Struts 2.x (which is now just a roadmap) So, given either or both of these, the Struts home page could become a simple portal that links to our products (1.x core, taglibs, 2.x roadmap). Once we got started on Maven using fresh meat, we could then make a informed decision about whether to migrate the Struts 1.x core. Meanwhile (assuming the 1.x CVS is an issue), if someone were interested in moving the 1.x documentation to Forrest, I wouldn't be opposed. -Ted. (Just a random thought, would either Maven or Forrest care that how we generate the taglib API documentation from the TLDs?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts web site [was: Re: Conversion of web site docs to XHTML]
Robert Leland wrote: Steve Raeburn wrote: I have committed the first step in transitioning the web site documentation to valid XHTML. As far as I know we were planning to move over to Maven or forrest. I have been working on Mavenizing items as I can. Instead of doing the stylesheets maybe your efforts could be directed towards integrating those xml docs into maven ? Do we want to hold a formal vote/lazy consensus on what doc system we are moving to ? I would go with Maven only because it provides a number of usefull reports. I don't care for the standard Maven look, but believe it's better than what we have. My main concern is to make sure whatever we pick Maven/Forrest that it's around and thriving a year from now. maven is very active but they also seem to be going through a large refactoring to reduce the memory footprint. Forrest is supposed to be slower and a bigger memory foot print, but I could care unless about that if it doesn't crash my JVM. The struts site now builds with a basic maven look, maven beta 10. We just need to hook in the doc xml which shoudln't be too bad, since there is a stylesheet directory under xdocs. If you take a look at those wild and crazy Tapestry guys it looks like you can really hack the look and feel to anything you want. -Rob - 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: Struts web site [was: Re: Conversion of web site docs to XHTML]
Craig R. McClanahan wrote: On Sat, 6 Sep 2003, David Graham wrote: Date: Sat, 6 Sep 2003 10:55:26 -0700 (PDT) From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts web site [was: Re: Conversion of web site docs to XHTML] --- Ted Husted [EMAIL PROTECTED] wrote: Robert Leland wrote: Do we want to hold a formal vote/lazy consensus on what doc system we are moving to ? Don already put the Struts SourceForge site on Forrest, so I would lean in that direction. Does Forrest require that look and feel? If so, I'm -1 only because it doesn't match the new Jakarta look and feel. I think Struts should fit in with other Jakarta sites. Also, it seems like most other Jakarta projects are using Maven so maybe we should too. Strictly from the selfish point of view of a developer wanting to minimize how many tools I have to use, I'd prefer Maven over Forrest simply because it's also a build system. Or, to put it anothe way, using Maven as a build system will give us a website/docs publishing system for free. +1 free is good Visually, I'm not a huge fan of either system's default LF, but I don't dislike either of them enough to vote -1 on that basis. My understanding is that there is some room for customization with either, though, if we wanted to expend the effort to manage our own LF. We can always start a struts-2 web site and tweak it until we like what we have, or until it works, which ever comes first ! I also wouldn't want to maintain a seperate look and feel except to move the blasted [powered by Maven] icon to the bottom of the page with other icons like in forrest. The argument for consistency with other Jakarta subprojects is good in theory, but I don't see most Jakarta subproject websites using either yet -- at least for their pages on jakarta.apache.org. It would also not be an issue if we ever wanted to become a top-level Apache project (like Maven and Ant did), versus staying under Jakarta. David 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]
Re: Struts web site [was: Re: Conversion of web site docs to XHTML]
Joe Germuska wrote: At 14:23 -0400 9/6/03, Robert Leland wrote: We can always start a struts-2 web site and tweak it until we like what we have, or until it works, which ever comes first ! I also wouldn't want to maintain a seperate look and feel except to move the blasted [powered by Maven] icon to the bottom of the page with other icons like in forrest. You can turn off the blasted icon by setting the property maven.xdoc.poweredby.image to an empty string (for instance, in the project.properties file. I've had trouble otherwise controlling the structure of that part of the generated docs (except the easy part of adding navigation.xml). Joe Joe: Thanks, I was hoping you would chime in ! It looks like you used maven for your site, and I prefer your color scheme over the standard... -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why are ImportAttributeTag and UseAttributeTag final classes?
David M. Karr wrote: Is there a good reason for the tiles classes ImportAttributeTag and UseAttributeTag to be final classes? I can't implement tiles-el if those are final classes. +1, for removing final. Since struts is a framework there is no good reason for marking a class as final. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Site + Joe Germuska+ Maven
Joe Germuska wrote: At 14:53 -0400 9/6/03, Robert Leland wrote: Thanks, I was hoping you would chime in ! It looks like you used maven for your site, and I prefer your color scheme over the standard... You can set a lot of stuff in project.properties -- it should be in a source distribution for jgs-struts, or I'll be happy to send what we use. I'm no expert, but I'll be happy to help where I can. It can be a little frustrating to push an existing CVS structure into Maven conventions (I tried to do it for SnipSnap and really got stuck, but their build is pretty funky.) It's a breeze when you start fresh (like maybe Struts 2.0...) It will be some mildly tedious work to move the current doc to xdocs, but nothing too bad, and if they are valid xhtml, it will be much easier. Please let me know if there's anything else I can help with; I'm not an expert, but we've been whole-hog on Maven here at work for about six months and we're pretty happy with it. If I miss anything here on the list, it's because I'm building towards an end-of-month deadline, but I should see direct mail as long as my spam filter doesn't go haywire... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts web site [was: Re: Conversion of web site docs to XHTML]
Steve Raeburn wrote: I have committed the first step in transitioning the web site documentation to valid XHTML. As far as I know we were planning to move over to Maven or forrest. I have been working on Mavenizing items as I can. Instead of doing the stylesheets maybe your efforts could be directed towards integrating those xml docs into maven ? Do we want to hold a formal vote/lazy consensus on what doc system we are moving to ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
Steve Raeburn wrote: I'm not singling Vic out for this (honest) but... The standard advice we are now giving everyone is use JSTL, which I wholeheartedly agree with and have said myself. However, I think we need to make sure that we still adequately support non-JSTL solutions and continue to consider bug fixes/enhancements to Struts tags EVEN where it would duplicate JSTL functionality because Struts still supports JSP 1.1/Servlet2.2. I haven't considered whether this particular enhancement would fall into the category of something we should do, it just prompted me to raise the issue. If we've reached the stage where the recommendations we are making *require* JSTL, then I think it's time to be honest about the required platform for Struts and up it to 1.1/2.3. I agree the html/logic/bean tags are still supported just not actively enhanced, unless a patch is supplied. Also is the change is simple that would aid in debugging, or the ability of a user to extend a tag if they are in a Servlet 2.2/Jsp 1.1 world. Thoughts? Steve - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 22519] - Allow multiple MessageResourcesfiles to be loaded under one key
Craig R. McClanahan wrote: Vic, Please go away. I didn't take this as being negative, just an effort to help Ted. I did get upset when the status was changed to WONTFIX for some items. It --did-- get me to read the Bugzilla request which I see as a positive. There are a number of good patches in there that I didn't even know about. forums, and enjoyed laughing at you. But I'm absolutely NOT going to put up with YOU thinking you have any RIGHT to change the status on Struts bug reports and enhancement requests. There is one exception and that is if someone has tested a bug and found it --not-- to be a problem then I believe --anyone-- has the right, even the resposability, to label it WORKSFORME. Again I saw it as trying to be helpful, and contribute. -Rob
Re: [OT] As the Struts world turns [was: Re: DO NOT REPLY [Bug 22519] - Allow multiple MessageResources files to be loaded under one key]
James Mitchell wrote: Someone posted a link on another thread that might actually help in situations like this: http://www.originalicons.com/smile Not funny. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [ANN] Commons-Validator 1.1.0 Alpha released]
Commons Validator 1.1.0 Alpha is now available for testing. Please refer to http://jakarta.apache.org/commons/validator/tasks.html that details some of the changes that have taken place since the 1.0.2 release. Downloads: http://jakarta.apache.org/~rleland/ValidatorAlpha/ be sure to update your validator*.xml files. Just a reminder : The release process is following the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL EL Validator rule: A better requiredif and validatewhenusing JSTL
Rick Hightower wrote: What were your thoughts on JSTL EL validator rule? You commented on BSF and OGNL, but not the JSTL EL validator rule, which I actually wrote. The others just seem like a good idea. Sorry, For not commenting on that. I agree that a JSTL EL expression makes sense. For now struts 1.X is still JSP 1.1 based: 1) Assuming the other committers agree, and I like what I see, add the tag to the contrib folder. If this tag targets JSP 2.0 then it would need to go into it's own folder. 2) Donate the tag to the struts.sf.net site. speculation At some point Struts 1.5.X, wildly pulling number out of air, or so --may-- go to 1.2/2.3 specs. I believe this because there is now talk of basing Struts 2.X on JSP 2.0. This spec is even further way from general adoption than 1.2/2.3, so I believe it would be better to start the move in the 1.5 time frame. OR... Do abopt JSP 1.2/2.3 in the Struts 2.X series and JSP 2.0 in Struts 3.X series. /speculation -Rob
Re: [OT] I didn't realize we had a celebrity
James Mitchell wrote: Did you guys check out the full page add that Oracle ran in the JDJ? Oh My God I don't get the Attendee Since 2002 though, why he keeps coming back. He hasn't come back yet ! :-/ ! They just wanted a pretty face !!! -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: design - tags with errors
Paul Sundling wrote: It's my bad. It looks like there is not a problem with the options tags. The real problem is that I included a jsp in the page where I was getting the exception. So in simplist terms: jsp:include page=/includes/largeEnough.jsp/ bean:message key=key.that.causes exception.because.it.does.not.exist/ following html and bunch of stuff... So when I get a blank page, I just have to comment out the include to see the errors. Sorry for the false alarm. Paul Thanks for the offer of a patch ! -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tags more extensible (was: Suggestions for Calendar Popup taglib?)
Replyied Inline.
Paananen, Tero wrote:
[this is in response to Robert Leland's reply to my
post on the struts-user list griping about the
(un)extensibility of custom tags]
My #1 pet peeve about custom taglibs are that almost
none of them have been designed with extensibility in
mind. This includes all the Struts tags that I've had
to tinker with.
Extending them basically means, more or less,
copy-and-pasteing all the existing code into your new
taglib, then customizing the behavior to meet your
needs.
Tero:
Your insight into how the Struts Tags can be made
more Modular so they can be extended easier would be very
valuable and welcome.I encourage you can bring the issue
up on the struts-dev list.
Robert,
From what I've seen most custom tags seem to have been
implemented as one big doStartTag() or doEndTag(). The
entire implementation of the tag is in that one method.
In order to modify the behavior, more often than not,
the only way to do this, is to completely rewrite that
method by copy-and-pasting the old implementation into
your new tag, modify it slightly and be done with it.
The only reuse comes with the getters and setters for
the tag's properties.
This approach to extending breaks the minute a new
release of your base tag changes significantly. You
either have to redo your extended tag based on the new
release or leave your extended tag as is, and potentially
leave bugs in that were fixed in the new release.
I've had some limited success with tags that implement
doStartTag() (and/or doEndTag() in more discreet steps:
// method names and (non-existing) return types
// purely illustrative
public int doStartTag() throws JspException {
doStart();
doStep1();
doStep2();
doEnd();
}
This way you can overload only the method that deals
with whatever you need to modify and leave everything
else as is.
If you also had pre- and post-processing methods for
every discreet step in the process, you'd have even
more flexibility:
// method names and (non-existing) return types
// purely illustrative
private String doStep1() {
preDoStep1();
// step 1 implementation here
postDoStep1();
}
Hopefully you see where I'm going with this. The pre-
and post-processing methods could be implemented to
skip, ignore, modify, etc. the implementation of the
real method.
I haven't done anything like this with custom tags
myself, but I've used a few products (ATG Dynamo comes
to mind first) that use this sort of architecture in
the entire application, and it's extremely flexible.
I realize that doing something like this would probably
have a performance impact and would most likely be overkill
for everyone but that one screwed up developer that needs
to modify every tag he gets his hands on, but as far as
extensibility goes, something like this would greatly
improve on how custom tags can be extended, IMHO.
I doubt there would many any notiable impact on performance.
I'm sure people on the list who have far more experience
than I do with writing taglibs, and application architectures
in general, will see lot of things wrong with this approach
and can come up with something better, but as someone who
has had to extend a somewhat large number of custom tags
(Struts and otherwise), I'm completely fed up with the
copy-and-paste codeing I'm forced to do right now.
I feel your pain as one ex-U.S. President once said.
What say ye, oh Struts gods (and goddesses)? :)
I agree totally, at the level were currenrly arguing, I dare anyone to
disagree !
A good way to tackle this is Use Case by Use Case, to avoid talking in
general terms.
1) What specific tags have you or do you want to modify the behaviour of.
2) What level of granularity makes sense.
3) Do we use simple overriding, or publish/subscribe or Decorator
Pattern, others.
I would start off by recommending the Decorator pattern. I believe
this is what
David Karr did when adding JSTL functionality to Struts.
-TPP
-Rob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Robert Leland [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: design - tags with errors
Paul Sundling wrote: After rereading it again I think I should clarify one of my comments: Even generating nothing would seem to be prefereable! What I meant by that is the tag itself generating nothing (resulting in an empty select list) as opposed to the entire page generating nothing(current behavior). That would be very much appreciated. You can file a Bugzilla report with your patches attachment. I was wondering what the general design philosophy for errors inside custom tags is. I've noticed that when there's a problem with html:option*, instead of giving a useful error message, it would just fail to display anything (clean white page).Is that the desired result? I'd be willing to modify the class to use error messages instead of crashing the page, if I'm not the only one who finds that desirable. Even generating nothing would seem to be prefereable! (Pointing me to a tag with the kind of preferred error handling that I should emulate would be useful.) Paul Sundling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameter vs. set-property (was Re: Flexible form support)
Sgarlata Matt wrote: Ted Husted wrote: IMHO, the general purpose parameter has been a useful feature of ActionConfig/ActionMapping and is worth applying elsewhere. We just have to be quick to remind people that if they outgrow the general purpose parameter, then they should start extending the base object and using set-property. (As people often do now.) I agree; set-property is my favorite Struts extension point :) However, I would like to point out that it doesn't work very well for the message-resources element. The reason for this is that set-property populates a MessageResourcesConfig object instead of the actual MessageResources object. Then in the ActionServlet, when the MessageResources object is initialized it is passed the parameter information but is not passed any set-property information: // here the resources are created, and passed the parameter MessageResources resources = factoryObject.createResources(mrcs[i].getParameter()); // here the resources are passed the return null info resources.setReturnNull(mrcs[i].getNull()); //!! here I think we should pass the MessageResourcesConfig getServletContext().setAttribute( mrcs[i].getKey() + config.getPrefix(), resources); What do you think? Would this be a reasonable enhancement request? Can I post it in BugZilla with patches? Since you have talked about it on the struts-user group, and it looks like the existing system makes your life harder, then open a Bugzilla request. What ever committer looks at the bug request will determine if the patch will be applied or modified. [Patches] are always welcome and speed the process ! If possible patch against the current HEAD of struts source code. Use the diff -u old new. I also like to use 'diff -u 5 old new' just to be sure. -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameter vs. set-property (was Re: Flexible form support)
Sgarlata Matt wrote: Robert Leland wrote: Sgarlata Matt wrote: What do you think? Would this be a reasonable enhancement request? Can I post it in BugZilla with patches? Since you have talked about it on the struts-user group, and it looks like the existing system makes your life harder, then open a Bugzilla request. What ever committer looks at the bug request will determine if the patch will be applied or modified. [Patches] are always welcome and speed the process ! If possible patch against the current HEAD of struts source code. Use the diff -u old new. I also like to use 'diff -u 5 old new' just to be sure. I've never used CVS before so I don't know what you mean. What is the current HEAD of struts source code mean? HEAD/CVS The HEAD means the most current version of source code of by default the TRUNK. This source can be downloaded from http://cvs.apache.org/builds/jakarta-struts/nightly/src/ IF I had said 'submit patches against the HEAD of the STRUTS_1_1_BRANCH, then you would have to use CVS directly to get to this source. The Mozilla site has a nice graphic http://www.mozilla.org/roadmap/branching-2003-06-24.png of Trunks and Branches. So if you would like provide patches against the most recient source code, http://cvs.apache.org/builds/jakarta-struts/nightly/src/ You can use the commons jars found in the struts nightly build found at the binary is at http://cvs.apache.org/builds/jakarta-struts/nightly to build and test your patches. If you haven't built struts before the only file you'll need to modify is the build.properties file which just a copy of the build.properties.sample file. The Jakarta site says cvs diff -u Main.java patchfile.txt is preferred. Can I use that instead? DIFF If you are NOT using CVS then you'll need to use the command diff -u 4 file1.old.java file1.new.java file1.diff IF you are using windows then you'll need to install Cygwin to get the 'diff' program. If you are using are using CVS then I yes use the cvs diff -u 4 file1.java file1.diff command. -Rob -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is the next release?
David Graham wrote: --- Ted Husted [EMAIL PROTECTED] wrote: AFAIK, the consensus is that our releases should follow the same general process used by the Jakarta Commons and the Apache HTTP Server project. So, for reference, I'm following http://httpd.apache.org/dev/release.html and http://jakarta.apache.org/commons/releases/ but observing the HTTPD numbering system. Right now, I intend to post a Release Plan for majority approval, either late tonight or early tomorrow. This Plan would include when we plan to roll the initial Alpha release. (I may even decided just to roll a release and post that along with the Plan.) We'd then vote whether to upgrade 1.2.1 from Alpha to Beta or General Availability (GA). Since there are any burning reasons to ship this instantly, I'm taking it as a foregone conclusion that this first roll will be at least a Beta. I'm confident that there are not any serious problems that prohibits its use, so I don't believe it will not remain an Alpha. But, I do suspect that there may be problems with this release that prohibit its widespread adoption -- even if it simply documenting what to do now that X is deprecated. So, I was calling it a Beta release. We already documented this in the 1.1 @deprecated tags. I don't think we need more documentation on the deprecations. David We need to document the every removed method and class, at least in the release notes. Once the deprecated methods/classes are taken out there is not a bread crumb trail to follow and it will cost use more work answering questions on the users list than if we document it to start with. That way when they don't read the release notes we can cut and paste the URL to the release notes. Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of twonew actions)
Steve Raeburn wrote: I *think* we agreed to add this action. Pick a name. [ ] ParameterDispatchAction [X] MappingDispatchAction [ ] ConfigDispatchAction -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource Bundle Prototyping
adam kramer wrote: On Wed, 6 Aug 2003, Joe Germuska wrote: I'm pretty sure this was an explicit design intention, although the main reason may have been to make backwards compatibility more manageable (or maybe not -- I can't cite any place where this was discussed; I just have vague recollections). From reading the lists, it's clear that many people intuitively expect modules to be less walled off from each other. Maybe a smarter Modularization, but one which might break some compatibility, could be targetted for a 1.5 release, or some mid-point between 2.0, which has a lot of bigger changes marked for it. I am going to make an effort to look through the archives and find the reasoning behind the design of the current modules (unless someone out there can enlighten us all). And explore the code and docs to come up with some ideas for application-wide module features that won't break struts conventions, etc... The modules would be much more useful to me if they had a concept of application and module. There were some thoughts about module inheritance that were discussed last summer. To my knowledge though no real design work has been done. It does seem that resource inheritance is the #1 requested feature. There may be a Bugzilla enhancement request ticket on this. -Rob -adam k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is the next release?
Ted Husted wrote: Just a head's up. I'd like to draw up a Release Plan tomorrow for Struts 1.2 beta 1. I'd like to get this out so people can start migrating to the non-deprecated Struts 1.1+ (for lack of a better term) *before* we get into the Commons Resources thing. Since we did so much backward-compatiblity work on Struts 1.1, getting the deprecations out of some of the older code will be no small task for some people, but the sooner we get the community started on this, the better. If anyone else would like to be the Release Manager, please feel free to chime in. I'd be happy to pass the baton once the plan is in place. Are we going to take the struts-legacy out this build or remove it for 1.3. If so then the data source code will need to be removed, before the beta. Beta implies a stable interface. Also I thought we were going to do away with alpha/beta/RC anyway. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc volunteers.xml
[EMAIL PROTECTED] wrote: sraeburn2003/08/09 19:07:34 Modified:doc volunteers.xml Log: Added myself Revision ChangesPath 1.27 +10 -0 jakarta-struts/doc/volunteers.xml Index: volunteers.xml === RCS file: /home/cvs/jakarta-struts/doc/volunteers.xml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- volunteers.xml 30 Jul 2003 03:43:38 - 1.26 +++ volunteers.xml 10 Aug 2003 02:07:34 - 1.27 @@ -144,6 +144,9 @@ li Kurt Post /li +li +Steve Raeburn +/li /ul @@ -287,6 +290,9 @@ li Phil Steitz /li +li +Steve Raeburn +/li /ul /section @@ -341,6 +347,10 @@ li bJames Turner/b (turner at blackbear.com) +/li + +li +bSteve Raeburn/b (sraeburn at apache.org) /li /ul Also edit the maven project.xml for developer entries. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When is the next release?
Craig R. McClanahan wrote: Another thing Remy does for Tomcat (which I *really* appreciate) is keeps a running change log (summary, not detailed) in the release notes for each version. That way, everyone can get a quick summary of what's changed. I'd like this kind of thing to be part of the release manager's responsibilities. Maven generates a change log and so does the perl script cvs2cl.pl (www.red-bean.com/~kfogel/cvs2cl.shtml, I have been thinking about struts next release and the need to document the ripped out methods etc. I started to experiment with these last week. It produces a GNU style changelog. I can help out in generating it. -Rob To ensure that two us don't start rolling a release at once, it's prudent to announce your intentions first. Depending on how formal you want to be, that announcement might be dubbed a Release Plan. But the only thing that matters is whether the release you roll passes a Majority Vote to move it from Alpha to Beta or GA. At least that's how I understand it =:0) Sounds good to me. Since this release is not backwardly compatible with 1.1.x, having removed all those deprecations, we are moving to the 1.2.x release series. Until something compels us to go on to the 1.3.x series, we can make be as many General Available releases in this series as we need. The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure, but I believe the GA release before .27 was .24: .25 and .26 didn't make the GA cut. Yep -- the ones that did were 4.1.6, 4.1.12, 4.1.18, and 4.1.24. The fact that it was every six is mostly coincidence and was caused by a large amount of refactoring work going on. One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I had thought it would be 1.2.0, but Martin and Craig seem to be saying we should start with 1.2.1. Being a geek, my natural inclination was to start with zero. =:0) I'm a zero-relative guy at heart :-). My only concern is that people will assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or 1.2.1. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] for bug nr. 21408
Radek Wisniewski wrote:
Hi,
I send patches for bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=21408
Could you attach them to the bug report ?
If you don't have a BugZilla account, it is easy to create. It takes
only 20 seconds.
-Rob
One patch in RequestProcessor saves errors in sesion in case of
redirection.
Patch for TagUtils reads errors from request or reads and removes from
session.
Index: RequestProcessor.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java,v
retrieving revision 1.32
diff -u -r1.32 RequestProcessor.java
--- RequestProcessor.java 2 Jul 2003 04:06:53 - 1.32
+++ RequestProcessor.java 13 Aug 2003 15:23:40 -
@@ -409,6 +409,15 @@
}
if (forward.getRedirect()) {
+//save errors in session, if any
+Object errors = request.getAttribute(org.apache.struts.Globals.ERROR_KEY);
+if(errors != null){
+ //it is not the best place to create session, use false
+ HttpSession session = request.getSession(false);
+ if(session != null){
+session.setAttribute(org.apache.struts.Globals.ERROR_KEY, errors);
+ }
+}
// only prepend context path for relative uri
if (uri.startsWith(/)) {
uri = request.getContextPath() + uri;
Index: TagUtils.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/TagUtils.java,v
retrieving revision 1.22
diff -u -r1.22 TagUtils.java
--- TagUtils.java 2 Aug 2003 22:19:37 - 1.22
+++ TagUtils.java 13 Aug 2003 15:23:06 -
@@ -636,7 +636,18 @@
ActionErrors errors = new ActionErrors();
-Object value = pageContext.findAttribute(paramName);
+HttpServletRequest request = (HttpServletRequest)pageContext.getRequest();
+Object value = request.getAttribute(paramName);
+if(value == null){
+ //if it was redirection, errors could be in session
+ HttpSession session = request.getSession(false);
+ if(session != null){
+value = session.getAttribute(paramName);
+if(value != null){
+ session.removeAttribute(paramName);
+}
+ }
+}
try {
if (value == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Robert Leland [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: Building contrib packages WAS Re: cvs commit: jakarta-struts/contrib/tag-docbuild.xml
David Graham wrote: --- David M. Karr [EMAIL PROTECTED] wrote: David == David Graham [EMAIL PROTECTED] writes: David While we're somewhat on this topic I'd like to get some clarification on David the build process. Why do struts-el and struts-legacy get built with the David standard Struts build file? Struts-EL has *never* built on my machine and David I have just taken it on faith the rest of Struts built properly. Also, David after struts-legacy was added I've had to run my builds twice. The first David one always fails and the second succeeds (well, not really succeeds David because struts-el fails). So what compile errors are you getting in Struts-EL and Struts-Legacy? Struts EL is never built if the jstl.jar, taglib standard variables are commented out. I don't get any compile errors. It's a problem with jars not being in the right place or my build.properties being incorrect. I don't mean this in any negative way but I'm not interested in building struts-el. When I build Struts I'm mainly interested in picking up a webapp and running through it to see if my changes work. If there's no concrete reason to build struts-el with Struts, I'd like to see them separated to simplify the build process. This specific problem will go away when struts-el is part of the taglib distro but I think there is a more general problem of building contrib packages along with the standard packages. David -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
Re: cvs commit: jakarta-struts/web/example/WEB-INF struts-config-registration.xmlstruts-config.xml
David Graham wrote: --- [EMAIL PROTECTED] wrote: rleland 2003/08/09 01:50:52 Modified:conf/share struts-config_1_2.dtd doc/userGuide release-notes.xml web/example/WEB-INF struts-config-registration.xml struts-config.xml Log: Add two new elements description-short and description-long for use by struts config file tools and document generation. Suggested by Jonas Björnerstedt The only suggestion I could find in the archives was to add display-name and description elements. I'm confused by the two description fields. Is there a need for two different descriptions of the same struts-config.xml file? web.xml uses description and display-name so I think it would be better to match that. David Yea, I was going to change it ti only have a single description element, but it... Turns out Struts allready had a 'display-name' 'description' element defined. Who Knew. So I will be changing that. -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
Re: Decomposing RequestProcessor -- Some Code To Play With
Paul Smith wrote: Hey guys, this is exactly what pageflow does, though it does more as well. Oh well Im working on a white paper which describes the functionality. How would I go about getting something into the contrib folder? You might want to contribute it to the www.sf.net/projects/struts project. It's alot less overhead, and you would be added as a developer. You would then be able to call for new releases independant of the struts release cycle, which IMHO is a good thing. As far as duplication Jakarta has 2 Regular expression libraries, 2 or more MVC frameworks and multiple Web Application frameworks. So I would say add it to the SF struts project, and build a user base and see what happens. Keep in mind that Craigs chaining is targeted towards Struts 2.0. It would be nice if we could take some evolutionary steps towards that in the 1.X, so when we do switch it won't be so revolutionary, and painful. It may be that your page flow could be just the ticket. However if you would like to contribute to the chaining directly that would be great ! -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForwards, et al (was SuccessAction)
Craig R. McClanahan wrote: In addition, commons-chain provides a couple of layers of Context implementation (optional, compiled only if you have the corresponding APIs) for web applications: Actually optional compiling doesn't work, I believe in commons-chain but could be the contrib. I was 12:30 am for me when the checkin occured and I was just trying to get it compiled quickly. -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/resources extensions.xml
David Graham wrote: I'm assuming this commit was prompted by a corresponding enhancement ticket. If so, it would be helpful if you included the ticket number in the commit message so we can reference it later for more info if needed. I think the typical notation is PR# . I know using Bug # causes Buzilla to create a hyper link to the report. -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote ?] deprecate ActionErrors
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: I believe at one time we were going to deprecate ActionErrors since it is really a shell over ActionMessages. We could still keep the error tag, just make it use ActionMessages directly. It would be nice to get rid of it but I don't think we can until 2.0. ActionForm.validate() (and other methods) return an ActionErrors object. There is no way to deprecate those methods with a new version that returns ActionMessages because return types aren't part of method signatures. I think this would break backwards compatibility but I would love to be wrong on this one :-). You're right. We could provide a stop gap ActionForm.validateToMsg() or whatever that returns a list of ActionMessages objects. We could then get rid of ActionError internally by making it a facade of ActionMessage instead of extending ActionMessage. The same goes for ActionErrors, it would only be a facade. and only created when needed. Also, ActionError should be deprecated with ActionErrors because it's just a useless subclass of ActionMessage. David [ ] +1 Yes deprecate ActionErrors [ ] 0 Yes, but you'll have to face the angry crowds yourself. [ ] -1 No, and here is why. -Rob -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
