RSF Discussions Forum

RSACBridgeProxy is the bean which allows Application Context (AC) beans to have dependencies upon Request Scope Application Context (RSAC) beans - it uses CGLIB at runtime (request time) to proxy method calls.

Without RSACBridgeProxy, RSAC beans would require that beans that depended upon them to also be RSAC beans, otherwise there would be no way to express that dependency neatly using Spring/RSAC.

With RSACBridgeProxy, a typical RSAC has become rather 'thin', consisting only of beans in isolation that are wired to beans in the underlying AC. Are there actually that many genuine RSAC beans that depend upon each other?

After 0.6 when the RSACBridgeProxy was introduced, it suddenly looked like the request container could indeed be (almost) completely flattened, and that there wasn't a very great value to RSAC after all. In 0.6.1 through 0.6.2 beans will be being moved back into application scope again (for example ActionResultInterpreters) which will speed request handling somewhat.

However, in the process of doing this some beans *are* coming to light that really do benefit from a request-scope lifecycle - for example, AutoBaseURLProvider is a bean which is quite awkward to implement at application scope, since it has a dependency on HttpServletRequest which of course is in the request scope and on which any computations it did would need to be redone.

This isn't a massively great example since the computation in this case is only some URL parsing, but I think this generally points the tendency that request-scope beans tend to cluster around the HttpServletRequest, which is a massive "bullet" full of request-scope dependencies. The further away you get (assuming you have a reasonable architecture), the more these dependencies have been abstracted behind reasonable interfaces.

A tricky issue going forwards is the ViewParameters. This is actually due for refactoring in any case (to move the variable part into a framework-dependence-free bean), but the essential problem is that this is *polymorphic* (since it is in general of a different class for each view/request). This makes it somewhat hard to proxy since RSACBridgeProxy couldn't statically know what type of proxy to make. So until we have ViewParameters reform and hide this variable object itself behind an interface in ViewParameters, moving beans back into application scope will be halted wherever there is a ViewParameters.

The bottom line -
i) RSAC beans are probably still quite useful, but not so massively as we first thought,
ii) They will tend to congregate around the "incoming" request-scope dependency (HttpServletRequest for Servlets, PortletRequest for portlets) where there is the greatest "badness" in terms of kitchen-sink type request-scope variability
iii) The most valuable bit of request-scope dependency mapping will probably be where it was at the start, in the incoming EL interpretation layer, which ironically doesn't really use RSAC since it has to do all the hard work of topologically sorting the EL dependencies by itself since they arrive at random.