>> An application may have different HTTP configurations with different session fixation protection strategies. I would accept an argument that SessionFixationProtectionEvent should be abstract.

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.

>> Partially same as above (developer should know what action was taken, application may have different HTTP configurations with different strategies). If only Spring attributes were migrated instead of all attributes (or vice versa), developer may need to add (or remove) certain session attributes, so he would need to have this information.

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?

>> I'm open to suggestions for a better name overall, but I couldn't come up with one that I thought made it clear exactly what it meant.

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