Michael, Having followed the xml as payload route as an alternative to form based input, it is generally pretty easy to adapt to a Struts application as long as you haven't tied your business logic to http or your form. It is likely that many struts applications would need to do something with error handling. This should get easier when commons resources get pulled out of struts.
It seems like there could be value in using axis to deploy struts applications. That would eliminate the double encoding that I think you are implying with the adapter you referred to as spinner. From what I have seen Axis seems pretty flexible and allows you to define new types of services. I have never used Axis to actually deploy a service that was anything other than a standard style so I don't fully understand the work this would entail. Having axis produce a request that is closer to or exactly what struts expects could avoid a lot of adapting. The input side seems pretty close already. David Morris >>> [EMAIL PROTECTED] 01/20/03 04:35PM >>> I too am delivering a project this week, but will get the Axis4Struts cvs setup ASAP so we can start playing with some of the ideas. Is org.apache.struts.axis4struts ok for a package? We need a spinner to take any given FormBean and spin it into a http post for the HTTPRequest to go to Struts .do I suggest a Multipart form/data post as the default as it will be more flexible than a urlencoded post albeit a little more complicated. The FormBean can then be the payload for the WSDL, eh? Or alternatively do we want to make the payload just an xml document and let the implementor handle it? Michael Oliver -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
