isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Isis session and transaction management on a custom viewer
Date Thu, 05 Sep 2013 13:52:18 GMT
Hi Oscar,
apols for the delay in replying on this; within...

And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.


On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <>wrote:

> [snip]
> ... we have some questions about current design:
> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
> viewer needs to hold the state,

The Apache Wicket framework is stateful, that's just the way it is.  In
fact, it's one of the principles of the framework to handle this [2].  One
needs to be aware of this [3].

> from an Apache Isis perspective? Just to hold the current user "context
> information"?

No, more than this.  Every component (widget) in the page is backed by a
Wicket model (LoadableDetachableModel); these must be serializable because
they are stored in the session.  Isis entities are not serializable (nor
would we want them to be), but the OIDs are (eg "TODO|123").   Isis handles
this by providing mementos (for entity, property, collection, action,
parameter).  Thus, EntityModel is a Wicket model that wraps an

But, yes, Isis itself does also have a session which represents the current
user.  This is its
org.apache.isis.core.commons.authentication.AuthenticationSession.  Isis
delegates to Wicket to store this for it in the HttpSession; this is done
through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
(IsisWicketApplication#getWebSessionClass).  By this, Wicket keeps track of
the user making the request.

If using Isis' Shiro integration for authenticaiotn/authorizatino, then
there are also Shiros session management to consider [4].  I am pretty sure
the default for that is also HttpSession, but it would seem to be pluggable
and they say it supports clusters [5].

> Why to choose for other webapps integrating with Isis the stateful design,
> instead of the - more scalable - stateless design?
Umm.  As [3] says, Wicket's reliance on session management means it
wouldn't be suitable for an Amazon scale website.  But I believe it's an
appropriate technology for a typical enterprise app (that might use a farm
of clustered servers for big deployments).

Restful Objects in contrast is deliberately stateful.  There is still the
user identity issue to contend with, but that's pluggable.  I hope that
someone (who knows more about this than me) might help work through an
oauth or equivalent implementation.  My understanding (I'm by no means a
security expert on this) is that these solutions are scalable because the
user credentials ultimately are stored in HTTP headers (encrypted suitably,
of course, according to the oauth protocols etc etc).

> 2.- Is there any class we can inherit from for stateless or stateful
> clients, that will be maintained in the future, as Apache Isis evolve, that
> takes care of web session handling, security (shiro) session, transaction
> management, etc. ? Perhaps we can inherit from classes currently existing
> on the Wicket viewer (or the Restful Objects viewer).

Look at the classes above as a start point, see if you can untangle them.

There is a ticket to better integrate Shiro and Wicket [6].  Right now we
logout of the Wicket viewer by invalidating Wicket's authentication
session.  However, Shiro doesn't know about this, so it preserves its
sessions.  We do (seemingly) still get the behaviour we want, but
improvements could be made here.

> 3.- Is there any other point we must take into account with this approach
> - the "custom viewer" interacting with the Apache Isis domain - ?
The biggest immediate risk is that you get the scoping wrong.  There is a
reasonably clear separation of scopes; see ApplicationScopedComponent,
SessionScopedComponent, TransactionalScopedComponent.  There's an old
diagram I did [7] which shows this (it might be a bit out of date, but
shows the general pattern).

The biggest ongoing risk is that - because the API is not formally
documented - that we change the code and break the custom viewer.

While I can see the value of there being a formal "in-process" API, I do
hope that most will use the RO viewer.  I guess one could use the RO applib
and RO viewer on the same box as a loopback; not sure if that would add to
much overhead to be feasible.


> Thanks,
> Oscar
> [1]


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message