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

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

#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.