One thing we've got rid of is the forwards to forms (with the new template engine the
html is returned directly by the rest endpoints). So at least the issue with the response
filter not being invoked is gone.
I wasn't a fan of the Transaction class. If we can manage to do it in filters that is
definitively my preferred option. So option 2 gets my vote!
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Wednesday, 25 September, 2013 2:31:27 PM
Subject: [keycloak-dev] Problems with Filter session management
There's a problem using servlet filters to manage KeycloakSession objects.
1) We may not be in a servlet environment. It seems that MBaaS may want
to avoid having a servlet container
It looks like it will be Vert.x + Netty. If we can run in that environment that would be
2) Not all exceptions are propagated to Servlet Filter, thus, no
automatic rollbacks. i.e. WebApplicationException and all its varients
3) You may think, "Well, we can write an ExceptionMapper to rollback",
but you'd be wrong. Stupid idiotic JAX-RS spec will not run an
ExceptionMapper for a WebApplicationException that has an entity.
There's two ways we could fix this problem:
1) Bring back the Transaction class
2) Write a JAX-RS ContainerRequestFilter that starts the session. Write
a JAX-RS ContainerResponseFilter that will check the response code to
see if it is a) successful, or b) a redirect and commit, otherwise rollback.
JBoss, a division of Red Hat
keycloak-dev mailing list