You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Volker Krebs <vo...@abas.de> on 2014/11/06 17:02:55 UTC
Re: Struts 2.3.18 ready for test
I still have an odd behavior and can't figure out what has changed from
2.3.16.3 to 2.3.18
We have an Action with an service interface as class member.
Something like this pseudo Action:
public class EditAction extends ActionSupport implements Preparable {
protected MyService myService;
public void prepare() throws Exception {
myService = new MyServiceImpl();
}
public String execute() throws Exception {
myService.doSomething();
}
}
In 2.3.16.3 this works fine.
In 2.3.18 I get the following exception.
As you can see from the stack trace we're using spring integration plugin.
2014-11-06 03:14:05,040 ERROR [http-bio-60123-exec-5]
com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could
not create and/or set value back on to object
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'com.mycompany.interfaces.MyService': Could not resolve
matching constructor
at
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:238)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowire(AbstractAutowireCapableBeanFactory.java:308)
at
com.opensymphony.xwork2.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:194)
at
com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:163)
at
com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:137)
at
com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:21)
at ognl.ASTProperty.getValueBody(ASTProperty.java:118)
at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
at ognl.SimpleNode.getValue(SimpleNode.java:258)
at ognl.ASTChain.setValueBody(ASTChain.java:222)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:185)
at
com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:172)
at
com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:150)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:309)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:227)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:244)
at
org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
at
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564)
at
org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
at
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
Any Ideas ?
Thanks
Volker
Am 21.09.2014 um 15:36 schrieb Lukasz Lenart:
> Hi,
>
> Please take a time and test the bits - any help is appreciated. Please
> report back any problems. I'll call for vote in a week if no problems
> will be spotted.
>
> Staging Maven repo
> https://repository.apache.org/content/groups/staging/
>
> Standalone artifacts
> http://people.apache.org/builds/struts/2.3.18/
>
> Release notes
> https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.18
>
>
> Thanks in advance & regards
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-07 16:44 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Yes my workaround was to directly exclude orderinfo param.
>
> I don't know if it is broken. But when the behavior of
> <param name="acceptParamNames">param1</param>
> should be to ignore every parameter but param1, then it's not working as
> expected.
Yeah, it's broken as this will open what was blocked previously :(
> I'll try to make a simple example on monday to test it.
Great! Thanks a lot!
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-13 14:40 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Yes, thats good.
Great!
> I have extended my example a bit and will prepare a PR.
Great! Great!
Cheers
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 13.11.2014 um 11:22 schrieb Lukasz Lenart:
> 2014-11-13 10:57 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> For exclude pattern I would use addExcludedPatterns and for accept patterns
>> I would use setAcceptedPatterns.
>> IMO, just by setting (adding) an exclude pattern it shouldn't be possible to
>> overwrite security relevant excludes.
>
> This is a good idea except this changes the previous behaviour -
> that's why I have reverted everything to not surprise users. We can
> think about that when I start working on 2.5
>
>> But I don't know exactly what the purpose of
>> DefaultAcceptedPatternsChecker.ACCEPTED_PATTERNS is. So I'm skating a bit on
>> thin ice here.
>
> Yeah... the same here :-)
>
> I assume this is good and works for you?
>
Yes, thats good.
I have extended my example a bit and will prepare a PR.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-13 10:57 GMT+01:00 Volker Krebs <vo...@abas.de>:
> For exclude pattern I would use addExcludedPatterns and for accept patterns
> I would use setAcceptedPatterns.
> IMO, just by setting (adding) an exclude pattern it shouldn't be possible to
> overwrite security relevant excludes.
This is a good idea except this changes the previous behaviour -
that's why I have reverted everything to not surprise users. We can
think about that when I start working on 2.5
> But I don't know exactly what the purpose of
> DefaultAcceptedPatternsChecker.ACCEPTED_PATTERNS is. So I'm skating a bit on
> thin ice here.
Yeah... the same here :-)
I assume this is good and works for you?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 12.11.2014 um 13:40 schrieb Lukasz Lenart:
> 2014-11-12 13:25 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> Am 12.11.2014 um 10:07 schrieb Lukasz Lenart:
>>>
>>> 2014-11-10 16:30 GMT+01:00 Volker Krebs <vo...@abas.de>:
>>>>
>>>> https://github.com/VolkerK/struts-examples/
>>>> branch develop
>>>
>>>
>>> Thanks a lot for the example, it was very helpful! Btw. you can
>>> prepare a PR to push it to the struts-example project :-)
>>>
>>> One remark, you cannot use such configuration:
>>>
>>> <interceptor-ref name="params">
>>> <param name="params">someParameter</param>
>>> </interceptor-ref>
>>> <interceptor-ref name="basicStack"/>
>>>
>>> as in such case params interceptor will run two times - first as a
>>> part of defaultStack and second time as a part of basicStack, you must
>>> use it that way
>>>
>>
>> Actually this is what I wanted to do. A couple of years ago I read somewhere
>> about the params - prepare - params approach.
>>
>> First set some paras that are required in the prepare method, and then after
>> prepare is finished set the some more params (and don't overwrite the ones
>> from the first params call).
>>
>> Ok that's probably too much of the domain (back-end) logic pressed into the
>> struts framework (workflow), but thats how I did it years ago when
>> I was naive and unexperienced :)
>
> Good to know, at least you know what you doing :-)
>
> Can I prepare new release, what do you think?
>
>
For exclude pattern I would use addExcludedPatterns and for accept
patterns I would use setAcceptedPatterns.
IMO, just by setting (adding) an exclude pattern it shouldn't be
possible to overwrite security relevant excludes.
But I don't know exactly what the purpose of
DefaultAcceptedPatternsChecker.ACCEPTED_PATTERNS is. So I'm skating a
bit on thin ice here.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-12 13:25 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Am 12.11.2014 um 10:07 schrieb Lukasz Lenart:
>>
>> 2014-11-10 16:30 GMT+01:00 Volker Krebs <vo...@abas.de>:
>>>
>>> https://github.com/VolkerK/struts-examples/
>>> branch develop
>>
>>
>> Thanks a lot for the example, it was very helpful! Btw. you can
>> prepare a PR to push it to the struts-example project :-)
>>
>> One remark, you cannot use such configuration:
>>
>> <interceptor-ref name="params">
>> <param name="params">someParameter</param>
>> </interceptor-ref>
>> <interceptor-ref name="basicStack"/>
>>
>> as in such case params interceptor will run two times - first as a
>> part of defaultStack and second time as a part of basicStack, you must
>> use it that way
>>
>
> Actually this is what I wanted to do. A couple of years ago I read somewhere
> about the params - prepare - params approach.
>
> First set some paras that are required in the prepare method, and then after
> prepare is finished set the some more params (and don't overwrite the ones
> from the first params call).
>
> Ok that's probably too much of the domain (back-end) logic pressed into the
> struts framework (workflow), but thats how I did it years ago when
> I was naive and unexperienced :)
Good to know, at least you know what you doing :-)
Can I prepare new release, what do you think?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 12.11.2014 um 10:07 schrieb Lukasz Lenart:
> 2014-11-10 16:30 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> https://github.com/VolkerK/struts-examples/
>> branch develop
>
> Thanks a lot for the example, it was very helpful! Btw. you can
> prepare a PR to push it to the struts-example project :-)
>
> One remark, you cannot use such configuration:
>
> <interceptor-ref name="params">
> <param name="params">someParameter</param>
> </interceptor-ref>
> <interceptor-ref name="basicStack"/>
>
> as in such case params interceptor will run two times - first as a
> part of defaultStack and second time as a part of basicStack, you must
> use it that way
>
Actually this is what I wanted to do. A couple of years ago I read
somewhere about the params - prepare - params approach.
First set some paras that are required in the prepare method, and then
after prepare is finished set the some more params (and don't overwrite
the ones from the first params call).
Ok that's probably too much of the domain (back-end) logic pressed into
the struts framework (workflow), but thats how I did it years ago when
I was naive and unexperienced :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-10 16:30 GMT+01:00 Volker Krebs <vo...@abas.de>:
> https://github.com/VolkerK/struts-examples/
> branch develop
Thanks a lot for the example, it was very helpful! Btw. you can
prepare a PR to push it to the struts-example project :-)
One remark, you cannot use such configuration:
<interceptor-ref name="params">
<param name="params">someParameter</param>
</interceptor-ref>
<interceptor-ref name="basicStack"/>
as in such case params interceptor will run two times - first as a
part of defaultStack and second time as a part of basicStack, you must
use it that way
<interceptor-ref name="basicStack">
<param name="params.acceptParamNames">someParameter</param>
</interceptor-ref>
in such case, action will be executed with basicStack with modified
acceptParamNames
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 10.11.2014 um 11:38 schrieb Lukasz Lenart:
> 2014-11-10 11:35 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> Am 10.11.2014 um 08:50 schrieb Lukasz Lenart:
>>>
>>> I've reverted changes regarding "acceptParamNames" - can you check
>>> with the latest snapshot?
>>>
>>
>> Looks like something is broken, acceptParamNames is applied to every action,
>> not just to the one where it is defined.
>>
>> At the moment I'm trying to extend the exclude_parameters example.
>
> That would be osm! as I cannot reproduce the behaviour with my examples.
>
https://github.com/VolkerK/struts-examples/
branch develop
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-10 11:35 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Am 10.11.2014 um 08:50 schrieb Lukasz Lenart:
>>
>> I've reverted changes regarding "acceptParamNames" - can you check
>> with the latest snapshot?
>>
>
> Looks like something is broken, acceptParamNames is applied to every action,
> not just to the one where it is defined.
>
> At the moment I'm trying to extend the exclude_parameters example.
That would be osm! as I cannot reproduce the behaviour with my examples.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 10.11.2014 um 08:50 schrieb Lukasz Lenart:
> I've reverted changes regarding "acceptParamNames" - can you check
> with the latest snapshot?
>
Looks like something is broken, acceptParamNames is applied to every
action, not just to the one where it is defined.
At the moment I'm trying to extend the exclude_parameters example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
I've reverted changes regarding "acceptParamNames" - can you check
with the latest snapshot?
Thanks in advance
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2014-11-07 16:44 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Am 07.11.2014 um 16:34 schrieb Lukasz Lenart:
>
>> 2014-11-07 16:27 GMT+01:00 Volker Krebs <vo...@abas.de>:
>>>
>>> Ok, it has to do with the acceptParamNames in ParametersInterceptor
>>> I'll have the following config for my action:
>>> <interceptor-ref name="params">
>>> <param name="acceptParamNames">orderTimeID</param>
>>> </interceptor-ref>
>>>
>>> In my action I have a property named "orderinfo".
>>> In 2.3.16.3 the ParametersInterceptor only set "orderTimeID".
>>> Calls to "orderinfo" were blocked. This is what I was expecting, a pure
>>> white list approach, block everything which is not "orderTimeID".
>>>
>>> In 2.3.18 the ParametersInterceptor tried to set orderinfo. Only when
>>> explicitly excluding it, everything worked as before.
>>> <interceptor-ref name="params">
>>> <param name="acceptParamNames">orderTimeID</param>
>>> <param name="excludeParams">ordertime\..*</param>
>>> </interceptor-ref>
>>
>>
>> Does it mean you have workaround but excluding params mechanism is
>> broken? As I understand you had to directly exclude orderinfo param?
>>
>
> Yes my workaround was to directly exclude orderinfo param.
>
> I don't know if it is broken. But when the behavior of
> <param name="acceptParamNames">param1</param>
> should be to ignore every parameter but param1, then it's not working as
> expected.
>
> I'll try to make a simple example on monday to test it.
>
> Have a nice weekend :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 08.11.2014 um 17:49 schrieb Lukasz Lenart:
> 2014-11-07 16:44 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> Yes my workaround was to directly exclude orderinfo param.
>>
>> I don't know if it is broken. But when the behavior of
>> <param name="acceptParamNames">param1</param>
>> should be to ignore every parameter but param1, then it's not working as
>> expected.
>
> I found where the problem is. Right now "acceptParamNames" are added
> to existing ACCEPTED_PATTERNS defined in
> DefaultAcceptedPatternsChecker - previously "acceptParamNames" were
> overriding default patterns from ACCEPTED_PATTERNS.
>
> You can still override the default patterns with
> "struts.override.excludedPatterns" and then use "acceptParamNames" to
> relax the those global patterns. Or you can implement your own version
> of AcceptedPatternsChecker.
>
> Basically I have to update docs about that. It was introduced by that
> PR -> https://github.com/apache/struts/pull/11
>
> The question is if this is a better solution? You have a lot of
> options to check accepted params but maybe it's too complicated? Let
> me know what you think.
>
>
My application was relying that certain parameters were blocked.
So adding global accept pattern could break backwards compatibility.
I think when defining acceptParamNames only those should be passed
to the action. Everything else should be blocked. (white list approach)
When not defining any acceptParamNames all parameters should be passed
except the ones in the excludedPatterns. (black list approach)
The black list approach is difficult, because you
will definitely forget some patterns. But a pure white list approach
would break a lot of applications. Because everybody must define the
parameters he needs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-07 16:44 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Yes my workaround was to directly exclude orderinfo param.
>
> I don't know if it is broken. But when the behavior of
> <param name="acceptParamNames">param1</param>
> should be to ignore every parameter but param1, then it's not working as
> expected.
I found where the problem is. Right now "acceptParamNames" are added
to existing ACCEPTED_PATTERNS defined in
DefaultAcceptedPatternsChecker - previously "acceptParamNames" were
overriding default patterns from ACCEPTED_PATTERNS.
You can still override the default patterns with
"struts.override.excludedPatterns" and then use "acceptParamNames" to
relax the those global patterns. Or you can implement your own version
of AcceptedPatternsChecker.
Basically I have to update docs about that. It was introduced by that
PR -> https://github.com/apache/struts/pull/11
The question is if this is a better solution? You have a lot of
options to check accepted params but maybe it's too complicated? Let
me know what you think.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 07.11.2014 um 16:34 schrieb Lukasz Lenart:
> 2014-11-07 16:27 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> Ok, it has to do with the acceptParamNames in ParametersInterceptor
>> I'll have the following config for my action:
>> <interceptor-ref name="params">
>> <param name="acceptParamNames">orderTimeID</param>
>> </interceptor-ref>
>>
>> In my action I have a property named "orderinfo".
>> In 2.3.16.3 the ParametersInterceptor only set "orderTimeID".
>> Calls to "orderinfo" were blocked. This is what I was expecting, a pure
>> white list approach, block everything which is not "orderTimeID".
>>
>> In 2.3.18 the ParametersInterceptor tried to set orderinfo. Only when
>> explicitly excluding it, everything worked as before.
>> <interceptor-ref name="params">
>> <param name="acceptParamNames">orderTimeID</param>
>> <param name="excludeParams">ordertime\..*</param>
>> </interceptor-ref>
>
> Does it mean you have workaround but excluding params mechanism is
> broken? As I understand you had to directly exclude orderinfo param?
>
Yes my workaround was to directly exclude orderinfo param.
I don't know if it is broken. But when the behavior of
<param name="acceptParamNames">param1</param>
should be to ignore every parameter but param1, then it's not working as
expected.
I'll try to make a simple example on monday to test it.
Have a nice weekend :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-07 16:27 GMT+01:00 Volker Krebs <vo...@abas.de>:
> Ok, it has to do with the acceptParamNames in ParametersInterceptor
> I'll have the following config for my action:
> <interceptor-ref name="params">
> <param name="acceptParamNames">orderTimeID</param>
> </interceptor-ref>
>
> In my action I have a property named "orderinfo".
> In 2.3.16.3 the ParametersInterceptor only set "orderTimeID".
> Calls to "orderinfo" were blocked. This is what I was expecting, a pure
> white list approach, block everything which is not "orderTimeID".
>
> In 2.3.18 the ParametersInterceptor tried to set orderinfo. Only when
> explicitly excluding it, everything worked as before.
> <interceptor-ref name="params">
> <param name="acceptParamNames">orderTimeID</param>
> <param name="excludeParams">ordertime\..*</param>
> </interceptor-ref>
Does it mean you have workaround but excluding params mechanism is
broken? As I understand you had to directly exclude orderinfo param?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 06.11.2014 um 18:09 schrieb Lukasz Lenart:
> 2014-11-06 18:00 GMT+01:00 Lukasz Lenart <lu...@apache.org>:
>> 2014-11-06 17:02 GMT+01:00 Volker Krebs <vo...@abas.de>:
>>> I still have an odd behavior and can't figure out what has changed from
>>> 2.3.16.3 to 2.3.18
>>> We have an Action with an service interface as class member.
>>> Something like this pseudo Action:
>>>
>>> public class EditAction extends ActionSupport implements Preparable {
>>>
>>> protected MyService myService;
>>>
>>> public void prepare() throws Exception {
>>> myService = new MyServiceImpl();
>>> }
>>>
>>> public String execute() throws Exception {
>>> myService.doSomething();
>>> }
>>> }
>>>
>>> In 2.3.16.3 this works fine.
>>> In 2.3.18 I get the following exception.
>>> As you can see from the stack trace we're using spring integration plugin.
>>>
>>>
>>> 2014-11-06 03:14:05,040 ERROR [http-bio-60123-exec-5]
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could not
>>> create and/or set value back on to object
>>> org.springframework.beans.factory.BeanCreationException: Error creating bean
>>> with name 'com.mycompany.interfaces.MyService': Could not resolve matching
>>> constructor
>>> at
>>> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:238)
>>> at
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
>>> at
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowire(AbstractAutowireCapableBeanFactory.java:308)
>>> at
>>> com.opensymphony.xwork2.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:194)
>>> at
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:163)
>>> at
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:137)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:21)
>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:118)
>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
>>> at ognl.SimpleNode.getValue(SimpleNode.java:258)
>>> at ognl.ASTChain.setValueBody(ASTChain.java:222)
>>> at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
>>> at ognl.SimpleNode.setValue(SimpleNode.java:301)
>>> at ognl.Ognl.setValue(Ognl.java:737)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
>>> at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:185)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:172)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:150)
>>> at
>>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:309)
>>> at
>>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:227)
>>> at
>>> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
>>> at
>>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:244)
>>> at
>>> org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
>>> at
>>> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564)
>>> at
>>> org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
>>> at
>>> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>>
>>>
>>> Any Ideas ?
>>
>> Nope :( I was digging around but I don't see anything special. Can you
>> prepare a demo app or post more data?
>
> Just note that the exception is logged in InstantiatingNullHandler
> when it tries to create an object which is null and on which you want
> set a value
>
Ok, it has to do with the acceptParamNames in ParametersInterceptor
I'll have the following config for my action:
<interceptor-ref name="params">
<param name="acceptParamNames">orderTimeID</param>
</interceptor-ref>
In my action I have a property named "orderinfo".
In 2.3.16.3 the ParametersInterceptor only set "orderTimeID".
Calls to "orderinfo" were blocked. This is what I was expecting, a pure
white list approach, block everything which is not "orderTimeID".
In 2.3.18 the ParametersInterceptor tried to set orderinfo. Only when
explicitly excluding it, everything worked as before.
<interceptor-ref name="params">
<param name="acceptParamNames">orderTimeID</param>
<param name="excludeParams">ordertime\..*</param>
</interceptor-ref>
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-07 8:16 GMT+01:00 Volker Krebs <vo...@abas.de>:
> I'm using a params, prepare, params interceptor stack.
> The member "myService" (from the example above) is null
> and the parameter interceptor tries to initialize it.
> Trying to instantiate the Interface.
But it's using Spring to do that, does it mean that this service isn't
defined in Spring context? Also it means that the parameter's value is
set on the service?
> Is it possible to set ReflectionContextState#CREATE_NULL_OBJECTS to false
> via struts config ? This would help.
Rather no, I don't such possibility right now
> But I'm also trying to prepare a small example, since this might be an
> update issue from 2.3.16.3 to 2.3.18
The only change in that area is this and you already posted a comment
(I assumed it as confirmation that this works as expected)
https://issues.apache.org/jira/browse/WW-3603
Please prepare such demo app as I cannot reproduce it locally based on
your example code.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Volker Krebs <vo...@abas.de>.
Am 06.11.2014 um 18:09 schrieb Lukasz Lenart:
> 2014-11-06 18:00 GMT+01:00 Lukasz Lenart <lu...@apache.org>:
>> 2014-11-06 17:02 GMT+01:00 Volker Krebs <vo...@abas.de>:
>>> I still have an odd behavior and can't figure out what has changed from
>>> 2.3.16.3 to 2.3.18
>>> We have an Action with an service interface as class member.
>>> Something like this pseudo Action:
>>>
>>> public class EditAction extends ActionSupport implements Preparable {
>>>
>>> protected MyService myService;
>>>
>>> public void prepare() throws Exception {
>>> myService = new MyServiceImpl();
>>> }
>>>
>>> public String execute() throws Exception {
>>> myService.doSomething();
>>> }
>>> }
>>>
>>> In 2.3.16.3 this works fine.
>>> In 2.3.18 I get the following exception.
>>> As you can see from the stack trace we're using spring integration plugin.
>>>
>>>
>>> 2014-11-06 03:14:05,040 ERROR [http-bio-60123-exec-5]
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could not
>>> create and/or set value back on to object
>>> org.springframework.beans.factory.BeanCreationException: Error creating bean
>>> with name 'com.mycompany.interfaces.MyService': Could not resolve matching
>>> constructor
>>> at
>>> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:238)
>>> at
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
>>> at
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowire(AbstractAutowireCapableBeanFactory.java:308)
>>> at
>>> com.opensymphony.xwork2.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:194)
>>> at
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:163)
>>> at
>>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:137)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:21)
>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:118)
>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
>>> at ognl.SimpleNode.getValue(SimpleNode.java:258)
>>> at ognl.ASTChain.setValueBody(ASTChain.java:222)
>>> at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
>>> at ognl.SimpleNode.setValue(SimpleNode.java:301)
>>> at ognl.Ognl.setValue(Ognl.java:737)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
>>> at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:185)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:172)
>>> at
>>> com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:150)
>>> at
>>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:309)
>>> at
>>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:227)
>>> at
>>> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
>>> at
>>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:244)
>>> at
>>> org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
>>> at
>>> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564)
>>> at
>>> org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
>>> at
>>> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>>
>>>
>>> Any Ideas ?
>>
>> Nope :( I was digging around but I don't see anything special. Can you
>> prepare a demo app or post more data?
>
> Just note that the exception is logged in InstantiatingNullHandler
> when it tries to create an object which is null and on which you want
> set a value
I'm using a params, prepare, params interceptor stack.
The member "myService" (from the example above) is null
and the parameter interceptor tries to initialize it.
Trying to instantiate the Interface.
Is it possible to set ReflectionContextState#CREATE_NULL_OBJECTS to
false via struts config ? This would help.
But I'm also trying to prepare a small example, since this might be an
update issue from 2.3.16.3 to 2.3.18
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-06 18:00 GMT+01:00 Lukasz Lenart <lu...@apache.org>:
> 2014-11-06 17:02 GMT+01:00 Volker Krebs <vo...@abas.de>:
>> I still have an odd behavior and can't figure out what has changed from
>> 2.3.16.3 to 2.3.18
>> We have an Action with an service interface as class member.
>> Something like this pseudo Action:
>>
>> public class EditAction extends ActionSupport implements Preparable {
>>
>> protected MyService myService;
>>
>> public void prepare() throws Exception {
>> myService = new MyServiceImpl();
>> }
>>
>> public String execute() throws Exception {
>> myService.doSomething();
>> }
>> }
>>
>> In 2.3.16.3 this works fine.
>> In 2.3.18 I get the following exception.
>> As you can see from the stack trace we're using spring integration plugin.
>>
>>
>> 2014-11-06 03:14:05,040 ERROR [http-bio-60123-exec-5]
>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could not
>> create and/or set value back on to object
>> org.springframework.beans.factory.BeanCreationException: Error creating bean
>> with name 'com.mycompany.interfaces.MyService': Could not resolve matching
>> constructor
>> at
>> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:238)
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowire(AbstractAutowireCapableBeanFactory.java:308)
>> at
>> com.opensymphony.xwork2.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:194)
>> at
>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:163)
>> at
>> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:137)
>> at
>> com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:21)
>> at ognl.ASTProperty.getValueBody(ASTProperty.java:118)
>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
>> at ognl.SimpleNode.getValue(SimpleNode.java:258)
>> at ognl.ASTChain.setValueBody(ASTChain.java:222)
>> at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
>> at ognl.SimpleNode.setValue(SimpleNode.java:301)
>> at ognl.Ognl.setValue(Ognl.java:737)
>> at
>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
>> at
>> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
>> at
>> com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
>> at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:185)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:172)
>> at
>> com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:150)
>> at
>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:309)
>> at
>> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:227)
>> at
>> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
>> at
>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:244)
>> at
>> org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
>> at
>> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564)
>> at
>> org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
>> at
>> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>>
>> Any Ideas ?
>
> Nope :( I was digging around but I don't see anything special. Can you
> prepare a demo app or post more data?
Just note that the exception is logged in InstantiatingNullHandler
when it tries to create an object which is null and on which you want
set a value
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2.3.18 ready for test
Posted by Lukasz Lenart <lu...@apache.org>.
2014-11-06 17:02 GMT+01:00 Volker Krebs <vo...@abas.de>:
> I still have an odd behavior and can't figure out what has changed from
> 2.3.16.3 to 2.3.18
> We have an Action with an service interface as class member.
> Something like this pseudo Action:
>
> public class EditAction extends ActionSupport implements Preparable {
>
> protected MyService myService;
>
> public void prepare() throws Exception {
> myService = new MyServiceImpl();
> }
>
> public String execute() throws Exception {
> myService.doSomething();
> }
> }
>
> In 2.3.16.3 this works fine.
> In 2.3.18 I get the following exception.
> As you can see from the stack trace we're using spring integration plugin.
>
>
> 2014-11-06 03:14:05,040 ERROR [http-bio-60123-exec-5]
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could not
> create and/or set value back on to object
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'com.mycompany.interfaces.MyService': Could not resolve matching
> constructor
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:238)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowire(AbstractAutowireCapableBeanFactory.java:308)
> at
> com.opensymphony.xwork2.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:194)
> at
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:163)
> at
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:137)
> at
> com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:21)
> at ognl.ASTProperty.getValueBody(ASTProperty.java:118)
> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
> at ognl.SimpleNode.getValue(SimpleNode.java:258)
> at ognl.ASTChain.setValueBody(ASTChain.java:222)
> at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
> at ognl.SimpleNode.setValue(SimpleNode.java:301)
> at ognl.Ognl.setValue(Ognl.java:737)
> at
> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
> at
> com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
> at
> com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
> at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:185)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:172)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:150)
> at
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:309)
> at
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:227)
> at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:244)
> at
> org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
> at
> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564)
> at
> org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
> at
> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
>
> Any Ideas ?
Nope :( I was digging around but I don't see anything special. Can you
prepare a demo app or post more data?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org