For what I understood you are customizing the RequestProcessor to handle SOAP message requests, right? I dont see Axis and any way of retrieving the WSDL to make a direct call...
If so, maybe instead of customizing the request processor, wouldn't it be best to have a "SOAPform" to process the envelope and then populate the bean? You could define the form-bean as your SOAPForm handler and a regular action-mapping. With the help of Tiles one could define a template definition to return the response in the appropriate format. Template: - soap header - soap body - soap footer How could one use your RequestProcessor if I am using Axis and publishing web services through WSDD or JWS files? I am new to web services but I found very usefull wsdl2java and have my clients process their requests in a somewhat transparent way through the use of SoapBindingStubs. It seems that with your approach I can't call a web service with these stubs but, instead, need to implement some SOAPMessageBuilder+Marshalling/Unmarshalling of JavaBeans to send SOAP messages, something that with JWS files, for example, is completely transparent. Pedro Salgado > Ah, I see. I'm not familiar enough with filters, but I had always > thought they were on the input side only. If that belief is wrong, > then it certainly becomes an option. > > I think at some point to make this really worth anything I'll have to > break my "transparency rule" to some extent. I do like the idea of > generating the output with a JSP because it's just so easy! A little > bit of background... I actually implemented this same thing in a custom > framework we were previously using in-house. In that application I > actually do write out the output in servlets, there is never a forward > to a JSP or anything else typically in the "view" layer. > This works > just fine, but when I started doing it in Struts it ocurred to me that > I could really simplify things by not taking that approach and instead > let the actual XML generation be done in a JSP. That also removed the > one change that was required under the old framework: you did have to > add two function calls to the controller servlets that were exposed as > services. Not a big change, but I wanted to avoid code changes > entirely here. > > At this point my belief is that probably the best way to handle this is > to have an element added to the Action mappings in Struts-Config.xml > that specifies the target JSP for a Web Service request. The default > woudl be the "generic" template I put together, although a bit more > flexible as time goes on. But, the point is that you could then define > an XML template in essence for every Action you wanted to expose as a > service. That would allow for things I probably can't do > automatically. I'd also write a taglib to make life easier (although I > might not have to... the current Struts taglibs might be more than > sufficient on their own). > > That would of course require a change to the DTD for Struts-Config.xml, > so in the mean time what I think I'm going to do is add an optional > config file thatwould be parsed via a plug-in at app startup that would > contain these extra mappings. Fairly trivial exercise, and it leaves > it completely optional, no changes to Struts required. > > Also, I realized on the drive in that there's no need to put the > parameters as a query string as I'm doing... I can just put the parsed > parameters directly into the request object as an attribute. Since > only the second pass of a Web Service request would know or care about > that object, it will basically just remove some code and simplify > things a bit. > > I'm hoping to get these thnigs done today and release a .02 package > before I leave work today (it's nice when your development server is > down and you can't do any real work until the techs rebuild it!)... I > also hope to remove the required actionMappingPath element in the XML > request... I haven't found a way to get at the requested pat > information in RequestProcessor yet, but it seems like something that > should be available at that point, so I probably just have to do some > digging. > > What is AOP by the way? Millions of acronyms out there, I know > thousands of them, but not that one :) > > Thanks very much for the feedback! > > Frank > >>From: "Marco Mistroni" <[EMAIL PROTECTED]> >>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >>Subject: RE: Strus Web Service Enablement >>Date: Thu, 3 Jun 2004 14:25:47 +0100 >> >>Hi, >> Well, main issue here is that if you want everything to be >>transparent >>To the user (including the forward) then whole stuff has to be done so >> that >>Something 'intercepts' the response when XML is contained in it (if I >> can explain myself correctly) >> >>In other way, to do same steps that you have already done with >>RequestProcessor >>Not being familiar with struts internal (other than action &actionform) >> I can't really say where to modify things... >> >>Another way would be, for each CustomAction written, write an >>CustomActionXml that extends CustomAction. This CustomActionXml will Be >> invoked whenever the path is for CustomAction AND the request is in >> XML. The logic will be done in the original CustomAction, difference >> being in the fact that CustomActionXml instead of redirecting to the >> 'original' forward of CustomAction, writes the response to outputWriter >> But this gets cumbersome.. >> >>I would go for doing with response exactly what u r doing with >> request.. Though right now I have no clue on how to do it...maybe u or >> some struts expert which knows inner logic of struts knows? >> >>Will AOP help in any way here? >> >> >>Regards >> marco >> >> >> >> >>Extends >> >>-----Original Message----- >>From: Frank Zammetti [mailto:[EMAIL PROTECTED] >>Sent: 03 June 2004 13:33 >>To: [EMAIL PROTECTED] >>Subject: RE: Strus Web Service Enablement >> >>I have to be honest and say I've never used a filter except for one >> situation to do security on the input side, a very basic application. >> How >>would you envision it being used for the output? >> >> >> >From: "Marco Mistroni" <[EMAIL PROTECTED]> >> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >> >Subject: RE: Strus Web Service Enablement >> >Date: Thu, 3 Jun 2004 10:15:43 +0100 >> > >> >Hi, >> > My 2 cents.... I think that is a great idea!!!! >> > >> >Do u think that using a filter for the response will help? >> > >> >Last year I did something similar (wrote a Struts-based webapp >> >That I was talking to using J2ME and KSOAP..but all I was able >> >To do was to extend existing action and dump the generated XML >> >Into the response.getWriter().write()... I was using axis btw for XML >> stuff on the serverside) >> > >> >Regards >> > marco >> > >> > >> > >> >-----Original Message----- >> >From: Frank Zammetti [mailto:[EMAIL PROTECTED] >> >Sent: 02 June 2004 21:29 >> >To: [EMAIL PROTECTED] >> >Subject: RFC: Strus Web Service Enablement >> > >> >Hello all... I wanted to post this here and get any comments that >>people >> >had >> >so I could decide where to go with it... >> > >> >For the past two days I've been working on a mechanism that would >> allow you >> >to expose existing Struts-based business logic as Web Services >> without changing any existing code. What I offer here is a first >> approximation of >> >that idea. >> > >> >If you might be interested in this, you can download the first >>iteration >> >of >> >the project at http://www.omnytex.com/wst.zip >> > >> >This archive is a sample webapp in exploded format. Just unzip it to >> your >> >webapps directory of your chosen app server and you should be good to >> go. >> >I've only tried it on Tomcat however, so anything else is unknown. >> > >> >In a nutshell, what I've done is written a custom subclass of >> >RequestProcessor. This version will recognize a SOAP-based Web >> Service request, "unroll" the request, and hand it off to a specified >> Action. As >> >far as the Action is concerned, it looks just like a regular HTTP >> form submission, so it processes same as before. Note that the >> request is forwarded back through ActionServlet, so anything you do >> should still work. >> >The RequestProcessor then overrides the destination ActionForward >> that the >> >Action returns, and instead sends it to a special JSP, which renders >>the >> > >> >response XML. The response type is set properly, and the generated >> XML is >> >returned. The XML it generates simply dumps all members of the >> ActionForm, >> >so it's not very smart right now, but as I said, this is a first >> approximation of the idea. >> > >> >So, in the end, you should be able to expose any existing Actions as >>Web >> > >> >Services without changing them. Everything you need is included, >>except >> >for >> >a JDK, but I assume you have that already (!), including a >> dirt-simple test >> >client. It's not a true SOAP client, but it gets the job done. >> > >> >Once you unzip the archive, I suggest reading the readme.txt file in >>the >> > >> >/source directory. This goes into a bit more detail on everything, >> as well >> >as explaining how to use this in your own application. I should also >> note >> >that this RequestProcessor is transparent to non-Web Service >> requests, i.e., >> >you can use it in your existing apps without changing anything >> whether you >> >expose anything as a service or not. >> > >> >I thank anyone in advance that checks this out. Please send me any >> comments >> >or suggestions you may have either to [EMAIL PROTECTED] or just >>post >> > >> >them here. >> > >> >My hope is that given some time to refine this it will be tight >> enough and >> >useful enough that maybe I can present it to the developer list for >> possible >> >inclusion in the base Struts distro. That's of course a ways off, if >>it >> > >> >ever reaches that point, but it's a start I think. >> > >> >Good day to all! >> > >> >Frank >> > >> >_________________________________________________________________ >> Looking to buy a house? Get informed with the Home Buying Guide from >>MSN >> > >> >House & Home. http://coldwellbanker.msn.com/ >> > >> > >> >--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >>_________________________________________________________________ Check >> out the coupons and bargains on MSN Offers! >>http://youroffers.msn.com >> >> >>--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >>--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > _________________________________________________________________ > Looking to buy a house? Get informed with the Home Buying Guide from MSN > House & Home. http://coldwellbanker.msn.com/ > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
