SWF / MVC write-up

[Marvin S. Addison]

> I've documented most of my findings and the results of various experiments
> with the testbed Brent created together with my authentication flows.
>
> https://wiki.shibboleth.net/confluence/display/IDP30/Spring+and+Web+Flow+Te
> chnical+Issues

Some feedback on sections of that document.

On views, I recall that multiple view resolvers were supported out of 
the box. Cursory code review suggests that by leveraging 
setViewNames(String[]) on each resolver, the canHandle() method performs 
a test whether the resolver works with a particular logical view name. 
Provided you know the logical view names up front as a matter of 
configuration, which seems a reasonable requirement, you could configure 
multiple resolvers with their supported views. Seems easy enough to test.

On serialization, all indications suggest that strictly avoiding the 
Java serialization mechanism will be a non-trivial task in the SWF 
components alone, not to mention other places serialization creeps in. 
It's not clear to me whether you want to unplug the default and plug in 
a custom implementation (i.e. StorageSerializer) or avoid serialization 
altogether. Either way it feels like a lose-lose in terms of substantial 
work for fewer features/deployment options.

Java serialization is an assumed capability for numerous technologies. 
For example we've made use of the Tomcat feature to overflow idle 
sessions to disk to avoid high memory footprints while allowing very 
long session timeouts (some of our users linger on the login form in CAS 
for quite some time). Stateful clusters would also be out. Anything with 
caching and replication will need it, so it seems to make sense to 
design for it. If there is concern about control over what and how 
objects are serialized, volatile fields and Externalizable provide all 
the rope you want. On the other hand you can still use Serializable to 
get sensible defaults.

M