Done https://issues.apache.org/jira/browse/WW-4037
2013/4/3 JOSE L MARTINEZ-AVIAL <jlm...@gmail.com> > 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 >> > > >> > > >> >> > >
