Issue with @ConversationScoped bean

Splash Forums Rewrite Users Issue with @ConversationScoped bean

This topic contains 9 replies, has 4 voices, and was last updated by  Christian Kaltepoth 8 years, 3 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #25150


    Our application initially used @SessionScoped backing bean that was then replaced by a @ConversationScoped bean. Using @ConversationScoped bean, we noticed that the unique identifier of the conversation is now automatically appended to the urls. For example : /my-file.xhtml?cid=1 where cid is the identifier of the conversation.

    Since the ‘cid’ parameter is passed in urls, rewriting no longer works.

    Rewriting rule is:

    Using the rule above, if a request is made to:

    The result is:
    The extension of the file is still present + the querystring parameters…

    Using a @SessionScoped bean, we obtain the expect result :

    Have you ever experienced this before? Except not using the @ConversationScoped context, do you have any idea what could be done to have the urls correctly generated? Or maybe a class that could be overrided?

    Thank you


    Heya, that’s interesting behavior (and seems maybe not correct.) Any chance you could upload a sample maven project to reproduce this? I could hypothesize, but I’d rather just take a look 🙂



    Hi Lincoln,

    Unfortunately I could not upload the code of the project I’m working on so I took a sample of code using Conversations and integrated Rewrite. I’ve been able to reproduce the problem.

    When accessing the first page of the wizard, an error will occur. However, if you remove the rule in URLConfigurationProvider and test again, everything will work fine.



    Hi Lincoln,

    Did you get a chance to look at the code sample I uploaded?


    Hey There,

    So I just got a chance to try out your example, and it looks like everything is working as I would expect. Perhaps you could explain a bit more about what you are expecting to happen as I navigate this flow?

    I’m still a bit confused about the scenario you’re describing. Based on the URL-mapping in your sample application, everything seems to be working fine based on what I would expect from the configuration you’ve set.

    Could you step me through your sample app and describe east step in detail?




    Sorry the late response. I found it strange you were unable to reproduce the problem so I realized that the application server might be the reason why that did not work for me. Hence I tested the app on Glassfish and it the good news is that it works fine. However, we face the issue with Weblogic 12.1.2 and this is the production server used for the project.

    Port 8080 -> Glassfish
    Port 7001 -> Weblogic

    In its original format, the url for the first page is:

    Then we applied a rule for that first page.
    return ConfigurationBuilder.begin().addRule(Join.path("/step1/{cid}").to("/wizard/firstStep.jsf"));

    Once the rewriting applied, the url is:
    http://localhost:8080/com.wizard/step1/2 where the number on the right of the last slash is the Conversation identifier.

    On Weblogic, here’s the url is obtained:

    The rewriting is done but the extension + querystring parameters are appended at the end of the url… I hope these details will help you in your investigation.

    Thank you

    • This reply was modified 8 years, 3 months ago by  jfmarcoux.

    I’ll keep looking in to this as much as possible, but I have to say that I don’t think it really makes sense to embed the conversation ID in the path of the URL. This is something that is not part of the permanent address, and may be changed at any time (by the container, even.)

    Why not simply rewrite the XHTML file and ignore this parameter? (I.e. Let is remain a query parameter.)



    You are right that the conversation conversation ID should not be embed in the path of the URL.

    By changing the rule for:
    return ConfigurationBuilder.begin().addRule(Join.path("/step1").to("/wizard/firstStep.jsf"));

    We can expect to have the cid as a query parameter. However, here’s the result on Weblogic :

    On Glassfish, that works fine:

    • This reply was modified 8 years, 3 months ago by  jfmarcoux.
    • This reply was modified 8 years, 3 months ago by  jfmarcoux.


    I worked with JF and I found the problem with Weblogic 12.1.2. Actually weblogic uses an internal version of JSF-api that you can found at this address

    The problem occurs in the class under the getActionURL method after the comment //Deal with extension mapping.

    1) the URL rewrite returns the right URL – http://localhost:7001/com.wizard/step1?cid=2
    2) the code in the MultiViewHandler class looks for an extension that doesn’t exist. So it adds the extension at the end of the URL – http://localhost:7001/com.wizard/step1?cid=2.jsf.
    3) JSF tries to check if the URL contains the parameter cid and it found it so it adds it (http://localhost:7001/com.wizard/step1?cid=2.jsf&cid=2)

    Do you have an idea how I can fix this problem?

         * <p>
         * This code is currently common to all {@link ViewHandlingStrategy} instances.
         * </p>
         * @see ViewHandler#getActionURL(javax.faces.context.FacesContext, String)
        public String getActionURL(FacesContext context, String viewId) {
            Util.notNull("context", context);
            Util.notNull("viewId", viewId);
            if (0 == viewId.length() || viewId.charAt(0) != '/') {
                String message =
                if (logger.isLoggable(Level.SEVERE)) {
                    logger.log(Level.SEVERE, "jsf.illegal_view_id_error", viewId);
            throw new IllegalArgumentException(message);
            // Acquire the context path, which we will prefix on all results
            ExternalContext extContext = context.getExternalContext();
            String contextPath = extContext.getRequestContextPath();
            // Acquire the mapping used to execute this request (if any)
            String mapping = Util.getFacesMapping(context);
            // If no mapping can be identified, just return a server-relative path
            if (mapping == null) {
                return (contextPath + viewId);
            // Deal with prefix mapping
            if (Util.isPrefixMapped(mapping)) {
                if (mapping.equals("/*")) {
                    return (contextPath + viewId);
                } else {
                    return (contextPath + mapping + viewId);
            // Deal with extension mapping
            int period = viewId.lastIndexOf('.');
            if (period < 0) {
                return (contextPath + viewId + mapping);
            } else if (!viewId.endsWith(mapping)) {
                for (String ext : configuredExtensions) {
                    if (viewId.endsWith(ext)) {
                        return (contextPath + viewId.substring(0, viewId.indexOf(ext)) + mapping);
                return (contextPath + viewId.substring(0, period) + mapping);
            } else {
                return (contextPath + viewId);

    Hmmm. Actually I’m surprised that MultiViewHandler sees the rewritten URL. The RewriteViewHandler delegates the view ID to the parent view handler (which should be MultiViewHandler) without modification. So Rewrite should modify the result of what the MultiViewHandler creates.

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

The forum ‘Rewrite Users’ is closed to new topics and replies.

Comments are closed.