Hello Joe, >As an aside, I think reveals an unfortunate (though minor) >shortcoming of the basic chain model: either way, you must edit the >struts chain-config.xml in order to use this behavior. I would >prefer if there were a way for users to register their preprocessing >command without having to extract the chain-config and edit it. That >in itself isn't so bad, but it also makes it harder to track future >changes in the chain-config.xml as distributed and integrate your >local details with newer versions. It almost calls for an AOP-like >configuration realm.
Hold on.... the 'editing' of chain config was my mistake because I didn't want to have too many files while I was testing my app. Now that I remember, in that famous article of Bill Siggelkow it was explained how to 'override' chain processing by just specifying The chain that you want to override.. In that case, I could just write my own custom-config.xml which contains The chain servlet-preprocess (or whatever chain I want to override) and Just declare it.. (like I have done in another very simple app), though I don't know if this will solve problems that you have identified above. >If you changed the behavior of >org.apache.commons.chain.generic.LookupCommand, you would impact >Struts in each of the places where it has a <lookup> element -- >looking up the preprocessing command, looking up the process-action >chain, and looking up the process-view chain. That's probably not > yep, I have noticed it :-) Sorry if I add another question..because there's something that has been bothering me since I am trying to port my app to 1.3. App was frank zammetti's strutsws, that allows to call Struts action using SOAP requests. Without going into details, RequestProcessor.preProcess(), if identifies an incoming XML request, it will extract those parameters and add them to the URL (e.g. /myAction.do) If the request was an XML request, it will extract the parameters from the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y I Have extended the SelectAction.getPath(Context ctx) command so that it does exactly What the original RequestPreprocessor.preProcess() was doing, so that the path returned by getPath(Context ctx) will be /myAction.do?param1=x¶m2=y). But for some reasons, when the flow arrives to my ValidateActionForm subclass (I have extended it to see what was happening) the two parameters for the action form are still null. If instead the request is not a SOAP request, the chain works as normal, and it works just fine (forms get populated & action gets executed). So, I think I am missing one point (or I am not overriding the proper methods). Could you tell me what happens after SelectAction.getPath() gets called? Where does the request go? Because if I can find the part of the code that gets request parameters and populate the form, maybe I can understand what's going on.. If it's not clear, I can mail you my class privately.... Thanx in advance for your reply Regards marco thanx and regards marco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]