Springcache causes request variables from outside the controller to disappear when using @Cacheable on action

Request scope variables will need to be cached alongside the response

Here's some more details of one case:
I have a filter (a grails filter, not a servlet filter), which sets request.x="something"
From within the action-view's GSP, the part that will be cached, request.x == "something" as expected
But from with the layout GSP, or anything else the layout calls, request.x == null.

Is your comment relevant to that scenario?
I was thinking the problem is that springcache is inserting itself into a place that is causing it to bypass my filter for the layout and everything other than the view that will be cached.

My other case with taglibs is different because request vars are being altered in both cached and non-cached parts. I was starting to think it wasn't possible with springcache, but your comment has me wondering. We are using UI-Performance plugin and we set p.dependantJavascript in the layout, templates that it uses, and in the action's view (which will be cached), then there's p:renderDependantJavascript back the bottom of the layout. Basically, request.y is appended in several places and then rendered. Currently, with @Cacheable, it's missing chunks of JavaScript put in from the actions's view GSP. Is there hope of solution for a scenario like this?

It's definitely possible for Springcache to cache request scope variables. If you're using a Grails filter it should definitely be 'inside' the Springcache filter as Grais filters are implemented as Spring iterceptors rather than servlet filters whereas Springcache does use a servlet filter.

Sorry, I should clarify, when I say "possible" I mean that I will be able to implement it, not that it does it now.

I attached a simple example to reproduce some of this
This adds a filter and taglib to the example I added to [GRAILSPLUGINS-2769] to demonstrate the behavior of request variables with springcache.

If you go to the person/list
You'll see request.testProp (which I populated in a filter) printed from both the layout and view.
Both have "testValue" on the first request, then after reloading the page, the value of testProp is null in the layout.
And at the bottom of the page you'll see something printed from a collection (request.stuff) which should have a member added from the layout and the view.
It looks OK on the first request, but then after reloading the request.stuff is missing the members ("Part 2 Added From View") added from within the view.

I have fixed this by ensuring all request attributes that are added to the request during page rendering and whose values implement Serializable are cached and then added to the request when a cached response is served. This fixes integration with the Resources plugin and should fix most other issues. Please install version 1.3.2-SNAPSHOT of the plugin and give it a try.