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 have time to try this, let me know -- but I'd be afraid that if you defined another catalog with the name "struts", it would overwrite the base "struts" catalog instead of merging with it. If that's true, then you either must edit the one chain-config.xml which defines the catalog named "struts" or we would have to specify a different catalog name for this lookup. Perhaps we should just choose "struts.local" or something. This would allow users to add preprocessing behavior without touching the base chain-config.xml, although it doesn't address the other case of mixing commands within the two main chains -- for the moment, I don't see any road to solving that which isn't a lot more work than it's worth, since I feel that users who are choosing to change the core chains are "power users" -- however, the "preprocessing" seems a bit more appropriate to expose to "less powerful" users.
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).
I don't understand how adding parameters to the request path once the Servlet is already processing it could possibly work; does the pre-existing code perform a redirect after manipulating the path? Furthermore, I would think that, at least in SelectAction, if you change the path in that way, it would never find the right Action, because the "getPath" method is really just returning a key for the map of ActionConfig objects -- and changing the key would result in a failed lookup.
I must admit that I've never looked at the strutsws project, so I may have more questions than answers. Is the idea that the same action can respond to a WebServices request as to a browser HTTP request? If that's the case, then you shouldn't need to change SelectAction -- because the same action can "handle" everything. However, you may need to add in new commands or override existing ones so that by the time the Action is executed, the ActionContext has been populated the same way, whether the request came from one source or the other. Thus, isn't the place to change things more like PopulateActionForm? Don't bother with a whole redirect -- if you know how to construct a new URL, then you could just as easily create a map and use BeanUtils.populate(ActionForm, Map) -- then when the Action operates, it has no concern for which method was used to invoke the request. It just trusts that the ActionForm has the right data.
Now, I'm not sure how the response works -- so maybe you want one action (perhaps in preprocess) which simply sets a flag in the ActionContext:
context.put("webService", new Boolean(isWebService(request));Then any later commands could simply test that context value to know when they need to operate in a different way to accommodate the differences of web services.
Is this making sense? Without a better handle on the details of strutsws, I won't be much more help, but unfortunately I don't have time to make a big study of that right now.
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
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
