> I still haven't really absorbed the rationale for this, and my
> difficulty in answering some of your questions make me willing to
> step up and say so.
> Maybe it would help if we could frame the goal of the project, in
> terms of more than "wouldn't it be cool?"
How about:
> My understanding is that people would like to be able to use Struts
> as a single controller, with multiple "views" -- a web services view
> as well as more familiar browser views. If this is the case, then it
> seems that it would make sense to integrate Struts and Axis into a
> single web application.
> I'm much more familiar with Struts than with Axis, but I've been
> poking around the Axis architecture guide a bit
> <
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/architecture-guide.html
>
> It seems to me that encoding and decoding SOAP is the most
> complicated step, so my hunch would be to plug Struts into Axis
> instead of the other way around. Perhaps you could write a
> StrutsProvider class, parallel to the RPC, Message, Wrapped, and
> Document providers; this would take the decoded SOAP message and pass
> it into Struts. Here's where I think you run into a snag,
> considering that Struts is bound to the Servlet API in the execute()
> method signature, while it's possible that Axis could have been
> triggered by a non-HTTP transport. But if you just took it for
> granted that Axis was only working in HTTP (for now), you can get at
> the HTTP environment through the Axis MessageContext. It seems that
> the Axis JavaDoc isn't online, so it'll take some more investigation
> to figure out what this is really all about.
> An alternative might be to have a customized Struts RequestProcessor
> recognize a SOAP request early on and call on Axis classes to unpack
> things before using the struts-config to lookup an action to process
> stuff. This might allow you to populate an ActionForm object as the
> primary means for passing data in to the Struts Action. You could
> then reuse a single Struts Action class at mapped to two different
> action paths so that you could have mapping-specific forwards (i.e.
> each mapping would have a "success" named-forward, one of which would
> make an HTML page and one of which would produce a SOAP response...
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
