Re: sTRUTS 1.3 - chain flow / complex app
On 5/23/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > Marco wrote: > >Does Shale use chain? Could you integrate chain in Shale? > > Shale does use chain, but to be honest, I don't know much more about > it than that. > Shale uses Commons Chain to configure it's application level processing (i.e. the stuff that is performed in its "front controller" filter). Shale does not use Commons Chain for any detailed per-request processing (although you can easily do so for your own application's purposes, by having your action handler (the code that processes a submit button event, sorta like an Action.execute() method in Struts 1.x) look up an appropriate Chain, set up an appropriate Context, and then fire off the chain. For conversation management, Shale also includes Dialog -- a very simple implementation of the same idea that Spring WebFlow fleshes out in all its sophisticated glory. This is quite useful for managing state across a multiple-request dialog with the user. This doesn't use Commons Chain, because it supports transitions to one of several next states, based on logical outcomes -- and the sequential flow nature that Commons Chain provides does not really match that model. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow /again
At 9:23 AM +0100 5/25/05, Marco Mistroni wrote: Hello Joe & all, I have one question regarding the chain.. Am I correct to assume that The SelectInput command that comes after ValidateActionForm in chain-config.xml should be called in case validation fails? How does that happen? Javadoc says that /** * Validate the properties of the form bean for this request. If there are * any validation errors, execute the child commands in our chain; otherwise, * proceed normally. * * @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb 2005) $ */ I think that JavaDoc is misleading. I had wanted to do some rearrangement to the chain around this issue, but have not yet. (To be honest, I'm not really sure what "child commands in our chain" means!) Here's how it works now: in the process action chain, the ValidateActionForm command does the validation and sets a flag in the context. Then, each subsequent command in the chain inspects the value of this and controls its behavior accordingly. This is kind of clumsy, and entangles the commands too much. It would be better to "abort" the chain when the form is invalid, at least as soon as possible. The problem is that commons-chain 1.0 treats a "true" return from a lookup chain as a signal to end ALL chain processing, not just that chain which was looked up. This has been addressed with a configurable property on LookupCommand in an as yet unreleased version of commons-chain. With that, one can "abort" a sub-chain without interrupting the processing of the source chain. There's still the awkward bit of having SelectInput separate from ValidateActionForm -- you have at least one class which needs to be invoked paying attention to this value in the context. I've thought of a few possible chain design approaches, like a branching command or a conditional lookup command, but none have felt so compelling that I wanted to push them in yet. but as far as I could see, SelectInput is just another command that comes after ValidateActionForm... and, one thing that make me more confused, is that if ValidateActionForm fails, it should return true, so the next command (which is SelectInput) shouldn't get executed... That's not true -- as noted above, in commons-chain 1.0, no command in a chain may ever return true without cancelling all chain processing. I found this counter-intuitive, as it seems do you -- and that's why I added the configuration property to LookupCommand. I'd suggest checking out the code -- it should be pretty easy to actually trace through it and get a better handle on what happens in there. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow /again
Hello Joe & all, I have one question regarding the chain.. Am I correct to assume that The SelectInput command that comes after ValidateActionForm in chain-config.xml should be called in case validation fails? How does that happen? Javadoc says that /** * Validate the properties of the form bean for this request. If there are * any validation errors, execute the child commands in our chain; otherwise, * proceed normally. * * @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb 2005) $ */ but as far as I could see, SelectInput is just another command that comes after ValidateActionForm... and, one thing that make me more confused, is that if ValidateActionForm fails, it should return true, so the next command (which is SelectInput) shouldn't get executed... could you clarify me how and when the SelectInput gets called? Thanx and regards marco -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: 23 May 2005 14:10 To: Marco Mistroni; 'Struts Users Mailing List'; 'Frank W. Zammetti' Subject: RE: sTRUTS 1.3 - chain flow / complex app Marco wrote: >Does Shale use chain? Could you integrate chain in Shale? Shale does use chain, but to be honest, I don't know much more about it than that. >I am looking forward to add more complexity for 'testing' the chain.. >If you have anything to suggest me, go ahead :-) .. Just keep doing what you're doing! More than the complexity, it's just valuable to have people using it period. I've been developing a new app on it for a few months now and everything seems to be going smoothly, but I'm sure I don't use every feature of Struts, so having more people use it to make any kind of webapp gives us more chances to flush out any quirks. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - 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]
RE: sTRUTS 1.3 - chain flow / solved
Excellent, I am looking forward to it! Frank -Original Message- From: "Marco Mistroni"<[EMAIL PROTECTED]> Sent: 5/24/05 4:08:39 AM To: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> Cc: "'Struts Users Mailing List'" Subject: RE: sTRUTS 1.3 - chain flow / solved Hello Frank Not at all... just give me couple of days to tidy it up And test also validations samples (which I trust they work since I haven't altered the way strutsws work..) Thanx for your help! I'll send you 'tidy code' in couple of days. Regards marco -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 23 May 2005 23:42 To: Marco Mistroni Cc: 'Struts Users Mailing List' Subject: Re: sTRUTS 1.3 - chain flow / solved Sorry I didn't respond sooner Marco, Fantastic work! I haven't had a chance to look at what you sent me yet, but I definitely look forward to doing so. Would you have any objection to me putting your code out on SF in CVS, maybe as a separate branch? That way others can benefit from your efforts. Take care, Frank Marco Mistroni wrote: > Hello, > Looks like I found a way to make it work! :-) > I have submitted the code to Frank..surely he'll find way to optimize > it.. > For now, I had to extend few commands (SelectAction, ValidateActionForm, > PopulateActionForm & SelectForward) and I had to rewrite struts > chain-config.xml to use my own commands... > > > Thanx to all of you who gave me precious hints! > > Regards > Marco > > > > > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit->Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow / solved
Excellent, I am looking forward to it! Frank -Original Message- From: "Marco Mistroni"<[EMAIL PROTECTED]> Sent: 5/24/05 4:08:39 AM To: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> Cc: "'Struts Users Mailing List'" Subject: RE: sTRUTS 1.3 - chain flow / solved Hello Frank Not at all... just give me couple of days to tidy it up And test also validations samples (which I trust they work since I haven't altered the way strutsws work..) Thanx for your help! I'll send you 'tidy code' in couple of days. Regards marco -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 23 May 2005 23:42 To: Marco Mistroni Cc: 'Struts Users Mailing List' Subject: Re: sTRUTS 1.3 - chain flow / solved Sorry I didn't respond sooner Marco, Fantastic work! I haven't had a chance to look at what you sent me yet, but I definitely look forward to doing so. Would you have any objection to me putting your code out on SF in CVS, maybe as a separate branch? That way others can benefit from your efforts. Take care, Frank Marco Mistroni wrote: > Hello, > Looks like I found a way to make it work! :-) > I have submitted the code to Frank..surely he'll find way to optimize > it.. > For now, I had to extend few commands (SelectAction, ValidateActionForm, > PopulateActionForm & SelectForward) and I had to rewrite struts > chain-config.xml to use my own commands... > > > Thanx to all of you who gave me precious hints! > > Regards > Marco > > > > > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit->Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow / solved
Hello Frank Not at all... just give me couple of days to tidy it up And test also validations samples (which I trust they work since I haven't altered the way strutsws work..) Thanx for your help! I'll send you 'tidy code' in couple of days. Regards marco -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 23 May 2005 23:42 To: Marco Mistroni Cc: 'Struts Users Mailing List' Subject: Re: sTRUTS 1.3 - chain flow / solved Sorry I didn't respond sooner Marco, Fantastic work! I haven't had a chance to look at what you sent me yet, but I definitely look forward to doing so. Would you have any objection to me putting your code out on SF in CVS, maybe as a separate branch? That way others can benefit from your efforts. Take care, Frank Marco Mistroni wrote: > Hello, > Looks like I found a way to make it work! :-) > I have submitted the code to Frank..surely he'll find way to optimize > it.. > For now, I had to extend few commands (SelectAction, ValidateActionForm, > PopulateActionForm & SelectForward) and I had to rewrite struts > chain-config.xml to use my own commands... > > > Thanx to all of you who gave me precious hints! > > Regards > Marco > > > > > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow / solved
Sorry I didn't respond sooner Marco, Fantastic work! I haven't had a chance to look at what you sent me yet, but I definitely look forward to doing so. Would you have any objection to me putting your code out on SF in CVS, maybe as a separate branch? That way others can benefit from your efforts. Take care, Frank Marco Mistroni wrote: Hello, Looks like I found a way to make it work! :-) I have submitted the code to Frank..surely he'll find way to optimize it.. For now, I had to extend few commands (SelectAction, ValidateActionForm, PopulateActionForm & SelectForward) and I had to rewrite struts chain-config.xml to use my own commands... Thanx to all of you who gave me precious hints! Regards Marco -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow / complex app
Marco wrote: Does Shale use chain? Could you integrate chain in Shale? Shale does use chain, but to be honest, I don't know much more about it than that. I am looking forward to add more complexity for 'testing' the chain.. If you have anything to suggest me, go ahead :-) .. Just keep doing what you're doing! More than the complexity, it's just valuable to have people using it period. I've been developing a new app on it for a few months now and everything seems to be going smoothly, but I'm sure I don't use every feature of Struts, so having more people use it to make any kind of webapp gives us more chances to flush out any quirks. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow / complex app
Hello all, >It's interesting to have some more complex use cases to test the >chain model against... I would offer my app as 'guinea pig' for complex cases :-) Currently it's a small app that manage my own 'expenses' (I have a mysql as backend and jboss 3.2.5/tomcat 5.5 as app server)to see What do I spend an where (yeah, I m not that good with money :-) I am updating my db almost automatically via quartz job, using struts as user interface for manual insert of expenses and job scheduling.. I m using castor/hibernate as ORM frameworks, and spring & struts I manage to port it from struts 1.1 to struts 1.3, and I was looking into strutsws cos I want to have J2ME clients that communicates using ksoap. I am looking forward to add more complexity for 'testing' the chain.. If you have anything to suggest me, go ahead :-) .. Does Shale use chain? Could you integrate chain in Shale? Regards marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow / solved
Hello, Looks like I found a way to make it work! :-) I have submitted the code to Frank..surely he'll find way to optimize it.. For now, I had to extend few commands (SelectAction, ValidateActionForm, PopulateActionForm & SelectForward) and I had to rewrite struts chain-config.xml to use my own commands... Thanx to all of you who gave me precious hints! Regards Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
Joe Germuska wrote: I'm not sure I think that would be nice ;-) Seems kind of risky, in that it adds a lot of indeterminacy. That's the main reason why lots of us are down on request chaining too. Just talking about the chain pattern generically... think about trying to implement a recursive problem with a chain implementation... by definition you'd want to do the equivalent of restarting the chain, right? Now, if you want to make the argument that resursive algorithms are somewhat risky, I would tend to agree :) Has never stopped me from using one when appropriate though. That's a gut reaction, but without more demand for it and more consideration of possible side effects, it's not something I'd be likely to implement for fun on a Saturday afternoon or anything... And certainly I have in no way thought this through completely. Plus, I'll repeat my refrain once more: I'm not up to speek on chain and 1.3's usage of it in particular at this point. I may in a few days come to the conclusion that it's a horrible idea myself :) Joe BTW, we are probably creeping into struts-dev turf on this thread here... Well, I'll tell you what... when I feel like I'm up to speed and know what I'm talking about (whether I actually do or not!), if I still think my first thought was right, I'll raise the idea on the dev list (commons dev I'd think is more appropriate). Like I said, a few days from now I may be completely off the idea :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
At 3:23 PM -0400 5/20/05, Frank W. Zammetti wrote: It's interesting to have some more complex use cases to test the chain model against... Absolutely. One thing that would be nice, and maybe it already is and I just don't know enough yet, is to be able to essentially restart the chain at any given point. That of course introduces the possibility of endless loops, but it makes it so that I could just do like restartChain() instead of forwarding back through tbe whole RP cycle. I'm not sure I think that would be nice ;-) Seems kind of risky, in that it adds a lot of indeterminacy. That's the main reason why lots of us are down on request chaining too. That's a gut reaction, but without more demand for it and more consideration of possible side effects, it's not something I'd be likely to implement for fun on a Saturday afternoon or anything... Joe BTW, we are probably creeping into struts-dev turf on this thread here... -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
Joe Germuska wrote: Well, the difference between extending PopulateForm and putting a command after it which re-populates in the case of a SOAP request is small; the only caveat being that in the add-a-command-after model you must do it after or the existing PopulateForm action would clobber your efforts -- subclassing eliminates any questions about the ordering of events. Yeah, I see your point. I'm coming at it from a purely gut instinct perspective... when I stop and think about it, I agree, the different is fairly small. How does the strutsws kit respond to form validation failures? Is the "input" path overwritten when you clone the ActionMapping? You could keep doing that, or you could use the same model described for the forward, that is indicate the failed-validation-path in a property set in the ActionMapping. That's exactly how. Just like there is a default response template, there is a default error template, or you can define your own in webservices-config.xml to do something more. The input is overridden with whichever one applies. I don't know nothing about properness ;-) It's interesting to have some more complex use cases to test the chain model against... Absolutely. One thing that would be nice, and maybe it already is and I just don't know enough yet, is to be able to essentially restart the chain at any given point. That of course introduces the possibility of endless loops, but it makes it so that I could just do like restartChain() instead of forwarding back through tbe whole RP cycle. Well, as I've said all along, I need to get up to speed on chain and 1.3's use of it before I can do more than stick my foot in my mouth here :) I have to get beta2 of AjaxTags out the door first, and I also want to get my file manager app put up on Sruts Apps. After that I'll circle back around and really get in to StrutsWS on 1.3, unless Marco beats me to the punch of course! :) Joe Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
I'd suggest adding a preprocessing command which recognizes the SOAP header, as Frank described, and instead of forwarding, simply sets a key/value pair in the ActionContext which other commands can interpret. Then later, you could extend the PopulateForm class to look for the flag and to do its population process based on SOAP data instead of request parameters. Yep, that's what I was talking about in terms of changing things... extending classes isn't changing them of course, but it's still not the "insert some commands and your done" that I was hoping for. I suppose it's not that bad really, I was just hoping for simple insertions into the chain config. Well, the difference between extending PopulateForm and putting a command after it which re-populates in the case of a SOAP request is small; the only caveat being that in the add-a-command-after model you must do it after or the existing PopulateForm action would clobber your efforts -- subclassing eliminates any questions about the ordering of events. How does the strutsws kit respond to form validation failures? Is the "input" path overwritten when you clone the ActionMapping? You could keep doing that, or you could use the same model described for the forward, that is indicate the failed-validation-path in a property set in the ActionMapping. Typical caveats apply, but I think that would handle it. I'm not totally sure how I feel about a practice of changing the forward config in the process-view chain, but I can't see any other way you'd handle it without having to bind your code a lot more to the specific fact that it might be used in both ways. Agreed. As it stands now, I'm doing some rather dicey things to make it all work, specifically I'm thinking of the cloning of the ActionMapping and altering it on-the-fly for exception handling. So, what you suggest is better in terms of "proper-ness" at least :) I don't know nothing about properness ;-) It's interesting to have some more complex use cases to test the chain model against... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
Joe Germuska wrote: I do think that it would be much easier in 1.3 than in 1.2 to solve this without doing a forward and re-engaging the request processor; I can see where the complexity of intervening in arbitrary spots in the request process in the "template pattern" approach of the RequestProcessor might make the forward a more attractive solution, but that is one of the issues solved by composing the request processing logic out of a number of small commands. I started looking a little bit at chain and 1.3 a few minutes ago. Still not qualified to really comment though :) The only thing I will say is that I had hoped StrutsWS could be brought to 1.3 by just inserting some commands in the chain, but it seems like some other commands might have to be altered. I could be wrong about that, I have more to learn before I could say with any certainty. I'd suggest adding a preprocessing command which recognizes the SOAP header, as Frank described, and instead of forwarding, simply sets a key/value pair in the ActionContext which other commands can interpret. Then later, you could extend the PopulateForm class to look for the flag and to do its population process based on SOAP data instead of request parameters. Yep, that's what I was talking about in terms of changing things... extending classes isn't changing them of course, but it's still not the "insert some commands and your done" that I was hoping for. I suppose it's not that bad really, I was just hoping for simple insertions into the chain config. I'm curious, how does strutsws deal with the response? Is it assumed that all of these requests are actually only ever serving SOAP clients, so that the response is always a SOAP response? Or is the goal to have one action function for both simple HTTP requests as well as SOAP requests? It is the later. The idea is that a single Action can transparently be called as part of a typical webapp, or by a SOAP client. In fact, I use this in a production app right now in that way... it's a "typical" webapp, more or less!, but some parts of it are exposed as Web Services for other systems to call on. Works great! In it's current form, when the Action completes in the case of a WS request, the forward returned is discarded and a new one is used. The forward used can be to the default template (which is a JSP that creates a SOAP response from an ActionForm) or one you specify in an optional webservices-config.xml, so you can create a more complex SOAP response if you need to (the default template has some limitations but generally works for relatively simple responses). If it's the first, then you have nothing else to do; however, if you were interested in the second... well, I suppose you could put something in after the ExecuteAction stage or at the beginning of the process-view chain which consulted the resulting ForwardConfig and, if in "SOAP mode", looked up a different ForwardConfig. Now that you can put arbitrary properties in a ForwardConfig, you could even configure it in-place: Interesting... there is a good argument to be made for doing that instead of having the separate webservices-config.xml file... although, there are some other things you can specify in that config file as well, so there's a reasonable argument for keeping it separate too (might clutter up struts-config in a hurry). The current config file is actually optional in any case, you can simply drop the new RP in and the plug-in that is required and your Actions can automatically be called by SOAP clients (ignoring security restrictions and session requirements). But, rolling it into struts-config is something to think about. and then this command early in the process-view chain: public class AdjustForwardConfigForSoap extends ActionCommandBase { public boolean execute( ActionContext ctx ) { if (ctx.containsKey("SOAPModeFlat")) { ForwardConfig fc = ctx.getForwardConfig(); String alternatePath = fc.getProperty("SOAP.path"); if (alternatePath == null) throw new IllegalStateException(); ForwardConfig alt = new ForwardConfig(); alt.setPath(alternatePath); ctx.setForwardConfig(alt); } } } Typical caveats apply, but I think that would handle it. I'm not totally sure how I feel about a practice of changing the forward config in the process-view chain, but I can't see any other way you'd handle it without having to bind your code a lot more to the specific fact that it might be used in both ways. Agreed. As it stands now, I'm doing some rather dicey things to make it all work, specifically I'm thinking of the cloning of the ActionMapping and altering it on-the-fly for exception handling. So, what you suggest is better in terms of "proper-ness" at least :) Joe Frank - To unsubscribe, e-mail: [EMAIL P
Re: sTRUTS 1.3 - chain flow
However, just to level-set as far as the current 1.2.x version goes... Thanks, Frank. That helps a lot. I do think that it would be much easier in 1.3 than in 1.2 to solve this without doing a forward and re-engaging the request processor; I can see where the complexity of intervening in arbitrary spots in the request process in the "template pattern" approach of the RequestProcessor might make the forward a more attractive solution, but that is one of the issues solved by composing the request processing logic out of a number of small commands. I'd suggest adding a preprocessing command which recognizes the SOAP header, as Frank described, and instead of forwarding, simply sets a key/value pair in the ActionContext which other commands can interpret. Then later, you could extend the PopulateForm class to look for the flag and to do its population process based on SOAP data instead of request parameters. I'm curious, how does strutsws deal with the response? Is it assumed that all of these requests are actually only ever serving SOAP clients, so that the response is always a SOAP response? Or is the goal to have one action function for both simple HTTP requests as well as SOAP requests? If it's the first, then you have nothing else to do; however, if you were interested in the second... well, I suppose you could put something in after the ExecuteAction stage or at the beginning of the process-view chain which consulted the resulting ForwardConfig and, if in "SOAP mode", looked up a different ForwardConfig. Now that you can put arbitrary properties in a ForwardConfig, you could even configure it in-place: and then this command early in the process-view chain: public class AdjustForwardConfigForSoap extends ActionCommandBase { public boolean execute( ActionContext ctx ) { if (ctx.containsKey("SOAPModeFlat")) { ForwardConfig fc = ctx.getForwardConfig(); String alternatePath = fc.getProperty("SOAP.path"); if (alternatePath == null) throw new IllegalStateException(); ForwardConfig alt = new ForwardConfig(); alt.setPath(alternatePath); ctx.setForwardConfig(alt); } } } Typical caveats apply, but I think that would handle it. I'm not totally sure how I feel about a practice of changing the forward config in the process-view chain, but I can't see any other way you'd handle it without having to bind your code a lot more to the specific fact that it might be used in both ways. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
I don't want to comment much, if at all, on the chain-based implementation Marco is trying to accomplish because I am frankly not up to speed on the 1.3 code base and so am not in a position to comment intelligently. I'm trying to help him off the list as best I can, but I'm actually having trouble even before the point he gets to, so I fear I haven't, and may not be for a while, much help to Marco. However, just to level-set as far as the current 1.2.x version goes... StrutsWS allows an Action to handle Web Service requests (SOAP-based) without changing them in any way. Marco explained it correctly, I'll just expand a bit... You have a new RequestProcessor... in processPreprocess(), it looks for the SOAPAction header. If it isn't there, everything proceeds as normal, so non-Web Service requests work as always. If it *is* present though, regardless of its value, the SOAP message (which presumably is the body of the request now) is parsed and a query string is created from it. We then do a forward: doForward(request.getServletPath() + queryString, request, response); ...so then the RP cycle begins again. At this point, for all intents and purposes, it looks like any other request (with some flags set in request attributes so the RP knows to not parse the SOAP message again), except that all the parameters are on the query string like a GET rather than in the body like a POST. There are some other WS-specific things added to the RP, like cloning the ActionMapping (via an overridden processMapping() method) and overriding the input attribute so that we can be directed to a proper error handling page, some extra stuff after the Action completes to forward to a special JSP that actually renders the SOAP-based response, etc. But really the key point is transforming the incoming SOAP-based message to a query string and restarting the request cycle. If you want to take a look, feel free: http://sourceforge.net/projects/strutsws/ It was always my intent to port StrutsWS to 1.3 when 1.3 was actually released, but Marco has taken the bull by the horns because he has a need, and I definitely look forward to him getting it working. I think the chain approach is tailor-made for a project like StrutsWS. Frank Joe Germuska wrote: It works, but yes, you are right in the sense that If I override The struts catalog, everything will screw up... unless I have a look at Chain-config before, so that I know what commands are supposed to be In struts chain, and then add mine while keeping original ones.. I think that's the best solution right now..though I don't know if it is the Optimal one For now, any case where one can't use the default chain should begin with extracting the default chain from the struts-core JAR and editing it, and then explicitly specifying an alternate location for the file in the web.xml init parameters. >I don't understand how adding parameters to the request path once the >Servlet is already processing it could possibly work; does the pre-existing code perform a redirect after manipulating the path? That's what the original WSRequstProcessor was doing (Frank, pls comment if I am saying something wrong).. It was working in the old way (for some reason, the preprocess method was then getting executed twice...and that's what I cannot reproduce, because the second time the request will come into the preprocess method, form will be populated.. if it does a redirect, that would explain the doubling as well as the correct population after the redirect -- but especially in the chain model, I wouldn't advise that as the best way to solve the problem. However, thanx to your explanation I have one more trial to try then I will be lost if it does not work :-) You always have us here on the list ;-) Joe -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow
It works, but yes, you are right in the sense that If I override The struts catalog, everything will screw up... unless I have a look at Chain-config before, so that I know what commands are supposed to be In struts chain, and then add mine while keeping original ones.. I think that's the best solution right now..though I don't know if it is the Optimal one For now, any case where one can't use the default chain should begin with extracting the default chain from the struts-core JAR and editing it, and then explicitly specifying an alternate location for the file in the web.xml init parameters. >I don't understand how adding parameters to the request path once the >Servlet is already processing it could possibly work; does the pre-existing code perform a redirect after manipulating the path? That's what the original WSRequstProcessor was doing (Frank, pls comment if I am saying something wrong).. It was working in the old way (for some reason, the preprocess method was then getting executed twice...and that's what I cannot reproduce, because the second time the request will come into the preprocess method, form will be populated.. if it does a redirect, that would explain the doubling as well as the correct population after the redirect -- but especially in the chain model, I wouldn't advise that as the best way to solve the problem. However, thanx to your explanation I have one more trial to try then I will be lost if it does not work :-) You always have us here on the list ;-) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow
Hello Joe, Thanx a lot for your reply... >If you have time to try this, let me know -- but I'd be afraid that >if you defined another catalog with the name "struts", it would >overwrite the base "struts" catalog instead of merging with it. If >that's true, then you either must edit the one chain-config.xml which >defines the catalog named "struts" or we would have to specify a >different catalog name for this lookup. Perhaps we should just >choose "struts.local" or something. This would allow users to add >preprocessing behavior without touching the base chain-config.xml, >although it doesn't address the other case of mixing commands within >the two main chains -- for the moment, I don't see any road to >solving that which isn't a lot more work than it's worth, since I >feel that users who are choosing to change the core chains are "power >users" -- however, the "preprocessing" seems a bit more appropriate >to expose to "less powerful" users. Yes I have tried, I have defined a servlet-preprocess chain to override What struts does by default. It works, but yes, you are right in the sense that If I override The struts catalog, everything will screw up... unless I have a look at Chain-config before, so that I know what commands are supposed to be In struts chain, and then add mine while keeping original ones.. I think that's the best solution right now..though I don't know if it is the Optimal one >I don't understand how adding parameters to the request path once the >Servlet is already processing it could possibly work; does the >pre-existing code perform a redirect after manipulating the path? That's what the original WSRequstProcessor was doing (Frank, pls comment if I am saying something wrong).. It was working in the old way (for some reason, the preprocess method was then getting executed twice...and that's what I cannot reproduce, because the second time the request will come into the preprocess method, form will be populated.. Welll, maybe I need to add another command similar to what I already have.. >Furthermore, I would think that, at least in SelectAction, if you >change the path in that way, it would never find the right Action, >because the "getPath" method is really just returning a key for the >map of ActionConfig objects -- and changing the key would result in a >failed lookup. Yes, that's exactly what's happening... because I am getting a path of Action.do?param1=x¶m2=y and that does not map to any actinconfig.. However, thanx to your explanation I have one more trial to try then I will be lost if it does not work :-) Thanx a lot and regards! marco I must admit that I've never looked at the strutsws project, so I may have more questions than answers. Is the idea that the same action can respond to a WebServices request as to a browser HTTP request? If that's the case, then you shouldn't need to change SelectAction -- because the same action can "handle" everything. However, you may need to add in new commands or override existing ones so that by the time the Action is executed, the ActionContext has been populated the same way, whether the request came from one source or the other. Thus, isn't the place to change things more like PopulateActionForm? Don't bother with a whole redirect -- if you know how to construct a new URL, then you could just as easily create a map and use BeanUtils.populate(ActionForm, Map) -- then when the Action operates, it has no concern for which method was used to invoke the request. It just trusts that the ActionForm has the right data. Now, I'm not sure how the response works -- so maybe you want one action (perhaps in preprocess) which simply sets a flag in the ActionContext: context.put("webService", new Boolean(isWebService(request)); Then any later commands could simply test that context value to know when they need to operate in a different way to accommodate the differences of web services. Is this making sense? Without a better handle on the details of strutsws, I won't be much more help, but unfortunately I don't have time to make a big study of that right now. >But for some reasons, when the flow arrives to my ValidateActionForm >subclass (I have extended it to see what was happening) the two >parameters for the action form are still null. > >If instead the request is not a SOAP request, the chain works as >normal, and it works just fine (forms get populated & action gets >executed). > >So, I think I am missing one point (or I am not overriding the proper >methods). > >Could you tell me what happens after SelectAction.getPath() gets >called? Where does the request go? >Because if I can find the part of the code that gets request parameters >and populate the form, maybe I can understand what's going on.. > >If it's not clear, I can mail you my class privately > >Thanx in advance for your reply > >Regards > marco > > > > > > > > > > > > > > > > > > > > > > >
RE: sTRUTS 1.3 - chain flow
At 2:43 PM +0100 5/20/05, Marco Mistroni wrote: Hello Joe, As an aside, I think reveals an unfortunate (though minor) shortcoming of the basic chain model: either way, you must edit the struts chain-config.xml in order to use this behavior. I would prefer if there were a way for users to register their preprocessing command without having to extract the chain-config and edit it. That in itself isn't so bad, but it also makes it harder to track future changes in the chain-config.xml as distributed and integrate your local details with newer versions. It almost calls for an AOP-like configuration realm. Hold on the 'editing' of chain config was my mistake because I didn't want to have too many files while I was testing my app. Now that I remember, in that famous article of Bill Siggelkow it was explained how to 'override' chain processing by just specifying The chain that you want to override.. In that case, I could just write my own custom-config.xml which contains The chain servlet-preprocess (or whatever chain I want to override) and Just declare it.. (like I have done in another very simple app), though I don't know if this will solve problems that you have identified above. If you have time to try this, let me know -- but I'd be afraid that if you defined another catalog with the name "struts", it would overwrite the base "struts" catalog instead of merging with it. If that's true, then you either must edit the one chain-config.xml which defines the catalog named "struts" or we would have to specify a different catalog name for this lookup. Perhaps we should just choose "struts.local" or something. This would allow users to add preprocessing behavior without touching the base chain-config.xml, although it doesn't address the other case of mixing commands within the two main chains -- for the moment, I don't see any road to solving that which isn't a lot more work than it's worth, since I feel that users who are choosing to change the core chains are "power users" -- however, the "preprocessing" seems a bit more appropriate to expose to "less powerful" users. Sorry if I add another question..because there's something that has been bothering me since I am trying to port my app to 1.3. App was frank zammetti's strutsws, that allows to call Struts action using SOAP requests. Without going into details, RequestProcessor.preProcess(), if identifies an incoming XML request, it will extract those parameters and add them to the URL (e.g. /myAction.do) If the request was an XML request, it will extract the parameters from the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y I Have extended the SelectAction.getPath(Context ctx) command so that it does exactly What the original RequestPreprocessor.preProcess() was doing, so that the path returned by getPath(Context ctx) will be /myAction.do?param1=x¶m2=y). I don't understand how adding parameters to the request path once the Servlet is already processing it could possibly work; does the pre-existing code perform a redirect after manipulating the path? Furthermore, I would think that, at least in SelectAction, if you change the path in that way, it would never find the right Action, because the "getPath" method is really just returning a key for the map of ActionConfig objects -- and changing the key would result in a failed lookup. I must admit that I've never looked at the strutsws project, so I may have more questions than answers. Is the idea that the same action can respond to a WebServices request as to a browser HTTP request? If that's the case, then you shouldn't need to change SelectAction -- because the same action can "handle" everything. However, you may need to add in new commands or override existing ones so that by the time the Action is executed, the ActionContext has been populated the same way, whether the request came from one source or the other. Thus, isn't the place to change things more like PopulateActionForm? Don't bother with a whole redirect -- if you know how to construct a new URL, then you could just as easily create a map and use BeanUtils.populate(ActionForm, Map) -- then when the Action operates, it has no concern for which method was used to invoke the request. It just trusts that the ActionForm has the right data. Now, I'm not sure how the response works -- so maybe you want one action (perhaps in preprocess) which simply sets a flag in the ActionContext: context.put("webService", new Boolean(isWebService(request)); Then any later commands could simply test that context value to know when they need to operate in a different way to accommodate the differences of web services. Is this making sense? Without a better handle on the details of strutsws, I won't be much more help, but unfortunately I don't have time to make a big study of that right now. But for some reasons, when the flow arrives to my ValidateActionForm subclass (I have extended it to see what wa
RE: sTRUTS 1.3 - chain flow
Hello Joe, >As an aside, I think reveals an unfortunate (though minor) >shortcoming of the basic chain model: either way, you must edit the >struts chain-config.xml in order to use this behavior. I would >prefer if there were a way for users to register their preprocessing >command without having to extract the chain-config and edit it. That >in itself isn't so bad, but it also makes it harder to track future >changes in the chain-config.xml as distributed and integrate your >local details with newer versions. It almost calls for an AOP-like >configuration realm. Hold on the 'editing' of chain config was my mistake because I didn't want to have too many files while I was testing my app. Now that I remember, in that famous article of Bill Siggelkow it was explained how to 'override' chain processing by just specifying The chain that you want to override.. In that case, I could just write my own custom-config.xml which contains The chain servlet-preprocess (or whatever chain I want to override) and Just declare it.. (like I have done in another very simple app), though I don't know if this will solve problems that you have identified above. >If you changed the behavior of >org.apache.commons.chain.generic.LookupCommand, you would impact >Struts in each of the places where it has a element -- >looking up the preprocessing command, looking up the process-action >chain, and looking up the process-view chain. That's probably not > yep, I have noticed it :-) Sorry if I add another question..because there's something that has been bothering me since I am trying to port my app to 1.3. App was frank zammetti's strutsws, that allows to call Struts action using SOAP requests. Without going into details, RequestProcessor.preProcess(), if identifies an incoming XML request, it will extract those parameters and add them to the URL (e.g. /myAction.do) If the request was an XML request, it will extract the parameters from the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y I Have extended the SelectAction.getPath(Context ctx) command so that it does exactly What the original RequestPreprocessor.preProcess() was doing, so that the path returned by getPath(Context ctx) will be /myAction.do?param1=x¶m2=y). But for some reasons, when the flow arrives to my ValidateActionForm subclass (I have extended it to see what was happening) the two parameters for the action form are still null. If instead the request is not a SOAP request, the chain works as normal, and it works just fine (forms get populated & action gets executed). So, I think I am missing one point (or I am not overriding the proper methods). Could you tell me what happens after SelectAction.getPath() gets called? Where does the request go? Because if I can find the part of the code that gets request parameters and populate the form, maybe I can understand what's going on.. If it's not clear, I can mail you my class privately Thanx in advance for your reply Regards marco thanx and regards marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow
No, rather than changing LookupCommand, you would put your logic into one or more classes that are clean implementations of Command and configure in a catalog with a name so that the existing lookup command would find them -- either put them in catalog "struts" under the name "servlet-standard-preprocess" or change the configuration of the lookup command to find them: catalogName="*your catalog*" name="*your command name*" optional="true"/> You shouldn't need to change the behavior of LookupCommand itself -- you just need to give it the right information to do its job. As an aside, I think reveals an unfortunate (though minor) shortcoming of the basic chain model: either way, you must edit the struts chain-config.xml in order to use this behavior. I would prefer if there were a way for users to register their preprocessing command without having to extract the chain-config and edit it. That in itself isn't so bad, but it also makes it harder to track future changes in the chain-config.xml as distributed and integrate your local details with newer versions. It almost calls for an AOP-like configuration realm. Also, to clarify: And so, I will need to replace this entry in chain-config.xml with This element is just a bit of syntactic sugar that Craig came up with in the chain-config digesting process that allows you to do this once and then later have simpler configuration, say for example if you use a given command frequently. It's comparable to the tag in Ant. But again, the whole intention of the LookupCommand is that instead of changing its behavior, you point it at the other commands which you want executed. If you changed the behavior of org.apache.commons.chain.generic.LookupCommand, you would impact Struts in each of the places where it has a element -- looking up the preprocessing command, looking up the process-action chain, and looking up the process-view chain. That's probably not what you want. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sTRUTS 1.3 - chain flow
Hello Joe, I have read in a sample chain-config.xml that I have downloaded, That RequestProcessor.processPreprocess maps now to 'LookupCommand with optional="true"' Does that mean that, If in my webapp my RequestProcessor.processPreProcess was doing some logic, now I have to put that logic into a Class that extends LookUpCommand? And so, I will need to replace this entry in chain-config.xml with ? thanx in advance and regards marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sTRUTS 1.3 - chain flow
At 10:05 AM +0100 5/17/05, Marco Mistroni wrote: Hello Joe, I am trying to port an app (Frank Zammetti's strutsws)that was using Struts 1.1 to Struts 1.3. I have a quick question: in which class/method the ActionForm is populated with parameters from request? org.apache.struts.chain.commands.servlet.PopulateActionForm (exending org.apache.struts.chain.commands.AbstractPopulateActionForm) http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/chain/commands/servlet/PopulateActionForm.java?root=Apache-SVN&rev=170126&view=log http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractPopulateActionForm.java?root=Apache-SVN&rev=169091&view=log Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]