On 16/02/18 03:49, Konstantin Kolinko wrote: > 2018-02-16 0:35 GMT+03:00 Mark Thomas <ma...@apache.org>: >> 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. >> > > I disagree. > > Javadoc (Servlet 4.0): > https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpSessionAttributeListener.html > https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpSessionBindingListener.html > > 1) HttpSessionAttributeListener is "@since Servlet 2.3", > HttpSessionBindingListener does not have "@since" clause. > Thus it looks that the attribute listener is a newer and improved API. > > 2) The "binding" listener is not a listener (it is not in the list of > listeners, it cannot be declared in web.xml). It is an interface > implemented by the value itself. > > 3) I think that once value.valueUnbound() is called, the expectation > is that the value is never going to be used again and can be > destroyed. I think it is not safe to call valueBound() on it. > > Thus the reason for (value != oldValue) check (line 1426 in trunk). > > > 4) A HttpSessionAttributeListener has three methods as opposed to two > in binding listener. > > Its attributeReplaced() method can be coded to handle the (value == > oldValue) case.
Thanks for disagreeing. Having someone put the opposing case helps clarify my own thoughts. Keep in mind that I am trying to address BZ 43866 at the same time. What bugs me about this is the inconsistency. The language for HttpSessionBindingListener, valueUnbound() and the phrase "unbound" is pretty much identical with the language for HttpSessionAttributeListener, attributeReplaced() and "replaced". Both valueUnbound() and attributeReplaced() have enough information to handle the value = oldValue case. What I really don't see is the justification (apart from history) for handling them differently. I think this is another instance of something to get clarified by the Servlet EG (or whatever it ends up being called) once the process moves to Eclipse. Meanwhile, I'd like to suggest the following. Two new Manager options to individually control the calling of these listeners when the value and the old value are the same. Something like: notifyBindingListenerOnUnchangedValue (defaults to false) notifyAttributeListenerOnUnchangedValue (defaults to true) This would leave the current behaviour unchanged, make it easy to change the default of the 'Servlet EG' clarifies the expected behaviour and provide a work-around for the problem described in BZ 43866. Thoughts? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
