PrettyFaces, CDI and the case of the missing ?cid=xxx…

Splash Forums PrettyFaces Users PrettyFaces, CDI and the case of the missing ?cid=xxx…

Tagged: 

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

Viewing 15 posts - 16 through 30 (of 44 total)
  • Author
    Posts
  • #22081

    Tony Herstell
    Participant

    Christian and Lincoln,

    Sorry for the trouble.

    I am very keen to use pretty-faces and I guess this does clear the roadblock for the other people following on behind me.

    :)

    #22082

    No worries. We are also very interested in fixing this issue. In the mean time I created a minimal example app reproducing this and I’m currently looking deeper into it.

    I’ll keep you update. :)

    #22083

    Hey there,

    I’ve some news. Good news and bad news.

    The good news is that in my minimal sample application Weld appends the cid parameter. The bad news is that Weld completely breaks the URL while doing so.

    In my setup I call an action which starts an conversation and then redirects to a pretty URL /pretty/conversation. But the browser is either redirected to:

    /faces/pretty/conversation?cid=1&cid=1

    or to:

    /pretty/conversation?cid=1.jsf&cid=1

    (depending on the mapping of the FacesServlet)

    I’ve tested this with JBoss AS 7.1.0.CR1b.

    #22084

    I pushed the example app to a GitHub repository:

    https://github.com/chkal/pf-cdi-test

    #22085

    This really seems like a JSF bug. I don’t have the JSF sources, but for one single call of super.perform(…) in PrettyNavigationHandler, the PrettyFacesWrappedResponse.encodeURL(…) method is called twice!

    This is not good.

    In addition, the second time encodeURL is called, PrettyFaces is passed an extra cid parameter, and the URL is wrong (has extra /faces/* on the beginning.)

    I’m not exactly sure why this is happening. But it seems to have changed in JSF / CDI recently, because this used to work fine, and PrettyFaces is not changing the URL here. JSF is modifying it incorrectly.

    The first call occurs here:

    Daemon Thread [http--0.0.0.0-8080-1] (Suspended (breakpoint at line 97 in PrettyFacesWrappedResponse))
    PrettyFacesWrappedResponse.encodeURL(String) line: 97
    ConversationPropagationFilter$1(HttpServletResponseWrapper).encodeURL(String) line: 114
    ExternalContextImpl.encodeActionURL(String) line: 514
    MultiViewHandler.getRedirectURL(FacesContext, String, Map<String,List<String>>, boolean) line: 381
    PrettyViewHandler.getRedirectURL(FacesContext, String, Map<String,List<String>>, boolean) line: 150
    ConversationAwareViewHandler(ViewHandlerWrapper).getRedirectURL(FacesContext, String, Map<String,List<String>>, boolean) line: 204
    ConversationAwareViewHandler.getRedirectURL(FacesContext, String, Map<String,List<String>>, boolean) line: 131
    NavigationHandlerImpl.handleNavigation(FacesContext, String, String) line: 166
    PrettyNavigationHandler.handleNavigation(FacesContext, String, String) line: 64
    ActionListenerImpl.processAction(ActionEvent) line: 130
    HtmlCommandButton(UICommand).broadcast(FacesEvent) line: 315
    UIViewRoot.broadcastEvents(FacesContext, PhaseId) line: 794
    UIViewRoot.processApplication(FacesContext) line: 1259
    InvokeApplicationPhase.execute(FacesContext) line: 81
    InvokeApplicationPhase(Phase).doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) line: 101
    LifecycleImpl.execute(FacesContext) line: 118
    FacesServlet.service(ServletRequest, ServletResponse) line: 593
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 329
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    ConversationPropagationFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 62
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 280
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    PrettyFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 126
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 280
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    StandardWrapperValve.invoke(Request, Response) line: 275
    StandardContextValve.invoke(Request, Response) line: 161
    SecurityContextAssociationValve.invoke(Request, Response) line: 151
    StandardHostValve.invoke(Request, Response) line: 155
    ErrorReportValve.invoke(Request, Response) line: 102
    StandardEngineValve.invoke(Request, Response) line: 109
    CoyoteAdapter.service(Request, Response) line: 362
    Http11AprProcessor.process(long) line: 897
    Http11AprProtocol$Http11ConnectionHandler.process(long) line: 626
    AprEndpoint$Worker.run() line: 2033
    Thread.run() line: 662

    Then the second invocation which contains the incorrect URL – seems to change in ConversationPropagationFilter:

    Daemon Thread [http--0.0.0.0-8080-1] (Suspended (breakpoint at line 97 in PrettyFacesWrappedResponse))
    PrettyFacesWrappedResponse.encodeURL(String) line: 97
    ConversationPropagationFilter$1(HttpServletResponseWrapper).encodeURL(String) line: 114
    ExternalContextImpl.encodeActionURL(String) line: 514
    FacesUrlTransformer.encode() line: 101
    ConversationPropagationFilter$1.sendRedirect(String) line: 76
    ExternalContextImpl.redirect(String) line: 576
    NavigationHandlerImpl.handleNavigation(FacesContext, String, String) line: 182
    PrettyNavigationHandler.handleNavigation(FacesContext, String, String) line: 64
    ActionListenerImpl.processAction(ActionEvent) line: 130
    HtmlCommandButton(UICommand).broadcast(FacesEvent) line: 315
    UIViewRoot.broadcastEvents(FacesContext, PhaseId) line: 794
    UIViewRoot.processApplication(FacesContext) line: 1259
    InvokeApplicationPhase.execute(FacesContext) line: 81
    InvokeApplicationPhase(Phase).doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) line: 101
    LifecycleImpl.execute(FacesContext) line: 118
    FacesServlet.service(ServletRequest, ServletResponse) line: 593
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 329
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    ConversationPropagationFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 62
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 280
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    PrettyFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 126
    ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 280
    ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 248
    StandardWrapperValve.invoke(Request, Response) line: 275
    StandardContextValve.invoke(Request, Response) line: 161
    SecurityContextAssociationValve.invoke(Request, Response) line: 151
    StandardHostValve.invoke(Request, Response) line: 155
    ErrorReportValve.invoke(Request, Response) line: 102
    StandardEngineValve.invoke(Request, Response) line: 109
    CoyoteAdapter.service(Request, Response) line: 362
    Http11AprProcessor.process(long) line: 897
    Http11AprProtocol$Http11ConnectionHandler.process(long) line: 626
    AprEndpoint$Worker.run() line: 2033
    Thread.run() line: 662

    Still a bit confused… but PrettyFaces isn’t breaking this directly at least. I think this looks like a Mojarra bug.

    #22086

    FacesURLTransformer looks suspect.

    #22087
    #22088

    Tony Herstell
    Participant

    In the project I supplied there is no ?cid=xxx at all!

    I am glad you are even getting cid’s

    #22089

    Yeah, I saw FacesURLTransformer too. This really looks like this class is messing up the URL.

    I really don’t get why Weld is not appending the cid parameter in encodeURL() but in redirect(). This doesn’t make sense to me. And it will definitively won’t work for AJAX requests. In the AJAX case Mojarra renders JavaScript that reloads the target URL in the client. In this case redirect() isn’t involved.

    #22090

    Now it’s getting really weird!

    I just added Tomcat profiles to my sample project. One for MyFaces and one for Mojarra. Both are working fine and without any problems. The cid is added exactly once to the URL and the pretty URLs aren’t messed up. I’m using the same Weld version with Tomcat as AS7 uses which is 1.1.4.Final.

    I’m stumped.

    I’ve pushed the changes I made for my sample project to GitHub. Just in case anybody want’s to take a look.

    https://github.com/chkal/pf-cdi-test

    #22091

    Perhaps it has something to do with the ordering of the filters? Both PrettyFaces and Weld are wrapping the response and the order of the filters is having influence on which response wraps the other one.

    And in AS7 the filter is likely added by the Weld integration layer of AS7. In Tomcat is different.

    Just a thought. I’ve to think about this more.

    #22092

    Tony Herstell
    Participant

    Thank so much for your persistence on this matter.

    It is worth cross posting to the Weld forum to see if they can assist?

    #22093

    Tony Herstell
    Participant
    #22094

    Tony Herstell
    Participant

    Sorry; it probably is not related.

    It’s a shame that we have to keep adding conversationIds when still in a conversation on a command button.

    Seam 2 seems to have conversations working very well.

    #22095

    To be honest – I don’t bother using the Conversation scope because it just isn’t very good.

Viewing 15 posts - 16 through 30 (of 44 total)

You must be logged in to reply to this topic.

Comments are closed.