On 06/05/13 21:53, Les Hazlewood wrote: > Hi John, > > The easiest way around this is to ensure that the same classes exist > in both applications. Since that doesn't seem too practical, I think > your current approach is a good one. > > However, another technique that I think could work (although laborious > and not something I've tried myself), would be to write a custom > SessionDAO implementation that stores attributes separately from the > core Session properties (last access timestamp, etc). Then you could, > when deserializing the data, pull the core session data + shared > session attributes + app specific session attributes and make them > available to Shiro. Almost as if the Session that Shiro sees would be > a subset 'view' of the overall data. > > In Redis or other cache mechanisms, I suspect you could use 3 entries > to store data: > > Entry 1 (sessions): key: sessionId, value: Shiro's native session > properties (lastAccessTimestamp, etc). > Entry 2 (shared session attributes): key: sessionId + > "_shared_session_attributes", value: map of shared session attributes > Entry 3 (app-specific session attributes): key: sessionId + "_" + > applicationId + "_session_attributes", value: map of app-specific > session attributes > > Then on deserialization, you can pull the three entries and combine > them into a single Session object instance handed back to Shiro. > > You'd also might need a custom Session implementation (and > SessionFactory to instantiate it) that knows how to, when setting > session attributes, route which of the two maps (shared vs > app-specific) the attribute should be stored. > > Anyway, these are just ideas, and I haven't tried them myself, but it > might lead to other ideas. > >
Thanks, Les. I think I'll just stick with the JSON technique for now - you have confirmed that it is an unavoidable session problem, which is what I was really trying to find out. John
