Frederik, Great vision, good analysis, nice solution. Think of animated "puppet" cartoons in Flash steered by a remote Jboss-story-server via SOAP ;-)
I guess you proposed having a dedicated AxisService/PatchedAxisServlet for Flash (i.e. a customized jboss-net-service.xml that could be installed in addition to/alternatively the jboss-net.jar!META-INF/jboss-service.xml) ... This would finally justify the time I spent to allow several AxisEngines in jboss ;-) I have no objections putting another Servlet into the jboss-net.jar, because we could derive it from the existing one and redundancy should be minimal, right? Go ahead, post the stuff (maybe as a patch through sourceforge that is assigned to me such that I will be reminded ;-) and please report any success stories or problems that you encounter with jboss.net, such that we can ensure that the stuff is working for everyone! CGJ -----Ursprüngliche Nachricht----- Von: Frederick N. Brier [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 17. April 2002 09:26 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] JBoss.net idea for Macromedia Flash support Macromedia Flash 5 and Flash MX has XML support, but due to its limitations cannot generate the exact HTTP headers, specifically SOAPAction, required by SOAP. Flash is installed in over 98% of the browsers and provides a cross platform intelligent (Actionscript) client. In a user group presentation they alluded to a product that would be a Cold Fusion server to Flash client architecture with XML providing the glue. I think JBoss can beat them there with a few small mods to JBoss.net. The idea is to add a doPost() method to the JBoss.net AxisServiceServlet class. It would preprocess the HttpServletRequest headers using a massaging class specified via XML generating a HashMap. It would then wrap the original HttpServletRequest and the HashMap in a class derived from HttpServletRequestWrapper which overrides the getHeader methods. The new request object is passed to the parent's doPost() implementation - AxisServlet. Specifically for Flash, we could appear to move a SOAPAction and Content-Type parameters to the HTTP Header. I've already started writing this and would like to finish it and contribute it. I'm just not sure how to participate in the process, and need some feedback on whether this is desired, acceptable, and if so, where the massaging class should be specified. One issue is that we are violating the SOAP spec, but several products and work-a-rounds already exist, mostly for ASP. Specifying a massaging class allows us to support other hamstrung clients. We could also associate the massaging class with a url-pattern either in install-axis.xml, another extension to the Axis deployment descriptor in the application's web-service.xml file. The changes and additions are fairly small and I could just post them to the mailing list after I get some feedback and get it working. I think this is an important technology with which to interface. With the addition of Flash plug-in's encrypted sandbox, private keys can be stored on the client side and used for authentication in implementing security. Please let me know what you think. Frederick N. Brier Sr. Software Engineer Multideck Corporation _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
