I’m developing a new Web frontend that uses ICEfaces, Spring and Acegi. I already had a prototype that used Spring for implementing backing beans for ICEfaces. Business as usual, after month of try-and-error 
.
Today, I tried to add Acegi to it for authentication and authorization of the Web access. I re-used my code based on Martin’s ideas and added it to the existing ICEfaces/Spring code. The backing beans all used session scope.
I got a
No thread-bound request found: Are you referring to request attributes outside of an actual web request?
exception. The application server tried to initialize the Acegi stuff, found a reference to a session-scoped bean in one of the Acegi beans and couldn’t find a session. Quite interesting, because Spring standalone with session-based backing beans worked. After some googling there was no real answer to the problem.
So, what’s going on here? I have adapted implementations for securing URL paths (PathBasedFilterInvocationDefinitionMap) and methods (MethodDefinitionMap) via a Commons-Configuration-based implementation. The corresponding configuration bean is injected into the Acegi contexts and has a session scope incl. AOP proxy. During the Acegi initialization the configuration bean is instantiated but can’t be bound to the session context.
At the moment it seems to be a question of initialization order. Acegi, by definition, has to get the control as soon as possible. But, at that time ICEfaces has no or maybe delivers no session for it.
So, if you use Acegi 1.0.5 on Spring 2.0.6 with ICEfaces 1.6.1 all Acegi beans (interceptor and friends) and its helpers (e.g. configurators) can’t have a session-scope.
