Bug report for Struts [2003/06/01]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: composable RequestProcessor

David Graham wrote: One thing that bothers me is that RequestProcessor is not an interface which leads to the Tiles situation. If it were an interface, you could implement your one method and delegate the rest to the TilesRequestProcessor or any number of other processors. IMO, RequestProcesso

Re: composable RequestProcessor

At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote: For Expresso I too have subclassed the TilesRequestProcessor for our own ExpressoRequestProcessor. Can a module have more than one controller? Not the way it is right now, and I'm not sure why you'd need it. I think if you want to use the approach yo

Re: composable RequestProcessor

If RequestProcessor becomes an interface then you ought invent a RequestProcessorManager interface, which is an object responsible for managing and invoking request processor. In other words we have a manager and worker children. If not the controller XML needs changing. How about I'm n

Re: Status check?

Martin, I'm trying to release the struts-legacy package with our GenericDataSource implementation. I'm working from the Commons instructions (but substituting jakarta-struts where appropriate). http://jakarta.apache.org/commons/releases.html At step 5, it looks like I should log into cvs.apach

Re: composable RequestProcessor

Joe Germuska wrote: At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote: For Expresso I too have subclassed the TilesRequestProcessor for our own ExpressoRequestProcessor. Can a module have more than one controller? Not the way it is right now, and I'm not sure why you'd need it. I think if you want

Re: Status check?

On Sun, 1 Jun 2003, Ted Husted wrote: > Martin, > > I'm trying to release the struts-legacy package with our > GenericDataSource implementation. I'm working from the Commons > instructions (but substituting jakarta-struts where appropriate). > > http://jakarta.apache.org/commons/releases.html T

DO NOT REPLY [Bug 20403] New: - allow for comments inside of web.xml

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 20403] - allow for comments inside of web.xml

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

I will try to wrap up, what we are up against: The current RequestProcessor implementation does not support chains of request processors. So the developer has to decide which request processor to choose. This brings him into a dilemma, if he wants to use two struts extensions that both implemen

Re: composable RequestProcessor

Peter A. Pilgrim wrote: > MasterRequestProcessor master = new MasterRequestProcessor(); > master.add( TilesRequestProcessor ); > master.add( FoobarRquestProcessor ); > > Is this it? I would say that this is on the right track. Essentially, each of the process methods represent an extension point o

RE: composable RequestProcessor

The big question with this chaining method is how do we get them to 'play nice' with each other, where the two (or more) processors are in conflict - for example one implements code that would override what the other does such as in processLocale() - or for those methods that return an object such

Re: composable RequestProcessor

Let's take a back step, then. What is a composable request processor? What is the thing that you are trying to build? MasterRequestProcessor master = new MasterRequestProcessor(); master.add( TilesRequestProcessor ); master.add( FoobarRquestProcessor ); Actually, it would be more like: master.add(

RE: composable RequestProcessor

A local extension that I made to Struts 1.0 is possibly germane to this discussion. If you don't mind looking at ActionServlet-based code I'll post my work here. I might go ahead and translate it to RequestProcessor. I planned to eventually do this all along, since all it did was override several

RE: composable RequestProcessor

> -Original Message- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > > That lead to the current discussion, which is mostly theoretical, > since no one who has spent longer extending RequestProcessor is > clamoring for this kind of complexity. Even if they were clamoring, > no one wou

RE: composable RequestProcessor

At this point, I think the main goal is to come up with a decent name for an interface which RequestProcessor could implement How about "IRequestProcessor"? (Yeh, okay so Im of the "every interface should start with an 'I' or the writer should die!" school of thought, as well as the even mo

RE: composable RequestProcessor

> From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: Monday, June 02, 2003 8:54 AM > To: Struts Developers List > Subject: RE: composable RequestProcessor > > > > At this point, I think the main goal is to come up with a decent name > for an interface which RequestProcessor could implement > >

Re: composable RequestProcessor

Could be, except if it's not something anyone really wants, we should probably just skip it! The whole question arose simply because one of my colleagues wanted to provide special processing for just processActionForm() and she didn't want to make the decision between extending RequestProcess

RE: composable RequestProcessor

Hehe. Guess this is one of those 'religious' coding convention topics ;-) Your right about the warts in this case though, in that the other struts interfaces dont use that convention so it would kinda stand out like a sore thumb. Hmm. I think Im starting to loose track of the thread here! How come

RE: composable RequestProcessor

> -Original Message- > > Come to think of it, when is struts going to depend on > servlet 2.3 and no > longer support 2.2? If thats slated for struts 1.2 perhaps > you could ditch > the AS and RP completely and do something with filters? - > though I suppose > you still want to organise

DO NOT REPLY [Bug 20415] New: - warn when

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

Ok, here is exactly what we use here at Magnet. Please ignore the 1.0-ness. Also excuse the scarcity of Javadocs for the individual methods.. hopefully the stuff at the head of the class explains it. package com.magnetbanking.util.servlet; import java.io.IOException; import javax.servlet.ServletE

DO NOT REPLY [Bug 20417] New: - Attribute idName not declared for NestedRadioTag

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