> It seems more appropriate to have logging determine the difference between the two events. What is a concrete example of where a developer would need to process the two different events differently within the same deployment? It seems that these events are including information that is static for a deployment which does seem like it belongs in an Event which is fired so frequently ... Again this seems like it would be better handled through logging. When and why would an application support both options at the same time? Why would developers need to handle the situations differently within the same deployment? Why would they be interested in the boolean configuration (migrate session attributes) which is a constant for a deployment?

Why can you have more than one `<http>` section in the namespace configuration? (http://static.springsource.org/spring-security/site/docs/3.0.x/reference/ns-config.html) I don't think I have a good enough concrete example for you. In every case I've ever used Spring Security, I only had one `<http>` configuration. But the original creators, whoever they were, allowed there to be multiple `<http>` configurations in one deployment for a reason, and it's a matter of fact that different `<http>` configurations could technically have different rules regarding session fixation protection. Without separate events / `sessionAttributesWereMigrated`, they developer has no way of determining how the session was changed/migrated. "Logging," if I understand you correctly, would be great for writing to some file what happened, but it does nothing for helping the developer decide how to react to the event.

Here's the best concrete example I can think of: I create an application that has both an external and internal portal. I want them to be the same deployment because they share the same database, resources, repositories, services, etc., but they interact with the public differently than with employees. Therefore, there are two login screens, two user databases and two sets of permissions. Instead of using permissions to differentiate these users, I want two completely different security contexts, because I want different rules on login retry, remember-me, SSL, session concurrency, etc. This is a perfectly plausible, possible need, and using multiple `<http>` configurations is a valid and legal way to solve this problem. Since multiple `<http>` configurations CAN have different session fixation protection strategies, I believe it is apparent that the eventuality must be planned for. Someday somebody will try it. If I've already written the code to account for it, what does it matter? It would take MORE work to UNDO it.

> Spring is built on Java Beans and so we should use Java Bean conventions (certain things do not work if you do not follow the conventions). Therefore, if it is to stay in the code (i.e. depending on what we decide above it may not be necessary) we need to find a way to make this a valid Java Bean

My suggestions are `getSessionAttributesWereMigrated()` and `getWhetherSessionAttributesWereMigrated()`. Which do you like better? I'm not a big fan of either, but I could live with them. I'd love to hear better suggestion that sounds a little more "natural."