Current http request in dynaview using pretty faces 3.2.0, seam 2.2.0, jboss 4.3

Splash Forums PrettyFaces Users Current http request in dynaview using pretty faces 3.2.0, seam 2.2.0, jboss 4.3

This topic contains 5 replies, has 2 voices, and was last updated by  Christian Kaltepoth 5 years, 11 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #18081

    andyredhead
    Participant

    Hi,

    I’m playing with the dynaview functionality in prettyfaces 3.2.0 using Seam

    2.2.0 (and jboss 4.3 cp09).

    In pretty-config.xml I have a seam bean configured via an EL expression which

    just returns a hard coded string as the template path, which works :)

    However, I’d really like to be able to access the reqeusted url in the seam bean

    (and use that as part of the logic which determines the path to a template).

    I’ve tried to inject the current http request using @In HttpServletRequest and

    also tried using

    ServletContexts.getInstance().getRequest()

    both return null :(

    Is there any way I can access the current HttpServletRequest from within a Seam

    2.2.0 bean acting as a dynaview “template path resolver”?

    Thanks, Andy

    [appologies if this post comes through via email as well – I tried emailing the list first but I dont think the mail got through]

    #21667

    andyredhead
    Participant

    So, after browsing around the prettyfaces source code I found the PrettyContext object.

    code

    PrettyContext prettyContext = PrettyContext.getCurrentInstance();

    _log.info(“getViewPath – pretty context is: “, prettyContext);

    if (prettyContext != null) {

    _log.info(“getViewPath – url info in pretty context: #0”, prettyContext.getRequestURL());

    }

    code

    This at least gives me access to the incoming request url but it doesn’t seem to give me access to the http request.

    Is there any standard way to access the current http request from within a dynaview bean?

    Thanks.

    #21668

    andyredhead
    Participant

    Hi,

    Lincoln has been kind enough to post a response to my original email (thank you)

    http://groups.google.com/group/prettyfaces-users/msg/2ca8ebd5820351a4

    Unfortunately the aging version of Seam we are currently working with doesnt have @RequestScope.

    I have a work-around which is to use a servlet filter to add the current request as a thread local variable which can be accessed by the dynaview resolving bean. I haven’t tested it much beyond clicking the url in a browser a couple of times but it seems to work :)

    My hacky prototype code shown below.

    Cheers, Andy

    Filter:

    public class RequestCaptureFilter implements Filter {

    /** Standard logger. */
    private static final Log LOG = LogFactory.getLog(RequestCaptureFilter.class);

    @Override
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain filterChain) throws IOException, ServletException {
    if (LOG.isDebugEnabled()) {
    LOG.debug("doFilter - start");
    }

    String pathStr = ((HttpServletRequest) req).getServletPath();
    String reqUri = ((HttpServletRequest) req).getRequestURI();
    String contextPath = ((HttpServletRequest) req).getContextPath();

    if (LOG.isDebugEnabled()) {
    LOG.debug("servlet path is: " + pathStr + ", context path: " + contextPath + ", reqUri: " + reqUri);
    }

    try {

    ThreadLocalRequest.set(req);

    filterChain.doFilter(req, resp);

    } catch (Exception e) {
    LOG.info("doFilter - exception from further down filter chain", e);
    } finally {
    try {
    ThreadLocalRequest.unset();
    } catch (Exception e) {
    LOG.warn("doFilter - problem unsetting thread local request", e);
    }
    }

    if (LOG.isDebugEnabled()) {
    LOG.debug("doFilter - finish");
    }
    }

    }

    Thread Local accessor class:

    public class ThreadLocalRequest {

    private static final ThreadLocal<ServletRequest> userThreadLocal = new ThreadLocal<ServletRequest>();

    public static void set(ServletRequest req) {
    userThreadLocal.set(req);
    }

    public static void unset() {
    userThreadLocal.remove();
    }

    public static ServletRequest get() {
    return userThreadLocal.get();
    }

    }

    Dynaview resolver bean:

    @Name(value = "AppUrlDynaview")
    @Scope(ScopeType.APPLICATION)
    @Startup(depends={"org.jboss.seam.navigation.pages"})
    public class AppUrlDynaview {

    @Logger
    Log _log;

    @Create
    public void create() {
    _log.debug("create - hello");
    }

    String _theUrl;

    public String getViewPath() {

    _log.info("getViewPath - start");

    ServletRequest servletReq = (HttpServletRequest) ThreadLocalRequest.get();

    if (servletReq != null) {

    _log.info("getViewPath - non null thread local request", servletReq);

    } else {
    _log.warn("getViewPath - null request in ThreadLocalRequest");
    }

    return "/home.seam";
    }

    public String getTheUrl() {
    return _theUrl;
    }

    public void setTheUrl(String urlStr) {
    _theUrl = urlStr;
    }

    }

    #21669

    Using a ThreadLocal is a good idea to work around this issue.

    But I think you could also use PrettyContext.getCurrentInstance().getRequestURL() for this as Lincoln wrote. Or doesn’t this work for you?

    Another thing. If you are using dynaview a highly recommend to update to the most recent PrettyFaces version 3.3.2 as it contains some important bugfixes for dynaview.

    Christian

    #21670

    andyredhead
    Participant

    Hi,

    using

    PrettyContext.getCurrentInstance().getRequestURL()

    worked fine – I’m looking at using more than just the incoming URL to determine which template to use, specifically the user information we have stored in the session.

    The intent is to do some basic A/B variant testing…

    I was wondering about an upgrade to 3.3.2 – though I got the impression that 3.3.3 may be released sometime in the near future?

    Cheers, Andy

    #21671

    You should definitively update to 3.3.2 as 3.2.0 is a very outdated version and the recent releases contained a lot of bug fixes. I don’t know when 3.3.3 will be released but if it gets released it will be a very smooth update from 3.3.2.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Comments are closed.