Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

I know the population process is currently in RequestUtils - I was proposing moving the multipart processing thats in the RequestUtils's populate() method out of there and into a Command. Although the "wrapped" request isn't currently used in the population mechanism theres no reason why, once th

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

On Fri, 25 Feb 2005 02:16:14 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Actually I just realized, if the Multipart stuff was all done in its own > Command, the point in the process it gets executed can be adjusted just by > the position in the Chain config - as long as its before the popu

Re: Servlet 2.3 Multipart Request Handling

On Fri, 25 Feb 2005 04:51:27 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > - Original Message - > From: "Martin Cooper" <[EMAIL PROTECTED]> > Sent: Friday, February 25, 2005 4:25 AM > > > On Fri, 25 Feb 2005 04:15:17 -, Niall Pemberton > > <[EMAIL PROTECTED]> wrote: > > > AFAI

Re: Servlet 2.3 Multipart Request Handling

- Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> Sent: Friday, February 25, 2005 4:25 AM > On Fri, 25 Feb 2005 04:15:17 -, Niall Pemberton > <[EMAIL PROTECTED]> wrote: > > AFAIK there were two issues with multipart request handling that needed > > Servlet 2.3 to resolv

Re: Servlet 2.3 Multipart Request Handling

On Fri, 25 Feb 2005 04:15:17 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > AFAIK there were two issues with multipart request handling that needed > Servlet 2.3 to resolve: > > 1) Forwarding a "wrapped" Request > http://issues.apache.org/bugzilla/show_bug.cgi?id=17583 > > 2) Un-implemented

Servlet 2.3 Multipart Request Handling

AFAIK there were two issues with multipart request handling that needed Servlet 2.3 to resolve: 1) Forwarding a "wrapped" Request http://issues.apache.org/bugzilla/show_bug.cgi?id=17583 2) Un-implemented Servlet 2.3 methods http://issues.apache.org/bugzilla/show_bug.cgi?id=28983 I think we agre

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

First, let me say that I did not create the current MultipartRequestHandler interface, and have never liked it, for a variety of reasons. However, by the time I got involved with it, we were pretty much stuck with it for backwards compatibility reasons. In order to retain backwards compatibility in

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

Actually I just realized, if the Multipart stuff was all done in its own Command, the point in the process it gets executed can be adjusted just by the position in the Chain config - as long as its before the populate Command. So that shouldn't be an issue, and theres no real reason for having the

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

I agree with you in general that the multipart functionality should be re-factored so that it could be more easily overriden. IMO though one of the issues is that the key multipart processing is in the RequestUtils's populate() method and as thats a "static" utils method its not possible to overrid

Re: Wiki Exports [was Re: Subversion reorg - Short term plans]

Oh, what I wouldn't give to be able to use Trac for Struts! Not only does it do, IMO, a good job of being a simple, nice looking wiki, but it is tightly integrated into Subversion and comes with its own source code browser that I find _much_ easier to use than viewCVS. That said, it probably

svn commit: r155254 - struts/flow/trunk/project.xml

Author: jmitchell Date: Thu Feb 24 13:52:45 2005 New Revision: 155254 URL: http://svn.apache.org/viewcvs?view=rev&rev=155254 Log: bring flow POM inline with parent, and that (mostly) completes the 'reorg of Struts subprojects' to an inherited Project Object Model Modified: struts/flow/trunk/

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

Thanks, Joe. Just a quick, if not short, response. I think the next thing I do should be to show some code. See within: On Thu, 24 Feb 2005 09:06:48 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 11:09 PM -0800 2/23/05, Dakota Jack wrote: > >Joe, > > > >I have rethought recent discussions

Re: Struts mailreader

On Thu, 24 Feb 2005 09:55:58 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > If I recall correctly, the app:checklogon tag was initially written to > simply demonstrate how to write a custom taglib. However, I am of the > opinion that (while intentions were good) that tag should be removed as i

Re: Subversion reorg - Short term plans

On Wed, 23 Feb 2005 17:02:40 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > shale/- I can save you a little short term work :-). I'd like to keep this one Ant-based for now. It's totally independent of the others, so that should not cause any grief. Craig -

svn commit: r155216 - struts/tiles/trunk/project.xml

Author: jmitchell Date: Thu Feb 24 09:57:48 2005 New Revision: 155216 URL: http://svn.apache.org/viewcvs?view=rev&rev=155216 Log: update struts url for required dependencies Modified: struts/tiles/trunk/project.xml Modified: struts/tiles/trunk/project.xml URL: http://svn.apache.org/viewcvs/

svn commit: r155215 - struts/core/trunk/build-legacy/taglib/maven.xml

Author: jmitchell Date: Thu Feb 24 09:55:06 2005 New Revision: 155215 URL: http://svn.apache.org/viewcvs?view=rev&rev=155215 Log: taglib maven.xml was brought back (and modified) Removed: struts/core/trunk/build-legacy/taglib/maven.xml ---

svn commit: r155214 - in struts/taglib/trunk: maven.xml project.xml

Author: jmitchell Date: Thu Feb 24 09:52:38 2005 New Revision: 155214 URL: http://svn.apache.org/viewcvs?view=rev&rev=155214 Log: update dependency url, bring maven.xml inline with sibling configs Added: struts/taglib/trunk/maven.xml - copied, changed from r155159, struts/core/trunk/bu

svn commit: r155212 - struts/el/trunk/project.xml

Author: jmitchell Date: Thu Feb 24 09:46:01 2005 New Revision: 155212 URL: http://svn.apache.org/viewcvs?view=rev&rev=155212 Log: update dependency url Modified: struts/el/trunk/project.xml Modified: struts/el/trunk/project.xml URL: http://svn.apache.org/viewcvs/struts/el/trunk/project.xml?

Re: Struts mailreader

Great. Maybe mailreader becomes the template for $template, but I will work in any case. .V James Mitchell wrote: If I recall correctly, the app:checklogon tag was initially written to simply demonstrate how to write a custom taglib. Yes, I am volunteering ;) Your thoughts? -- James Mitchell S

svn commit: r155196 - struts/bsf/trunk/project.xml

Author: jmitchell Date: Thu Feb 24 08:10:22 2005 New Revision: 155196 URL: http://svn.apache.org/viewcvs?view=rev&rev=155196 Log: bring el/project.xml inline with parent Modified: struts/bsf/trunk/project.xml Modified: struts/bsf/trunk/project.xml URL: http://svn.apache.org/viewcvs/struts/b

Re: Struts mailreader [a not about struts-blank]

As to blank, let's leave them in until we have a better all-around solution to bootsrapping a Struts application. The idea is that the applications using blank as a starting point may use Tiles and the Validator. Blank should come "fully-loaded" in terms of configuration, but "nearly-empty" in t

Re: Subversion reorg - Short term plans

On Thu, 24 Feb 2005 07:29:02 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 23 Feb 2005 20:25:33 -0800, Martin Cooper wrote: > > I haven't created 'site' yet. I'm going to come up with an overall > > docs plan, post it on the wiki, and then try to migrate all of the > > docs together, in as

Re: Struts mailreader [a note about struts-blank]

correction to subject line ;) -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: "James Mitchell" <[EMAIL PROTECTED]> To: "Struts Developers List" Sent: Thursday, February 24, 2005 10:43 AM Subject: Re: Struts

Re: Struts mailreader [a not about struts-blank]

Great! In making local mods for the various apps, I noticed the blank app is loading tiles and validator plugins, yet they are not used. Since we already have a tiles app and a validator app, I don't think that needs to be there. My primary reason for wanting to remove that is so that I don't

Re: Struts mailreader

+1 The other justification was defensive programming. If they tried to open the page directly, it would blow up, since the expected objects would not be in the request. But, since then, we've stopped linking to pages directly, so the tag is a feature without a cause :) If we want to demonstrat

Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled

At 11:09 PM -0800 2/23/05, Dakota Jack wrote: Joe, I have rethought recent discussions on multipart requests and have a different proposal. What I would suggest would be to take the whole multipart business out of the framework altogether and to treat it as I think it should be treated, as just an

Struts mailreader

If I recall correctly, the app:checklogon tag was initially written to simply demonstrate how to write a custom taglib. However, I am of the opinion that (while intentions were good) that tag should be removed as it demonstrates what I would call a "bad practice" wrt j2ee security. We could r

DO NOT REPLY [Bug 33730] New: - Bad request url with Struts/Tiles/Tomcat 5.5.7

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://issues.apache.org/bugzilla/show_bu

Re: Blank Questions

I don't know about a template, but I do know someone who did a iBATIS rendition of the infamous MailReader application. Once apps stabilizes, perhaps he would donate it to us and we could hook it up to one of the native Java DBMS. I am working an application controller implemented in C# based on

Re: Subversion reorg - Short term plans

On Wed, 23 Feb 2005 20:25:33 -0800, Martin Cooper wrote: > I haven't created 'site' yet. I'm going to come up with an overall > docs plan, post it on the wiki, and then try to migrate all of the > docs together, in as short an interval as possible. The 'site' > subproject will show up at that time.

Wiki Exports [was Re: Subversion reorg - Short term plans]

We have MoinMoin installed on ASF hardware right now. (Of course, we can use any resources we like. Things like wikis don't have to be on ASF hardware if we want to host them somewhere else.) The MoinMoin wiki is here: [http://moinmoin.wikiwikiweb.de/FrontPage]. I see a MoinMoin proposal for PD

RE: Uhh... dumb question...

-Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, February 24, 2005 10:14 AM To: Struts Developers List Subject: Re: Uhh... dumb question... Thanks Joe. I was hoping it was available in a ready-to-use form (understanding all the caveats about API sta