Having two sessions is actually what I'm trying to avoid - I want to use
shiro native sessions exclusively. My problem is that Tapestry by default
uses the servlet API to access the underlying HttpSession, so using
annotations like @Persist cause a second session to be created. If I can
intercept Tapestry calls to the servlet API and direct them to the shiro
session, then I can have only one session, properly clustered and, above
all, it'll be completely transparent to the application.
lprimak wrote
>
> The whole point of a web session is to have only one. Now he is winding
> up with two sessions.
> One web and one shiro native.
> How is he clustering the web session if he clusters
> the shiro native session differently? Sounds like the 'web session' isn't
> working correctly in his case
> and he is trying to 'compensate' with Shiro, which is sooo wrong path to
> go.
>
> On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:
>
>> Lenny - why do you think it would be a problem ?
>>
>> Cheers - Alex K
>>
>> On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak <lprimak@.ny>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'll look into it.
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>>
>>>> Alex Kotchnev-2 wrote
>>>>>
>>>>> Martin,
>>>>> it sounds like you might need to crack open the Tapestry source, but
>>>>> it
>>>>> seems doable. Although I don't know the details, I know for sure that
>>> the
>>>>> @Persist annotation allows for different persistence strategies (e.g.
>>>>> @Persist("flash")), which can be plugged by different modules (e.g.
>>>>> JPA
>>>>> and
>>>>> Hibernate provide an "entity" strategy). So, it seems like if you look
>>> at
>>>>> how Tapestry JPA contributes the "entity" strategy, you might be able
>>>>> to
>>>>> replace or add your own (e.g. 'shiroSession'). There probably is a way
>>> to
>>>>> override the existing 'session' strategy w/ the one backed by Shiro's
>>>>> Session (e.g. anywhere where you can "contribute" as the code below
>>> does,
>>>>> you can also override).
>>>>>
>>>>> Another example is Tynamo's tapestry-jdo module, e.g. :
>>>>>
>>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html<http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/index.html>
>>> ;
>>>>>
>>> http://tynamo.org/constant/sites/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:
>>>>>
>>>>>> Alex,
>>>>>>
>>>>>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
>>> switch
>>>>>> the
>>>>>> session manager to shiro's DefaultWebSessionManager. I do it this way
>>> to
>>>>>> later cache and cluster session data with EhCache.
>>>>>> What I need is a way to substitute the HttpSession tapestry is using
>>> with
>>>>>> shiros' Session implementation. If I can do that, then I hope I can
>>>>>> use
>>>>>> the
>>>>>> servlet API in the application instead of the shiro-specific calls.
>>>>>> Ideally
>>>>>> annotations would also work as intended, with clustering and all.
>>>>>>
>>>>>> Regards,
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> Alex Kotchnev-2 wrote
>>>>>>>
>>>>>>> Martin,
>>>>>>> you 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 AM, kata <januszkiewicz.marcin@>
>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>> shiro
>>>>>>>> uses the servlet session API, is there a way to do this in a way
>>>>>>>> that
>>>>>> is
>>>>>>>> transparent to the application, and hopefully still allow me to use
>>>>>>>> annotations like @Persist and @SessionState?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>>>>>>> For additional commands, e-mail: users-help@.apache
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>>>>> For additional commands, e-mail: users-help@.apache
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715160.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>>> For additional commands, e-mail: users-help@.apache
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
>
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715165.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
