I do think that it would be much easier in 1.3 than in 1.2 to solve this without doing a forward and re-engaging the request processor; I can see where the complexity of intervening in arbitrary spots in the request process in the "template pattern" approach of the RequestProcessor might make the forward a more attractive solution, but that is one of the issues solved by composing the request processing logic out of a number of small commands.
I started looking a little bit at chain and 1.3 a few minutes ago. Still not qualified to really comment though :)
The only thing I will say is that I had hoped StrutsWS could be brought to 1.3 by just inserting some commands in the chain, but it seems like some other commands might have to be altered. I could be wrong about that, I have more to learn before I could say with any certainty.
I'd suggest adding a preprocessing command which recognizes the SOAP header, as Frank described, and instead of forwarding, simply sets a key/value pair in the ActionContext which other commands can interpret. Then later, you could extend the PopulateForm class to look for the flag and to do its population process based on SOAP data instead of request parameters.
Yep, that's what I was talking about in terms of changing things... extending classes isn't changing them of course, but it's still not the "insert some commands and your done" that I was hoping for. I suppose it's not that bad really, I was just hoping for simple insertions into the chain config.
I'm curious, how does strutsws deal with the response? Is it assumed that all of these requests are actually only ever serving SOAP clients, so that the response is always a SOAP response? Or is the goal to have one action function for both simple HTTP requests as well as SOAP requests?
It is the later. The idea is that a single Action can transparently be called as part of a typical webapp, or by a SOAP client. In fact, I use this in a production app right now in that way... it's a "typical" webapp, more or less!, but some parts of it are exposed as Web Services for other systems to call on. Works great!
In it's current form, when the Action completes in the case of a WS request, the forward returned is discarded and a new one is used. The forward used can be to the default template (which is a JSP that creates a SOAP response from an ActionForm) or one you specify in an optional webservices-config.xml, so you can create a more complex SOAP response if you need to (the default template has some limitations but generally works for relatively simple responses).
If it's the first, then you have nothing else to do; however, if you were interested in the second... well, I suppose you could put something in after the ExecuteAction stage or at the beginning of the process-view chain which consulted the resulting ForwardConfig and, if in "SOAP mode", looked up a different ForwardConfig. Now that you can put arbitrary properties in a ForwardConfig, you could even configure it in-place:
<action path="/SoapOrHttpDoesntMatter" type="com.example.ProcessRequestAction" name="FormBeanName"> <forward name="success" path="/NormalResponse.jsp"> <set-property key="SOAP.path" value="/SOAPResponseTemplate.jsp" /> </forward> </action>
Interesting... there is a good argument to be made for doing that instead of having the separate webservices-config.xml file... although, there are some other things you can specify in that config file as well, so there's a reasonable argument for keeping it separate too (might clutter up struts-config in a hurry). The current config file is actually optional in any case, you can simply drop the new RP in and the plug-in that is required and your Actions can automatically be called by SOAP clients (ignoring security restrictions and session requirements). But, rolling it into struts-config is something to think about.
and then this command early in the process-view chain:
public class AdjustForwardConfigForSoap extends ActionCommandBase {
public boolean execute( ActionContext ctx ) {
if (ctx.containsKey("SOAPModeFlat")) { ForwardConfig fc = ctx.getForwardConfig(); String alternatePath = fc.getProperty("SOAP.path"); if (alternatePath == null) throw new IllegalStateException(); ForwardConfig alt = new ForwardConfig(); alt.setPath(alternatePath); ctx.setForwardConfig(alt); } } }
Typical caveats apply, but I think that would handle it. I'm not totally sure how I feel about a practice of changing the forward config in the process-view chain, but I can't see any other way you'd handle it without having to bind your code a lot more to the specific fact that it might be used in both ways.
Agreed. As it stands now, I'm doing some rather dicey things to make it all work, specifically I'm thinking of the cloning of the ActionMapping and altering it on-the-fly for exception handling. So, what you suggest is better in terms of "proper-ness" at least :)
Joe
Frank
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
