isnt this also a regular limitation of clustering? if you have a complex object in httpsession and change one of its properties it wont necessarily get replicated unless you set the actual httpsession attribute again. some clustering libs only replicate dirty properties, not entire sessions. so i dont necessarily think calling dirty() once an attr changes is that big a deal, especially given you will not have that many of those, with wicket there isnt much reason to keep things in session yourself.
-igor On Fri, May 2, 2008 at 8:45 AM, James Carman <[EMAIL PROTECTED]> wrote: > When I was reading the discussion about session.dirty > > (http://www.nabble.com/What-is-session.dirty%28%29-for--td17021032.html#a17021032) > on the users list, I came up with an idea. Perhaps we could come up > with a set of reusable AspectJ aspects for these sort of cases. For > this particular case, we'd introduce an annotation like @SessionData > or something and create an aspect that says "anytime a setter is > called on a class with the @SessionData annotation, we call > session.dirty()". Now, this would be a separate subproject of Wicket > so that it's not required or anything. Then, if folks wanted to, they > could weave that into their own classes to make sure that they're > taking care of their session data properly (in a cluster). I can > imagine that we might be able to do the on-before-first-render stuff > with aspects, too. Again, the aspects would be optional, kind of like > how the spring-aspects (for @Configurable and @Transactional) are > optional, but very useful. >
