RE: composable RequestProcessor

> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: 04 June 2003 12:05 > To: Struts Developers List > Subject: Re: composable RequestProcessor > > > I still don't see why processing an "action" request is any different > than processing a "validation" request. > >

Re: [OT] SEX SEX SEX

Already voted. IDEA is being severely robbed, IMHO. And 3000 odd votes from various users at keyboardmonkey.com would look suss. :P Eclipse has more users, so I suppose it has to give in, but to JBuilder as well!??... nah. doesn't bode well. Arron. > Ok, now that I've got your attention ;) >

Re: Status check?

> OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or > updated the web site, but it's there. > > The Tomcat build did indeed break, and interested parties can see the > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe > for their support. > > -- > Martin

Re: Status check?

-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 a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, an

RE: composable RequestProcessor

Just thought I'd through an argument out there against using the xml configuration approach as food for thought. On my current application, I have around 12 struts modules. Each is using dynaActionForms, 3 or 4 plugins, and ranging from 10-50 actions. I have several developers who do a great job

ActionContext [WAS: RE: composable RequestProcessor]

I'd even like create a new execute(StrutsRequestContext) method in the default Action class, that simple calls the old execute(m, f, r, r) (for backwards compatibility). Im doing this in my app - though the execute signature remains the same. Most of my actions extend some abstract action classe

RE: composable RequestProcessor

>Maybe the interface for processor modules should >take two arguments, a "StrutsRequestContext" like what you described, which >would have these properties: >request >response >mapping >form >path >Then a second object, "StrutsModuleContext" >with these properties, with public accessors, only a pu

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

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 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

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 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

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

cvs commit: jakarta-struts/contrib/struts-el README.txt

dmkarr 2003/06/05 21:33:35 Modified:contrib/struts-el README.txt Log: Bug: 20486 Added a note about the history of the porting of the "iterate" tag and the implementation of code to check for "c:forEach" in addition to "logic:iterate". Also clarified that the Jakarta Taglib

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

Isn't JSF just another spec like Servlets and JSP?... Any vendor can make a JSP impl based on the spec, so they should also be able to make a JSF impl. Struts-Faces allows Struts to play with any compliant JSF implementation. If it doesn't we get to go Craig-bashing. :) Struts plays with Servlet/

DO NOT REPLY [Bug 20502] New: - 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

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 20432] - Validator returns nulls in 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 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

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 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

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 20486] New: - Explaining that logic:iterate was ported to struts-el but has now been superseded

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: Validator Javascript being displayed on the jsp page

Sounds like it could be 11950 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11950 hth, e. "David Graham" <[EMAIL PROTECTED]> 06/04/2003 02:26 PM Please respond to "Struts Developers List" To: [EMAIL PROTECTED] cc: Subject:RE: Validator Javascript b

RE: Validator Javascript being displayed on the jsp page

Sorry, my search of bugzilla didn't turn up anything but you can search it yourself if you have some time. David Using the latest version of commons-validator (1.0.2) helped resolve the problem. You mentioned that 'This sounds like a bug that was fixed some time ago'. Can u please elaborate on

Re: composable RequestProcessor

But I guess this is just speculating about hte future. Maybe the best solution is to create a simple composable RequestProcessor for 1.2 and then see what the future might bring? A new RequestProcessor in any form warrants its own point release. 1.2 is already scheduled for a move to commons-re

RE: Status check?

On Wed, 4 Jun 2003, James Turner wrote: > Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan > brought forth upon the Java community a new framework, conceived of MVC, > and devoted to the notion that all business logic should be treated > separate. > :-) > Advice to Crai

RE: Validator Javascript being displayed on the jsp page

Hi David, Using the latest version of commons-validator (1.0.2) helped resolve the problem. You mentioned that 'This sounds like a bug that was fixed some time ago'. Can u please elaborate on what the bug was and if u have the bug id, that would be helpful too... just for future reference... The r

Re: composable RequestProcessor

Doctor it hurts when I do that Then don't do that! A lot of places in the Struts framework, simple inheritance is used. Some places because it's the simplest thing that might possibly work, other places to avoid unwanted flexibility (ActionForm). When the simple solution is starting to feel aw

RE: Status check?

> From: Ted Husted [mailto:[EMAIL PROTECTED] > So, pending advice to the contrary, I'll plan on putting 29 > June 2003 in > the Release Plan (two years and two weeks after Struts 1.0). Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan brought forth upon the Java communi

Re: Status check?

Ted Husted wrote: Craig R. McClanahan wrote: > I do think we should say something like "two weeks after RC2, barring > any major bugs" so that we can encourage people to actually try RC2 in > that time frame. June 15 would the be second anniversary of Struts 1.0 -- but I reckon that's a might t

Re: Status check?

Craig R. McClanahan wrote: > I do think we should say something like "two weeks after RC2, barring > any major bugs" so that we can encourage people to actually try RC2 in > that time frame. June 15 would the be second anniversary of Struts 1.0 -- but I reckon that's a might too close, so let's sa

[OT] SEX SEX SEX

Ok, now that I've got your attention ;) Please go and vote: http://www.sys-con.com/java/readerschoice2003/index.cfm -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx -

Re: composable RequestProcessor

Jeff Robertson wrote: Wow. Mr. Husted, this may seem like an obvious conclusion to you, but to me (and probably others as well) this is a big "hey, why didn't I think of that!" moment. I know the feeling -- I just got it reading the latest docs for the Struts Workflow extension =:0) IMHO, Matthai

Re: Status check?

- Original Message - From: "David Graham" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? > >Right, but what's the right amount of time to wait? > > Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchel

RE: Status check?

Good for me too. James > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 04, 2003 2:43 PM > To: [EMAIL PROTECTED] > Subject: RE: Status check? > > > >Right, but what's the right amount of time to wait? > > Craig suggested 2 weeks and I think t

[ANNOUNCE] Updated Struts-Faces Integration Library

version. Nightly builds of the updated code, starting with the 20030605 version (i.e. tonight) will be available at: http://jakarta.apache.org/builds/jakarta-struts/nightly/struts-faces/ (Versions up through and including 20030604 are for the EA3 release of Faces; wait until tomorrow to grab the

RE: Status check?

Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. David James > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 04, 2003 2:34 PM > To: [EMAIL PROTECTED] > Subject: RE: Status check? > > > Se

RE: Status check?

Right, but what's the right amount of time to wait? James > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 04, 2003 2:34 PM > To: [EMAIL PROTECTED] > Subject: RE: Status check? > > > Setting release dates is not a good idea for many reasons.

Re: Status check?

On Wed, 4 Jun 2003, Ted Husted wrote: > Date: Wed, 04 Jun 2003 14:25:15 -0400 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Re: Status check? > > > Martin Cooper wrote: > > OK, FileUpload

RE: Status check?

Setting release dates is not a good idea for many reasons. IMO, 1.1 final should be released after enough time that people have tested apps with RC2 and there are no show stopping bugs. David Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want

RE: Status check?

Good for me. Since the intent is for RC2 to go final after testing and a FileUpload Final, do we want to set a date for Struts 1.1 final? Think we can have RC2 live before we head off for SF? It would be a nice trophy to bring to JavaOne, especially with a target release date for Final. James

RE: composable RequestProcessor

I don't see anything in the ActionServlet that couldn't be provided by some other class. David In the past the argument for creating redundant services from within Struts was that it allowed for easier and condensed configuration management of Struts stuff from non-struts stuff. For example, we

Re: Status check?

Martin Cooper wrote: OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. Excellen

RE: composable RequestProcessor

In the past the argument for creating redundant services from within Struts was that it allowed for easier and condensed configuration management of Struts stuff from non-struts stuff. For example, we have the plugin (lifecylce) config which is essentially the same as using a servlet for initializa

Re: composable RequestProcessor

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/[EMAIL PROTECTED]&msgId=133116 -Ted. -

RE: composable RequestProcessor

If we use Filters in lieu of the RP wouldn't that require that we move the ActionServlet to a filter as well? Where does the ActionServlet fit in to this? The ActionServlet initializes Struts from the config files but all processing goes through the RP. So, we could still have the servlet init.

RE: composable RequestProcessor

If we use Filters in lieu of the RP wouldn't that require that we move the ActionServlet to a filter as well? Where does the ActionServlet fit in to this? Brandon Goodin -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:44 AM To: [EMAIL PROT

RE: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

You can count me retroactively +1 as well ... sorry, it's been insanely busy lately. Craig On Wed, 4 Jun 2003, James Turner wrote: > Date: Wed, 4 Jun 2003 00:31:38 -0400 > From: James Turner <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: 'Struts Developers List'

Re: composable RequestProcessor

David Graham wrote: Why should we duplicate the effort of the container inside Struts? We often duplicate the effort of the container. Actions duplicate servlets. Modules duplicate multiple applications. In each of these cases, the effect of the container feature is the same, but the justificat

cvs commit: jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example LinkSubscriptionRenderer.java LinkSubscriptionTag.java

craigmcc2003/06/04 10:37:36 Modified:contrib/struts-faces/src/example/org/apache/struts/webapp/example LinkSubscriptionRenderer.java LinkSubscriptionTag.java Log: Update the example app sources for the new EA4 release of JavaServer Fa

cvs commit: jakarta-struts/contrib/struts-faces/web/example/WEB-INF web.xml

craigmcc2003/06/04 10:37:02 Modified:contrib/struts-faces/web/example logon.jsp registration.jsp subscription.jsp contrib/struts-faces/web/example/WEB-INF web.xml Log: Update the web portion of the Struts-Faces example app for the new EA4 rele

Re: Status check?

On Sat, 31 May 2003, Martin Cooper wrote: > > "Ted Husted" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Martin Cooper wrote: > > > Now, about the Struts 1.1 RC2 release. The problem is the staging > > > needed to get FileUpload out the door. It's currently at Beta 1, and >

DO NOT REPLY [Bug 11852] - The bean:message tag should accept Objects as arguments

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

David Graham wrote: Why should we duplicate the effort of the container inside Struts? We often duplicate the effort of the container. Actions duplicate servlets. Modules duplicate multiple applications. In each of these cases, the effect of the container feature is the same, but the justifica

RE: Re: composable RequestProcessor

Actions have some drastically different logical contents that may make them incompatible with other Actions. I'm not sure how you could create a composable Action process without rewriting the whole underlying struts Action architecture. Also, there are other ways to avoid the "pitfalls" of Action

Re: composable RequestProcessor

I'm not convinced that this configuration is Struts' responsibility. If we want to define a chain of methods that will process a request we should be using Filters and web.xml to configure them. Filters are the standard method of doing this and fit in well with our RequestProcessor (RP) method

DO NOT REPLY [Bug 20459] - html:form focus and focusIndex problem

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: Re: composable RequestProcessor

I'm not sure why you shouldn't open it up all the way. Sounds good to me. Why stop at the RP. Why not take it all the way to the action as well? A lot of people have been clamoring for some kind of method to configurably compose action functionality in a way that avoids the deadly pitfalls of 'a

RE: Re: composable RequestProcessor

At 9:36 -0600 6/4/03, Brandon Goodin wrote: That sounds very complex. With Validator we are dealing with quantifiable results. This is not so cut and dry with RP stuff. With the RP I think we would do best not to add anymore complexity than neccessary. One process should be ignorant of the other un

DO NOT REPLY [Bug 20432] - Validator returns nulls in 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 20265] - Locale missing when constructing a MessageFormat in MessageResources

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 20468] - MessageResources always uses the default Locale for MessageFormats

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 11852] - The bean:message tag should accept Objects as arguments

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 20466] - should accept Object args instead of String args

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: Re: composable RequestProcessor

That sounds very complex. With Validator we are dealing with quantifiable results. This is not so cut and dry with RP stuff. With the RP I think we would do best not to add anymore complexity than neccessary. One process should be ignorant of the other unless data is provided in the Tranfer Object

RE: Re: composable RequestProcessor

Like targets in Ant... -Original Message- From: Kent Sølvsten Rasmussen [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 June 2003 23:19 To: Struts Developers List Subject: Re: Re: composable RequestProcessor Just a thought... Would it be possible to take the anology to Validator one step f

Re: Re: composable RequestProcessor

Just a thought... Would it be possible to take the anology to Validator one step further? Instead of a predefined or configurable lifecycle, would it be possible to let the SubProcessors depend on each other, just like some of the validations "depend" on each other? Maybe the configurationfile

Re: composable RequestProcessor

Joe, I agree that it makes sense to wrap things up on the wiki page. And the status it currently has is a good snapshot of the current situation. We will see how this progresses and when it makes sense to change the wiki pages again. I still need to look at the current request processor code wi

RE: composable RequestProcessor

At 21:14 +0800 6/4/03, Andrew Hill wrote: Just had a look at the updated wiki. Is it just me lacking sleep or are the contents for the singleInterface page and the composableRequestprocessor page kindof in the wrong places? (ie the stuff for composable on the single page and vice versa) I don't thi