However, just to level-set as far as the current 1.2.x version goes...
StrutsWS allows an Action to handle Web Service requests (SOAP-based) without changing them in any way. Marco explained it correctly, I'll just expand a bit...
You have a new RequestProcessor... in processPreprocess(), it looks for the SOAPAction header. If it isn't there, everything proceeds as normal, so non-Web Service requests work as always.
If it *is* present though, regardless of its value, the SOAP message (which presumably is the body of the request now) is parsed and a query string is created from it. We then do a forward:
doForward(request.getServletPath() + queryString, request, response);
...so then the RP cycle begins again. At this point, for all intents and purposes, it looks like any other request (with some flags set in request attributes so the RP knows to not parse the SOAP message again), except that all the parameters are on the query string like a GET rather than in the body like a POST. There are some other WS-specific things added to the RP, like cloning the ActionMapping (via an overridden processMapping() method) and overriding the input attribute so that we can be directed to a proper error handling page, some extra stuff after the Action completes to forward to a special JSP that actually renders the SOAP-based response, etc. But really the key point is transforming the incoming SOAP-based message to a query string and restarting the request cycle.
If you want to take a look, feel free: http://sourceforge.net/projects/strutsws/
It was always my intent to port StrutsWS to 1.3 when 1.3 was actually released, but Marco has taken the bull by the horns because he has a need, and I definitely look forward to him getting it working. I think the chain approach is tailor-made for a project like StrutsWS.
Frank
Joe Germuska wrote:
It works, but yes, you are right in the sense that If I override The struts catalog, everything will screw up... unless I have a look at Chain-config before, so that I know what commands are supposed to be In struts chain, and then add mine while keeping original ones.. I think that's the best solution right now..though I don't know if it is the Optimal one
For now, any case where one can't use the default chain should begin with extracting the default chain from the struts-core JAR and editing it, and then explicitly specifying an alternate location for the file in the web.xml init parameters.
>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?
That's what the original WSRequstProcessor was doing (Frank, pls comment if I am saying something wrong).. It was working in the old way (for some reason, the preprocess method was then getting executed twice...and that's what I cannot reproduce, because the second time the request will come into the preprocess method, form will be populated..
if it does a redirect, that would explain the doubling as well as the correct population after the redirect -- but especially in the chain model, I wouldn't advise that as the best way to solve the problem.
However, thanx to your explanation I have one more trial to try.... then I will be lost if it does not work :-)
You always have us here on the list ;-)
Joe
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
