Hi all,
I am currently using shiro and the tapestry-security plugin to manage
sessions and persist data. Everything works fine when getting the session by
SecurityUtils.getSubject().getSession(). However, this means that the
application is peppered with fragments of shiro-specific code. Since shir
really should be able to continue using @Persist and @SessionState.
> Both Shiro's subject.getSession() and the @Persist annotation store their
> values in the same http session. Is that not working for you ?
>
> Cheers,
>
> Alex K
>
> On Wed, Aug 8, 2012 at 7:20 A
objects. You are already using the exact same session
> management objects.
>
> On Aug 8, 2012, at 10:04 AM, kata wrote:
>
>> Alex,
>>
>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
>> the
>> session manager to
> Shiro, on the other hand, does, if you enable it. You shouldn't do that
> in a web/tapestry environment.
>
> On Aug 8, 2012, at 10:30 AM, kata wrote:
>
>> Then there must be some crucial bit of configuration I'm missing. Every
>> time
>> I visit a pag
tes/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
>
>
>Sorry I don't have more specific answers. I hope this helps.
>
> Cheers,
>
> Alex K
>
> On Wed, Aug 8, 2012 at 10:04 AM, kata <januszkiewicz.marcin@>wrote
t;wrote:
>>
>>> I wouldn't use native shiro sessions with Tapestry. This is a recipe
>>> for
>>> disaster.
>>>
>>> On Aug 8, 2012, at 10:59 AM, kata wrote:
>>>
>>>> Alex,
>>>>
>>>> thanks, I
Hi, all
As a follow-up: I decorated the TapestrySessionFactory to return a shiro
session instead of the wrapped HttpServletSession. The interfaces were not
identical, so a (very) simple coercion function was needed. I got exactly
what I needed: the only shiro-related code consists of a few lines i
