You are right. Only thing is that due to time constraints I can only provide the code and some explanations. The code is production ready for me, but I know for a fact it needs to be modified in order to make it more struts-like (basically avoiding any dependence of javax.servlet). I will create the ticket and upload the code.
Thanks JL 2013/4/3 Martin Gainty <mgai...@hotmail.com> > > if you are convinced this Intercetpr and Interface doesnt exist in the > codebase.. i am certain the struts devs would like to have these 2 classes > incorporated into the codebase > > why not file JIRA ? > https://issues.apache.org/jira/browse/WW > > > Saludos Cordiales desde EEUU > Martin > ______________________________________________ > Porfavor..no altere ni interrumpir esta communicacion...Gracias > > > > > > Date: Wed, 3 Apr 2013 16:30:19 -0400 > > Subject: Re: Cookie Interceptor > > From: jlm...@gmail.com > > To: dev@struts.apache.org > > > > I use CookieAware in Struts 2.2.3, and I don't have any issues for not > > having the setters. But I do have a bunch of issues with cookies with > name > > MENU-STATUS, since the interceptor tries to parse the cookie name as an > > OGNL value (ACCEPTED_PATTERN was added later than 2.2.3). My proposal > would > > be to simplify the interceptor in two ways: > > 1) Remove the filter by cookie value: I don't know under which > > circumstances that could be useful > > 2) Parse the cookieName as a OGNL expression, so I can setup the cookie > > names I want to receive dynamically, instead of harcoding them in the > > configuration files. > > > > Also related, there is no way in Struts to setup a Cookie. I developed my > > own CookieProviderInterceptor and CookieProvider (interfaces) to allow an > > Action to create a cookie and pass it to the CookieProviderInterceptor to > > ser it in the request, but I would love to see a more integrated process. > > > > Cheers > > > > Jose Luis > > > > > > 2013/4/3 Christian Grobmeier <grobme...@gmail.com> > > > > > Hi, > > > > > > the CookieInterceptor currently looks for all available cookies. Lets > say > > > there > > > are cookies x, y, z. Now it would call setX, setY, setZ on the action. > > > In addition it creates a cookie-map which is then injected to the > action. > > > > > > The cookie interceptor does not make sense at a general level so far. > > > You need to have x, y, z in your actions, and so all your actions would > > > need to provide these setters. Also "*" is risky: if you set a cookie > for > > > use in > > > Action A it might fail if you have not an appropriate cookie-based > Action > > > B. > > > > > > Actually I have tried to implement CookieAware and expected it would > > > populate a map only from which I can take care of the cookies myself. > > > This doesn't work, because an error is thrown when the get/set methods > > > are missing. > > > > > > To overcome this I created a CookieMapInterceptor which does not > populate > > > the action but only a Map. For that I have overridden the > > > CookieInterceptor. It was a bit of pain because a few necessary > > > members are private and not protected. > > > > > > That said, I would like to implement one of the following solutions: > > > > > > Option 1) override CookieInterceptor with CookieMapInterceptor and > > > make ACCEPTED_PATTERN, acceptedPattern, cookiesNameSet protected > > > > > > Option 2) add another option to the CookieInterceptor, which is called > > > "skipActionPopulation" (defaults to false). If true, only the map > > > would be created without putting the Cookies on the Action > > > > > > In any way I would love to make ACCEPTED_PATTERN, acceptedPattern, > > > cookiesNameSet protected. > > > > > > Any preferences/objections? > > > > > > Cheers > > > Christian > > > > > > > > > > > > -- > > > http://www.grobmeier.de > > > https://www.timeandbill.de > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > >
