2010/4/20 Francisco José Aquino García fj.aqu...@gmail.com:
Where are the sources for xwork-core-2.1.6 then?
Here you have the latest version
svn.apache.org/viewvc/struts/struts2/trunk/
The old can be found here
http://svn.opensymphony.com/fisheye/browse/xwork
Regards
--
Łukasz
Nice, that 'merge' parameter.
I'm still using Struts2 2.1.6 and had already stumbled on this.
Worked around it using params.excludeParams on the statically-parameterized
actions to filter out the static params.
Browsing the latest distribution I've noticed that it bundles
xwork-core-2.1.6.jar but
2010/3/17 Francisco José Aquino García fj.aqu...@gmail.com:
Browsing the latest distribution I've noticed that it bundles
xwork-core-2.1.6.jar but the latest version listed on the XWork home page is
2.1.5... has Struts2 forked xwork-core-2.1.6 from the official XWork?
Yap, XWork is part of
Ok, this is all great, but problem still is not solved.
You can see configs provided @ war.
I will put this simple:
My app`s config is taken from struts-blank, so its minimal, and there are no
explicit changes in interceptor stack for any of actions. Why this crap
happens then? I really dont care
you are confusing static parameters with request parameters. You *do
not* need to add param to your action mapping to get the parameters
bound the class fields. You add param to your action mapping to
inject things into your action, IoC style, but is is not needed for
request parameters. So if you
action name=person-*-* class=example.Person
param name=cmd{1}/param
param name=id{2}/param
resultjsp/abc.jsp/result
/action
You *do
not* need to add param to your action mapping to get the parameters
bound the class fields.
I understand
Ok I see it now. The staticparams interceptor adds the params to the
request params map, so that would explain why it is called again. We
could add a setting to the result to prevent this if needed.
musachy
On Fri, Jul 17, 2009 at 10:18 AM, Ritvars Rundzānsrrundz...@gmail.com wrote:
Musachy Barroso wrote:
Ok I see it now. The staticparams interceptor adds the params to the
request params map, so that would explain why it is called again. We
could add a setting to the result to prevent this if needed.
I would argue that each of {staticP,actionMappingP,p}arams should both
We cant change it because it would break backward compatibility. I
added a merge parameter to the static parameters
interceptor(defaults to true):
http://jira.opensymphony.com/browse/XW-709
fixed in xwork trunk. Thanks for reporting!
musachy
On Fri, Jul 17, 2009 at 12:02 PM, Dale
Hi!
I am wondering, why setters for cmd and id fields @ my Person action (see
below) is called twice. For example, when browser requests
/person-aaa-bbb?dum=ccc , this gets stdout-ed :
example.per...@113981b 18061339
setCmd ]aaa[
setId ]bbb[
setCmd ]aaa[
setDum ]ccc[
setId ]bbb[
execute
I know
can you put a breakpoint in the setter and see where is it called
from? (both times)
musachy
On Thu, Jul 16, 2009 at 8:08 AM, Ritvars Rundzānsrrundz...@gmail.com wrote:
Hi!
I am wondering, why setters for cmd and id fields @ my Person action (see
below) is called twice. For example, when
I put BP @ setCmd.
1st hit:
Daemon Thread [http-8080-2] (Suspended (breakpoint at line 28 in Person))
Person.setCmd(String) line: 28
NativeMethodAccessorImpl.invoke0(Method, Object, Object[])
#1 is from the static param interceptor, so you have that set up
somewhere, and the second one is from the normal request parameter
(params interceptor)
On Thu, Jul 16, 2009 at 10:35 AM, Ritvars Rundzānsrrundz...@gmail.com wrote:
I put BP @ setCmd.
1st hit:
Look carefully! As you can see, BOTH setters origin from static params
interceptor (1st: line 129, 2nd - line 148).
And i do not have set it up somewhere - look @ war. Config is as simple as
possible.
uh? This is from the 2nd stack:
ParametersInterceptor.doIntercept(ActionInvocation) line: 187
ParametersInterceptor(MethodFilterInterceptor).intercept(ActionInvocation)
musachy
On Thu, Jul 16, 2009 at 1:33 PM, Ritvars Rundzānsrrundz...@gmail.com wrote:
Look carefully! As you can see, BOTH
Yes, 2nd one contains ParametersInterceptor call, but both of them contains
StaticParametersInterceptor call. You mentioned, that static param
interceptor, so you have that set up
somewhere. There are no explicitly defined interceptors @ my-super-app.
Ok, whatewer, this is irrelevant. Just deploy
Ritvars Rundza-ns wrote:
Yes, 2nd one contains ParametersInterceptor call, but both of them contains
StaticParametersInterceptor call. You mentioned, that static param
interceptor, so you have that set up
somewhere. There are no explicitly defined interceptors @ my-super-app.
The default stack
17 matches
Mail list logo
