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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>thanx and regards
> marco
--
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]
