On 04/06/04 16:10, "Marco Mistroni" <[EMAIL PROTECTED]> wrote:
> Hi, > >> How could one use your RequestProcessor if I am using Axis and >> publishing web services through WSDD or JWS files? > > Point here, if I understood correctly, is that frank is implementing > The serverside part. So if you or I or anyone else would use his > package, > It will be for enabling an existing struts application to be called > As webservice. Written this way it seems more interesting: one could use the same struts actions to implement a web-based interface or to transfer data between systems. > > I have used axis long time ago (and not for an advanced example > either..), but wouldn't it be enough if you construct a SOAP message > and send it > To the struts app URL? > Will u have any drawback in doing that, if you abstract the way you call > The webservice? > > > Again, I m no expert with axis, but I thought there was an API that you > Can simply construct an XML message and post it to the webservice URL > (JAXM?) > > >> imitations of my code is that only Strings can currently be passed as >> parameters to a service, and only Strings can be returned, so certainly >> much >> of the full power of Web Services cannot be utilizied (and I'm not sure > I >> see any way to change that based on what I've done), so it's possibly >> always >> going to be of limited utility. I don't expect that this is going to > be >> useful for every Web Service situation, indeed it may only be useful in >> some >> limited subset. > > AFAIK, ultimately in an XML message everything will be reduced to a > String. > If u need for some reason to map it to a specific type, have a look at > The org.commons.beanutils.ConvertingWrapDynaBean class and see if it can > help > > > Dunno what the client would to though...... > > Regars > marco > > > > > > In any case, you've given me some things to go Google now :) > > Frank > >> 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] >> > > _________________________________________________________________ > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
