However, just to level-set as far as the current 1.2.x version goes...
Thanks, Frank. That helps a lot.
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'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.
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? 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>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.
Joe
--
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]
