Hi Val,
The mechanism is similar to the implementation of invalidate() of the
WebSessionV2 class. The {@link #invalidate()} action is delegated to the
genuine session. Similarly, actions setAttribute(), removeAttribute(), and
setMaxInactiveInterval() should be delegated to the genuine session. This
way, the web container can do to the session whatever it promises to do,
such as calling the HttpSessionBindingListener's valueUnbound callback
function, etc.
If you look at the HttpSession interface, this is the whole list of APIs
concerned:
* setAttribute()
* removeAttribute()
* setMaxInactiveInterval()
* invalidate()
* putValue()
And putValue() has been covered by setAttribute() in WebSessionV2
There are two main reasons that WebSessionV2 should delegate to the genuine
session:
1. Avoid re-inventing the wheel. The web container has already implemented
the related APIs.
2. WebSessionV2 is not visible to the web container. When the web container
decides to expire the session, it will not reach the WebSessionV2
implementation. And this is exactly where I had the problem in the first
place.
By the way, thanks for pointing out removing attributes, I've made another
pull request on GitHub:
https://github.com/apache/ignite/pull/2243
Also I can't assign the ticket to myself because of lack of permission:
https://issues.apache.org/jira/browse/IGNITE-5607
--
View this message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/It-seems-WebSession-s-removeAttribute-does-not-support-HttpSessionBindingListener-tp19184p19575.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
