Extending io.undertow.servlet.spec.HttpSessionImpl
by Kákonyi István
Hi Team!
I am involved in a github project that try to implement a SIP Application Server under wildfy 8 (check https://github.com/Mobicents/sip-servlets/issues/3 for more detail).
According to SIP Servlet spec we have to implement a ConvergedHttpSession class that provides access to HttpSession related functionality which is only present in a converged HTTP/SIP container. In a converged container, an instance of HttpSession can be cast to ConvergedHttpSession in order to access methods available only to converged applications.
Wildfly 8 uses undertow-servlet project for session handling and I noticed that currently it is not possible to extend io.undertow.servlet.spec.HttpSessionImpl (it has only a private constructor method and a static method for instantiation), so we are stuck in the implementation a little bit because of that limitation.
Do you have any suggestion how to resolve this problem? Is there a chance to change HttpSessionImpl's constructor to "protected" in order to be able to extend it?
Best Regards,
Istvan
9 years, 2 months
Possible session lookup bug when no session cookie present
by Toby Crawley
With this commit[1], calls to Sessions.getOrCreateSession() from
within a handler where no session cookie was sent with the request
result in a new Session being created every time, with the last
Session created actually being the one stored when the exchange is
completed.
This means that the following in a handler results in "foo" not being
in the session on the next request:
Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar");
Sessions.getOrCreateSession(exchange);
Before [1], the second getOrCreateSession() call would return the same
Session object as the first call, not overwriting the one already
attached to the request, and "foo" would be preserved.
I'm not sure if you consider this a bug or not, but wanted to point it
out just in case. We discovered this in an Immutant test when
upgrading from undertow 1.1.0, and we were able to work around it with
a small change to that test. I don't believe this will affect any
Immutant users, since we handle all Session access for them, and call
getOrCreateSession() only once during regular operation.
Let me know if you do consider this a bug, and I'll file a JIRA.
- Toby
[1]: https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a...
9 years, 2 months
