Perfect!

It worked, and now I just need to create my own AuthorizationStrategy to check the loggedinUser etc :) Thank you for the super help!

-- Edvin

Eelco Hillenius wrote:
On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Sessions in WebWork are stored in the HttpSession like this:

ActionContext.getContext().getSession().put(key, value);

so this should be trivial. Thanks a lot!

I have never needed to override newRequestCycle() in the WebApplication
class before, and it seems getHttpSession() is not available in the
default RequestCycle implementation. How do I get a hold of the
HttpSession object?
Something like this in your application:

        private static class MyRequestCycle extends WebRequestCycle
        {
                public static MyRequestCycle get()
                {
                        return (MyRequestCycle)RequestCycle.get();
                }

                public MyRequestCycle(WebApplication application, WebRequest
request, Response response)
                {
                        super(application, request, response);
                }

                public HttpSession getHttpSession()
                {
                        return 
getWebRequest().getHttpServletRequest().getSession(false);
                }
        }

        @Override
        public RequestCycle newRequestCycle(Request request, Response response)
        {
                return new MyRequestCycle(this, (WebRequest)request, response);
        }

Of course, you could do this in a custom Wicket session or utility
class as well if you use:
((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getSession(false);

And... why I would do this in a custom session and just call
super.getAttribute("_webwork_user"):
* Wicket encodes attributes in it's own way (prepends the application
key to it), so you'd have to circumvent that;
* It is not a certainty that the session store implementation that the
Wicket session uses, is using the HttpSession to start with (might be
a database or plain RAM for instance)

So the safest thing to do here is go directly to the HttpSession. You
can pretty much depend on the RequestCycle being a WebRequestCycle
unless you're doing something really different.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to