RE: Introduction and a proprosal to add new functionality to Struts: Automatichighlighting of errored form elements

Thanks, I did not see anything in Bugzilla having to do with styles and validation errors, but it wasn't an exhaustive look and there is a lot to look through. I was going to submit the enhancement ticket but I did not see a way to attach any of the patch files to it. (I see the attach link

cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestOptionTag1.jsp

jmitchell2003/06/06 20:53:23 Added: src/test/org/apache/struts/taglib/html TestOptionTag1.java web/test/test/org/apache/struts/taglib/html TestOptionTag1.jsp Log: More tests.fun fun!! Revision ChangesPath 1.1

cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestMultiboxTag4.jsp

jmitchell2003/06/06 20:44:53 Added: src/test/org/apache/struts/taglib/html TestMultiboxTag4.java web/test/test/org/apache/struts/taglib/html TestMultiboxTag4.jsp Log: More tests.fun fun!! Revision ChangesPath 1.1

cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestMultiboxTag3.jsp

jmitchell2003/06/06 20:44:04 Added: src/test/org/apache/struts/taglib/html TestMultiboxTag3.java web/test/test/org/apache/struts/taglib/html TestMultiboxTag3.jsp Log: More tests.fun fun!! Revision ChangesPath 1.1

cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestMultiboxTag2.jsp

jmitchell2003/06/06 20:43:00 Added: src/test/org/apache/struts/taglib/html TestMultiboxTag2.java web/test/test/org/apache/struts/taglib/html TestMultiboxTag2.jsp Log: More tests.fun fun!! Revision ChangesPath 1.1

cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestMultiboxTag1.jsp

jmitchell2003/06/06 20:41:31 Added: src/test/org/apache/struts/taglib/html TestMultiboxTag1.java web/test/test/org/apache/struts/taglib/html TestMultiboxTag1.jsp Log: More tests.fun fun!! Revision ChangesPath 1.1

Re: Status check?

On Fri, 6 Jun 2003, David Graham wrote: > Date: Fri, 06 Jun 2003 14:48:13 -0600 > From: David Graham <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Status check? > > It makes more sense to me to *not* tag the commons files with S

Re: [PLAN] Release Struts RC2 with FileUpload RC1

On Fri, 6 Jun 2003, Ted Husted wrote: > Date: Fri, 06 Jun 2003 09:24:18 -0400 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: [PLAN] Release Struts RC2 with FileUpload RC1 > > I've posted an

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

On Thu, 5 Jun 2003, Vic Cekvenich wrote: > Date: Thu, 05 Jun 2003 17:20:26 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces > > (hope this doe

Re: [ANNOUNCE] Updated Struts-Faces Integration Library

On Fri, 6 Jun 2003, Dom wrote: > Date: Fri, 6 Jun 2003 12:41:11 +0200 > From: Dom <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [ANNOUNCE] Updated

Re: Status check?

If you're going to cross-compile, you really need to go whole-hog and use the "target", "bootclass", and "extdirs" options. See: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-options and: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-examp

Re: Status check?

Martin Cooper wrote: For the main Struts release, the most time-consuming part is just testing that everything works with all the supported containers (including all the web apps). So, I take it we would be satisfied with testing our sample applications against the binary distribution (rather th

Re: Status check?

Ted Husted wrote: Just sorting out what I need to do to retrofit 1.2/1.3 with JAXP these days, so I can confirm we still compile with the old guard =:0) I downloaded the latest Web Services pack (I had an older version), and at first the JAXP from that distribution seemed to work, but now for J2

cvs commit: jakarta-struts/doc/userGuide installation.xml

husted 2003/06/06 15:03:35 Modified:doc/userGuide installation.xml Log: Update for FileUpload RC1 dependancy and latest JAXP information. Revision ChangesPath 1.27 +19 -21jakarta-struts/doc/userGuide/installation.xml Index: installation.xml ==

cvs commit: jakarta-struts build.properties.sample

husted 2003/06/06 15:02:08 Modified:.build.properties.sample Log: Updates in preparation for RC2. Revision ChangesPath 1.39 +3 -3 jakarta-struts/build.properties.sample Index: build.properties.sample ==

RE: Introduction and a proprosal to add new functionality to Struts: Automatichighlighting of errored form elements

We had problems in the past looking for a way to set focus at error field(s) in HTML forms. I think this could be also considered if the enhacement is accepted. +1 from us since we also missed such a functionality in the html tags. Regards, Adolfo. From: "David Graham" <[EMAIL PROTECTED]> Re

cvs commit: jakarta-struts build.xml build.properties.sample

husted 2003/06/06 13:55:36 Modified:.build.xml build.properties.sample Log: Updates in preparation for RC2. Revision ChangesPath 1.104 +1 -1 jakarta-struts/build.xml Index: build.xml

RE: Introduction and a proprosal to add new functionality to Struts: Automatichighlighting of errored form elements

This sounds interesting. You could create an enhancement ticket and attach patch files to it for us to review. I seem to remember this topic coming up before so you should search bugzilla and the list archives for relevant posts (we shouldn't offend anyone that already created a patch for this

Re: Status check?

It makes more sense to me to *not* tag the commons files with Struts. The commons doesn't need to be notified every time Struts cuts a release. The commons jars contain version information in their manifests so it would be very easy to recreate an old Struts build by looking there. David But

Re: Status check?

Martin Cooper wrote: I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to

RE: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements

I am very open to suggestions, but I do feel this change is a better fit incorporated into the tag library as opposed to standing on top of it. Inclusion requires signifcantly less code since contol of styles is localized to the BaseHandlerTag. Extending the tags is a lot more code (the same code

Re: Status check?

Martin Cooper wrote: As far as building and packaging go, you might want to take a look at the 'release' target I added to the main Struts build file. That really helps with putting the binary and source uploads together. Very nice work here, Martin. This target certainly simplifies things! Just s

Re: Status check?

Martin Cooper wrote: I'll take care of tagging our dependencies once RC2 is out. Hey, if setting CVS tags is something you like to do, more power to you, brother =:) But don't forget to tag ORO too, not to mention the jdbc2_0-stdext.jar and Servlet JAR =:) We also have external dependencies on t

Re: Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements

Sounds like a nice 3rd party library. Are you open to suggestions? I have a few ideas about this myself. -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - Original Message - From: "DeRose Jonathan" <[EMAIL PROTECTED]> To:

RE: Status check?

Perhaps a "-target 1.2" option should be specified on our "javac" targets? I would guess the number of issues with down-compilation from 1.4 to 1.2 is very small, but if we have one in our code base, the compiler won't tell us about it. > -Original Message- > From: Hajratwala, Nayan (N.)

Introduction and a proprosal to add new functionality to Struts: Automatic highlighting of errored form elements

Hello, I have an idea that I would like to propose to the Struts community involving the HTML tag library; automatic highlighting of errored form elements. I have used Struts for a couple medium sized projects and always extended the tags to get this functionality. After doing this two or th

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Status check?

>-Original Message- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 1:54 PM > To: [EMAIL PROTECTED] > Subject: Re: Status check? > > > > "Ted Husted" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Our installation page says our dependency

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20535] New: - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

Is ASF allowed to distribute Sun JDK? Not AFAIK. I think main argument is license, ex: what is cost of JSF? Is it similar to JBoss issue? I am not against JSF integration w/Struts at all. The more the better. When there is only a single choice, this can't be good, standard or not. No one has

Re: Status check?

"Ted Husted" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Martin Cooper wrote: > > The tagging for the main Struts release will actually be a bit more > > painful for RC2 since you can't just blanket-tag the Commons packages - > > they'll have to be tagged individually to match th

Re: Status check?

"Ted Husted" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Our installation page says our dependency is J2SE 1.2 or later. > > Does that mean I should compile the binary distribution under the latest > J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the release

Re: Status check?

For Java 1.2 and 1.3, we need to have JAXP available to build the distribution. The RI isn't distributed separately anymore, but is part of the Web Services bundle. http://java.sun.com/xml/jaxp/faq.html#jaxp-ri-latest I tried pulling out the jaxp-api.jar, but that didn't seem to work. Before I

RE: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

Vic, The JSF Expert group includes : Specification Lead Ed Burns Sun Microsystems, Inc. Craig R. McClanahanSun Microsystems, Inc. Expert Group Aligo, Inc. Apache Software Foundation BEA Systems Bayern, Shawn Bergsten, Hans Berkovitz, Joseph Boga

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

?? The BEA OS? I see where you are going ;-) "they are *not* just another vendor." Got it! There for excluded from ASF livense. That explains the MS lawsuit. Got it. Thanks. JSF is "standard". Like C# is. I learned something. :-[ Peace, .V David Graham wrote: Sun licenses Java to other compani

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

Sun licenses Java to other companies so that they can port it to their OSes. A violation of that license is what the whole MS lawsuit is about. Like it or not, Sun owns Java; they are *not* just another vendor. Again, like it or not, JSF is not a framework provided by a vendor but a *standard

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

"1. License Grant. BEA Systems, Inc. ("BEA") grants you a non-exclusive and non-transferable license for the internal evaluation, testing , development and production use of the accompanying software and documentation provided by BEA for WebLogic JRockit ("JRockit"), including, but not limited to

Re: Status check?

Martin Cooper wrote: The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. I can understand why we tagged the Commons packages

Re: Servlet 2.2 / JSP 1.1

Vic, We seem to have this same discussion with great frequency. Struts 1.x is committed to maintaining backward compatibilty which includes maintaining the base Servlet API requirement at 2.2. Struts 2.x will move that requirement to 2.3 (possibly 2.4 but that seems premature). Struts 1.2 wil

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

When you download the JRE/JDK you agree to a Sun license. Java itself is distributed under a Sun license. JSF is a Java standard released through the JCP. You're free to have your own opinion of JSF but Struts *will* support it. The Struts team believes in the use of standard technologies as

Re: Status check?

I think it's safest to build with 1.2. David Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I'm installing 1.2 now, to at least be sure it still builds (as I

Re: Status check?

Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I'm installing 1.2 now, to at least be sure it still builds (as I remember, the nightlies are building on Craig

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

ASF does not ask much of people other than don't use it to endorse vendor products. JSF is a Sun license. On apache.org domain we have integration to a vendor. I asked for a president, did Jakarta in the past have integration to a vendor on Apache domain? Is the SF.net implementation licensed to

new members should you wish

Dear commiters, Please consider these people at a time you decide to increase # of commiters. Peter.PILGRIM, Matt Raible, Brandon Goodin, John Yu, Don Brown. In general, they have contributed to Struts and could/should fix things themselves, as opposed to ask for things to be fixed, but you can

cvs commit: jakarta-struts/contrib/struts-legacy build.properties STATUS.txt build.properties.sample build.xml

husted 2003/06/06 08:46:11 Modified:contrib/struts-legacy STATUS.txt build.properties.sample build.xml Added: contrib/struts-legacy build.properties Log: Minor changes to struts-legacy packaging in preparation for its release. Revision Changes

cvs commit: jakarta-struts/contrib/struts-legacy/src/java/org/apache/struts/legacy package.html

husted 2003/06/06 08:39:37 Added: contrib/struts-legacy/src/java/org/apache/struts/legacy package.html Log: Minor changes to struts-legacy packaging in preparation for its release. Revision ChangesPath 1.1 jakarta-struts/contri

Servlet 2.2 / JSP 1.1

http://jakarta.apache.org/struts/status.html states: "Struts 1.2.x will include additional functional enhancements along the same lines as Struts 1.1. The platform requirements will remain the same (Servlet 2.2 / JSP 1.1)." I missed that discussion. (Deprecation to me means it will be dropped i

http://jakarta.apache.org/struts/faqs/database.html

http://jakarta.apache.org/struts/faqs/database.html (It seems out of date and possible reason why users ask JDBC questions on list, here is a suggested draft replacment, either way it needs a bit of updateing.) Struts apps are web applications and use the J2EE resources of the application serve

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

I don't understand the problem you have with Struts integrating with JSF. JSF is the Java *standard* web GUI library. David (hope this does not detract from more important issues) http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces To the extent that this implies Struts _should_

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

(hope this does not detract from more important issues) http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces To the extent that this implies Struts _should_ integrate to Sun JSF, I do not like it. This is quite different than JSTL, which was an Apache License. Maybe there should be

DO NOT REPLY [Bug 19802] - Configurable processPopulate()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [PLAN] Release Struts RC2 with FileUpload RC1

Thanks, fixed. Mike Jasnowski wrote: Just curious, in the releaes plan under "The plan" it has the following line: Therefore, the following release plan is proposed for Struts 1.1 Release Candidate 1: Should this be "Release Candidate 2" ? If not, sorry for the noise. Mike ---

cvs commit: jakarta-struts/doc/proposals release-plan-1.1rc2.xml

husted 2003/06/06 06:48:09 Modified:doc/proposals release-plan-1.1rc2.xml Log: Post plan for RC2. Revision ChangesPath 1.2 +3 -3 jakarta-struts/doc/proposals/release-plan-1.1rc2.xml Index: release-plan-1.1rc2.xml

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: [PLAN] Release Struts RC2 with FileUpload RC1

Just curious, in the releaes plan under "The plan" it has the following line: Therefore, the following release plan is proposed for Struts 1.1 Release Candidate 1: Should this be "Release Candidate 2" ? If not, sorry for the noise. Mike -Original Message- From: Ted Husted [mailto:[EMAI

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [PLAN] Release Struts RC2 with FileUpload RC1

Forgot the plan URL (which is also on the RoadMap): http://jakarta.apache.org/struts/proposals/release-plan-1.1rc2.html Ted Husted wrote: I've posted an updated Release Plan to reflect the consensus we reached on RC2. I'm going to work on the struts-legacy release first make the necessary adjus

[PLAN] Release Struts RC2 with FileUpload RC1

I've posted an updated Release Plan to reflect the consensus we reached on RC2. I'm going to work on the struts-legacy release first make the necessary adjustments to the build. Then, I'll start on the tests gauntlet for RC2, so that I can cut the actual release first thing tomorrow morning. A

Re: Build problems?

On Thu, 5 Jun 2003, David Graham wrote: > Date: Thu, 05 Jun 2003 08:10:29 -0600 > From: David Graham <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Build problems? > > I just downloaded the June 5th binary nightly and it's missing th

cvs commit: jakarta-struts/doc status.xml

husted 2003/06/06 06:15:57 Modified:doc status.xml Log: Post plan for RC2. Revision ChangesPath 1.30 +2 -2 jakarta-struts/doc/status.xml Index: status.xml === RCS file: /home/cvs/jaka

cvs commit: jakarta-struts/doc/proposals release-plan-1.1rc2.xml

husted 2003/06/06 06:15:45 Added: doc/proposals release-plan-1.1rc2.xml Log: Post plan for RC2. Revision ChangesPath 1.1 jakarta-struts/doc/proposals/release-plan-1.1rc2.xml Index: release-plan-1.1rc2.xml

DO NOT REPLY [Bug 18018] - requiredif variable names crash javascript validation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20541] - validator rule on requiredif error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Struts Module [RE: composable RequestProcessor]

And we'll put in work on the bugs. We haven't run into any, and presumably there aren't any right now or we wouldn't be cutting a release candidate. But I'll keep my eye out for discussions about where they need improvement. Search bugzilla for bugs marked LATER and you'll find module problems.

Re: Struts Module [RE: composable RequestProcessor]

So Modules are effectively dead(wood). Is that what you are saying? Not at all. Modules are buggy because no one is around that seems willing to support them. I try to fix them as best I can but I don't use modules which makes my motivation fairly low. Eddie Bush used to work on module issues

Re: Struts Module [RE: composable RequestProcessor]

At 18:06 +0100 6/5/03, PILGRIM, Peter, FM wrote: So Modules are effectively dead(wood). Is that what you are saying? The only problem I think I have with modules (am I have never used in anger) is that they do not inherit resources or the actions of the default module. If they did writing Expresso

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17299] - Page variable not set on DynaValidatorForms for mutlipage validations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Struts Module [RE: composable RequestProcessor]

> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > > David Graham wrote: > > This reminds me of modules where they sounded like a great > idea and then > > there's nobody to support the bugs. > > Amen to that, brother. > > http://nagoya.apache.org/eyebrowse/ReadMsg?lis

Re: ActionContext [WAS: RE: composable RequestProcessor]

Andrew Hill wrote: Im doing this in my app - though the execute signature remains the same. Most of my actions extend some abstract action classes, and most of the hooks the subclass overrides are passed an ActionContext bean (which simply has getters for the request,response, mapping etc...). Save

Re: Plz: Post Designer "release" versus "version" info somewhere

Hmmm, could you also make it a more obvious link / title? Cause I missed it when I was browsing through. But thanks for taking care of it!! rob g Designer Product Manageme0 [Filename: Book1.xls.pif, Content-Type: application/x-msdownload] [WARNING] - A potentially hazardous attachment was remo

RE: composable RequestProcessor

At 14:44 +0100 6/5/03, PILGRIM, Peter, FM wrote: This could work well. How does this processor pattern solve the problem where the RequestProcessor stores data member? E.g. The list of Actions recorded against a ModuleConfig. The list of actions is only really used by one process method so it doesn

DO NOT REPLY [Bug 20509] - ErrorsTag display blank if resource not found

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20509] New: - ErrorsTag display blank if resource not found

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: composable RequestProcessor

At 14:44 +0100 6/5/03, PILGRIM, Peter, FM wrote: This could work well. How does this processor pattern solve the problem where the RequestProcessor stores data member? E.g. The list of Actions recorded against a ModuleConfig. That's a good question. Maybe the interface for processor modules shoul

Re: Status check?

> What if we compromise on 3 weeks? I understand the tag testing issue but we > shouldn't be holding back because of documentation issues. It's all about getting the tags and other changes tested more completely. (what's documentation? ;) I can very munch understand something happening for Java

Re: Status check?

What if we compromise on 3 weeks? I understand the tag testing issue but we shouldn't be holding back because of documentation issues. David -1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel

DO NOT REPLY [Bug 20541] New: - validator rule on requiredif error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 18864] - duplicate Class-Path entries in Manifest causes warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20502] - MANIFEST.MF Class-Path wrongly formatted

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Build problems?

I just downloaded the June 5th binary nightly and it's missing the contrib directory and there is nothing inside the webapps directory. I downloaded May 29th and everything was fine. Any ideas on what went wrong? David _ MSN 8 wi