> > I'd like to suggest that @SessionState be deprecated in favor of > @SessionAttribute in the future. > > Thoughts?
This is ultimately a _documentation_ error. (If we ignore the problem with generics for the moment.) That is, the real problem is that the docs for @SessionState/@SessionAttribute really need to discuss the tradeoffs, and the documentation for @SessionState should say in big giant bold letters "DO NOT USE THIS FOR SIMPLE VARIABLES. BUILD A CUSTOM CLASS OR USE @SessionAttribute." Similarly, the documentation for @SessionAttribute should say: "DO NOT USE A SIMPLE NAME. Qualify the name with some sort of package, i.e. instead of 'user' use: com.yourcompany.User" Sample paragraphs to be inserted: For both of these annotations, you are essentially creating global data that will have to be serialized/deserialized/distributed and so on, because its stored in the servlet session. As with all global data, there is the possibility of collisions, not just with your app but with other Frameworks. For that reason, DO NOT USE @SessionState FOR SIMPLE VARIABLES. It is worth taking the time to build a class to hold this information, because it will force you to consolidate that information into a single, logical unit. Over time, you'll be glad you did. That's why @SessionState is the older, and more traditional way to do this, because it forces you to build such an object. That said, there are times when you just want to store a single string, etc. In this instance, you can use @SessionAttribute. But you should qualify the name with some sort of package, again so you don't have collisions. That is, don't use 'username', use 'com.mycompany.username'. DO NOT USE A SIMPLE NAME. When deciding between the two, it's best to use SessionState for complex objects, and SessionAttribute for simple types. If you use SessionState for complex objects, you will be immune to any typos in the variable name because the compiler will check for you. For SessionAttribute, its best to define a constant, and use that rather then defaulting to the instance variable name, because otherwise, you could have a subtle runtime error due to a typo. Pierce Pierce
smime.p7s
Description: S/MIME cryptographic signature
