Hi, I've been looking at: https://bz.apache.org/bugzilla/show_bug.cgi?id=43866
In short, this bug is looking for a way to tell Tomcat an object set as a session attribute has been mutated and therefore needs to be replicated. The 'standard' way to do this is by calling setAttribute() but this triggers listeners. While thinking about ways to implement an option for this, I stumbled across the following. When setAttribute() is called with an object that is already in the session then StandardSession.setAttribute() calls listeners inconsistently. Any HttpSessionBindingListener will not be called because the old and new values are the same (see line 1426 in trunk). Any HttpSessionAttributeListener will be called since the old and new values are not compared (see line 1466 in trunk). I can find no reason in the spec for this difference. I think these should be consistent. In the case where setAttribute() is called with the same value as is already bound either both types of listener should be called or neither. The question is what to do about it. I think we need an option on the Manager to control this. For now, call it notifyListenersOnUnchangedValue (suggestions for better names welcome). Clearly there need to be two options, "true" and "false". Does there need to be a third "legacy" (again suggestions for better names please) that essentially retains the current inconsistent behaviour. Or do we have two options. One for HttpSessionBindingListener and one for HttpSessionAttributeListener? Thoughts? Comments? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
