hi all,
i am setting cookie form action and i am getting exception :
org.apache.catalina.connector.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the request
processing
java.lang.ArrayIndexOutOfBoundsException
org.apache.coyote.http11.AbstractHttp11Processor
I don't see any connections with Struts 2 code, could you provide more
details and the whole stack trace ?
Regards
--
Lukasz
2011/11/28 Debraj Mallick sridebrajmall...@gmail.com:
hi all,
i am setting cookie form action and i am getting exception :
*my action : *
public class SetCookieAction extends ActionSupport implements
ServletRequestAware, ServletResponseAware {
private ListIngredientBean ingredientBeanList;
protected HttpServletResponse servletResponse;
@Override
public void setServletResponse(HttpServletResponse
It seems that your cookie is bigger than the maximum admitted(which is 4k).
2011/11/28 Debraj Mallick sridebrajmall...@gmail.com
*my action : *
public class SetCookieAction extends ActionSupport implements
ServletRequestAware, ServletResponseAware {
private ListIngredientBean
Thanks for the tip, Łukasz.
I have tried this option, not without a few workarounds: I had to add a
param to struts.xml so validation files are loaded during runtime:
constant name=struts.configuration.xml.reload value=true/
I have arrived to a leve in which I can call, from my Action:
You should consider to use the session scope for this kind of use case
(though it could cause memory leak exception).
Aside from this is not a Struts issue
Sent from my mobile device, so please excuse typos and brevity.
Maurizio Cucchiara
Il giorno 28/nov/2011 14.25, JOSE L MARTINEZ-AVIAL
Tracked here https://issues.apache.org/jira/browse/WW-3713
--
View this message in context:
http://struts.1045723.n5.nabble.com/struts-rest-plugin-2-2-3-result-from-POST-tp4469274p5029137.html
Sent from the Struts - User mailing list archive at Nabble.com.
Hi,
Please explain the meaning of the following :
param name=excludeMethodsinput,back,cancel,browse/param
Tipically these are the method names ignored by an interceptor.
Sent from my mobile device, so please excuse typos and brevity.
Maurizio Cucchiara
Il giorno 28/nov/2011 19.34, Srineel Mazumdar smaz19...@gmail.com ha
scritto:
Hi,
Please explain the meaning of the following :
param
2011/11/28 Josep García jgar...@isigma.es:
I have tried this option, not without a few workarounds: I had to add a
param to struts.xml so validation files are loaded during runtime:
constant name=struts.configuration.xml.reload value=true/
Hmmm that's bad, each time the configs will be
Looks like you want some pre-condition check before the validation.
If and only if the pre-condition is true, the validation will be executed.
I did the same thing several years ago.
There are 2 solution I tried:
(A)Inherit all the struts2 bundled validators, add some pre-condition
check code,
If the goal is to execute validations based on arbitrary preconditions (I
missed the original req) the *easiest* thing to do might be to just
extend/usurp the existing validation interceptor to do that precondition
check.
d.
On Mon, Nov 28, 2011 at 7:58 PM, Li Ying liying.cn.2...@gmail.com
Changing the [validation interceptor] will switch on/off the all
validations by one pre-condition.
But what he need is:
if and only if pre-condition-A is true, run validation-A;
if and only if pre-condition-B is true, run validation-B;
etc...
So, I think the right way is, change the validators.
This doc explains it.
http://struts.apache.org/2.x/docs/interceptors.html#Interceptors-MethodFiltering
2011/11/29 Srineel Mazumdar smaz19...@gmail.com:
Hi,
Please explain the meaning of the following :
param name=excludeMethodsinput,back,cancel,browse/param
If the need is across the application, then modifying the app-wide
interceptor makes sense.
App-wide rule-based validations require something higher-level than
reworking existing validators, or writing new ones, to express something
that is likely declarative in nature. Seems more like run this
Yes, of course you are right.
But what you talking about sounds like to change S2 mechanism itself,
which we can not do.
As a S2 user but not a S2 developer, the simplest way is to write a
new validator..
Of course, If the [pre-condition based validation] is a common
request, I think it will
The point of having extensible, open-ended interceptor and configuration
mechanisms is precisely so we *can* extend it to meet application needs,
without having to modify the framework itself.
The framework provides the hooks, through interceptors and plugins,
precisely for circumstances
17 matches
Mail list logo
