SWF / MVC write-up

[Cantor, Scott]

On 9/4/13 10:59 AM, "Marvin S. Addison" <marvin.addison at gmail.com> wrote:
>
>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.

The resolvers that appear to be provided are uniformly designed not to
test for the presence of the template they're resolving, so I don't think
this works, but I can test/investigate further. I didn't try to actually
predefine the views though, perhaps that will allow them to chain.

I would note that the documentation even notes you can't put the JSP
resolver first, because it auto-resolves by design as a last guess. So the
question is whether the Velocity one does too.

But this is a big deal, so I definitely will look into it more.

>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.

Nevertheless we have to, or change a pretty fundamental decision.

> 
>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.

We have to carry XMLObjects and other data through the context tree and
those are not Serializable. That's the least of the reasons we can't
serialize right now.

There is no intent to substitute a different serialization model.

>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.

We didn't, and we made a specific decision early on in V3 that login
conversation state would not need to be serialized. We have never
attempted to cluster that (apart from Terracotta which just replicates
object state).

I'm pretty sure the entire design of the context tree and what we would
put into it was based around that choice.

Of course, it may be that the memory overhead of SWF is such that we can't
afford not to deal with this. I run a pretty long timeout now with the IdP
and have never had an issue with memory, but we only track objects of our
own creation. But I think one difference is that if you don't allow
snapshots, the SWF state is probably smaller for each session than it
normally is.

-- Scott