Announcement Announcement Module
Collapse
No announcement yet.
Weblogic losing flow execution id Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Weblogic losing flow execution id

    I wrote a simple 4 page flow to showcase the use of weblogic in the project of one of our customers. The flow worked perfectly in Tomcat 4.1, but for some reason that I don't understand, I can't get it to work under Weblogic 8.1
    Initially it simply didn't work, complaining about a Logging package. Now, it seems to be losing the flow Id: I start the flow, press the first submit button and I get the following exception:

    org.springframework.webflow.execution.NoSuchFlowEx ecutionException: No executing flow could be found with id 'BE8201A7-78E6-45E9-1317-724669B02D58' -- perhaps the flow has ended or expired? This could happen if your users are relying on browser history (typically via the back button) that reference ended flows.; nested exception is java.lang.IllegalStateException: No session attribute 'org.springframework.webflow.execution.FlowExecuti on.BE8201A7-78E6-45E9-1317-724669B02D58' found


    Am I missing some extra configuration step in Weblogic? As I said, this works perfectly under Tomcat, but I simply can't get it to run under WL.

    Thanks

  • #2
    My guess would be that it's a session management problem. WebLogic does not detect that the second request belongs to the same HTTP session as the first, so it creates a new HTTP session and ofcourse cannot find the flow execution in it (it's in the other session...). Check the WebLogic configuration to make sure it is properly dealing with sessions: either using cookies or using URL rewriting. When using cookies, also make sure you browser is set to accept them.

    Erwin

    Comment


    • #3
      I realize this post is quite old, but I'm noticing the same issue when deploying to WebLogic 9.2.

      The app is working fine for development when we deploy to Jetty, but once we deploy to WebLogic the alwaysRedirectOnPause set to true seems to be making WebLogic give a new session for each redirect. The end result is that SWF can't find the flow execution.

      I'm not too familar with how the alwaysRedirectOnPause works (beyond reading http://www.ervacon.com/products/swf/tips/tip4.html). So I was hoping someone else may have already overcome this problem. Has anyone successfully deployed to WebLogic using alwaysRedirectOnPause? If so, was there something special you did to not get a new session on redirect?

      Thanks!

      Comment


      • #4
        Bizar.
        Anyway, it seems like a good idea to sanity test SWF usage on a number of major app servers, so I've created a JIRA issue to get this on the radar:
        http://jira.springframework.org/browse/SWF-475

        Erwin

        Comment


        • #5
          As a note to the problem I'm seeing, it seems to only happen with Internet Explorer an WebLogic. I can have the same application deployed to WebLogic and use Firefox without a problem. To clarify what I said before, we can use Jetty and Internet Explorer (or Firefox) without a problem.

          Comment


          • #6
            Flow gets lost on Websphere 6.0

            Actually, the same problem is with IBM Websphere 6.0 - IE or Firefox does not matter. It happens however with some portlets only, my guess with those that are instantiated on public pages. For example from a "login" page is a link to "remind password" page. A portlet on that page gets displayed fine, but 100% looses flow execution id when submit is pressed.

            Any way of detecting beforehand is session is lost and generate a new flow key?

            Andrius

            Comment


            • #7
              I've actually found a workaround for my IE/WebLogic issue -- it may or may not help out with your Websphere issue, Andrius.

              We wrote our own serlvet to handle incoming SWF requests, so we have full control over how the redirect is issued (before we were using a combination of Spring MVC's DispatcherServlet and SWF's MVC FlowController). With full control over the redirect, we can now issue a special response if we're in WebLogic:

              Code:
                      String serverInfo = getServletContext().getServerInfo();
              
                      if (serverInfo != null && serverInfo.indexOf("WebLogic") >= 0) {
                          response.setHeader("Set-Cookie", "JSESSIONID=" + request.getSession().getId() + ";path=" + request.getContextPath());
                      }
              
                      response.sendRedirect(response.encodeRedirectURL(url));
              As long as we explicitly set the request's session ID as the Set-Cookie header before sending the response while in WebLogic, everything works just fine. Since the Set-Cookie header is the default behavior of response.sendRedirect(), I don't think there will be an issue with it, but you do end up with two values for the Set-Cookie header (from what I've seen debugging in WebLogic). My testing is showing that IE is able to figure out the correct session ID to use, though. If someone reading this post can see a problem with this approach please speak up.

              This workaround leads me to believe that the problem is less with SWF and more with how the browsers are interpreting the responses created by the servers. Especially since I don't have the problem with IE & Firefox while using Jetty and I don't have the problem with Firefox and WebLogic, but I do have a problem with IE and WebLogic. (The deployed code stays the same in all cases.)
              Last edited by tjstavenger; Feb 19th, 2008, 02:30 PM.

              Comment


              • #8
                Anonymous user sessions

                Ok, turns out sessions were not enabled for anonymous users.

                Thanks for help,
                Andrius

                Comment


                • #9
                  Just for reference, we use SWF 1 and 2 in production weblogic 9.2 MP3 environments with full range of browser support w/o issue.

                  Comment

                  Working...
                  X