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
Wouldn't the problem be that tapestry uses web/server sessions for lots of
things and doesn't really know about Shiro sessions? Or are you planning to
get tapestry to use Shiro sessions?
On Aug 8, 2012, at 12:44 PM, Kalle Korhonen wrote:
> On Wed, Aug 8, 2012 at 8:24 AM, kata wrote:
>> Havin
On Wed, Aug 8, 2012 at 8:24 AM, kata wrote:
> 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
I would avoid using shiro native sessions.
Saying that, one thing you might try to do is to override Tapestry Session
service.
I don't know if that's possible. Using Alex K's approach would only override
@Persist annotations, etc.
which would only solve part of the problem for you, not all of it
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 T
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 tryin
Lenny - why do you think it would be a problem ?
Cheers - Alex K
On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak 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
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 so
It seems that you could override the session persistence strategy and
replace the usage of http session with Shiro's session -e.g. the
implementation seems to be pretty straightforward e.g. inside of Tapestry ,
look at SessionApplicationStatePersistenceStrategy (
http://www.koders.com/java/fidD25B0
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 stra
So you are using native Shiro session management. Tapestry / Servlet API don't
support that.
If you use a 'real' JEE server like Glassfish, web sessions are clustered /
cached properly for you,
without Shiro native sessions or customDAO etc.
You cannot use Shiro native session management and ex
The problem with this is that while the servlet session manager doesn't
support a custom sessoinDAO, which i need for caching and clustering
sessions. Using native session is the only way to do that (as far as i
know).
lprimak wrote
>
> Are you 'forcing' Shiro's native session management? If yo
Are you 'forcing' Shiro's native session management? If you are then you will
get that behavior.
My suggestion is for you not to do it. The Tynamo security's default
configuration works just great.
Tapestry does not have its own session management, it's just a wrapper for
Servlet's one.
Shiro,
Then there must be some crucial bit of configuration I'm missing. Every time
I visit a page which uses a @Persist annotation, tapestry ignores shiros'
session and tries to access its own. If I don't change the cookie names,
shiro and tapestry overwrite the default JSESSION cookie and nothing works.
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 a
On Wed, Aug 8, 2012 at 4:20 AM, kata wrote:
> 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
As Alex said before, the backing objects for all session management, Shiro's,
Tapestry, and Servlet
are the same 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 se
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 i
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 wrote:
> Hi all,
>
> I
19 matches
Mail list logo
