PrettyFaces, CDI and the case of the missing ?cid=xxx&#8230;

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.

February 13, 2012 at 5:17 am #22082

Moderator

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.

February 13, 2012 at 6:19 am #22083

Moderator

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.

February 13, 2012 at 6:30 am #22084

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

Moderator

I pushed the example app to a GitHub repository:

February 13, 2012 at 11:26 pm #22085

Keymaster

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.

February 13, 2012 at 11:34 pm #22086

Keymaster

FacesURLTransformer looks suspect.

February 13, 2012 at 11:35 pm #22087

https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/jsf/FacesUrlTransformer.java

Keymaster

February 13, 2012 at 11:35 pm #22088

Participant

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

I am glad you are even getting cid’s

February 14, 2012 at 5:02 am #22089

Moderator

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.

February 15, 2012 at 4:25 pm #22090

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

Moderator

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.

February 15, 2012 at 4:29 pm #22091

Moderator

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.

February 15, 2012 at 7:42 pm #22092

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?

February 15, 2012 at 7:46 pm #22093

https://community.jboss.org/thread/195138

Participant

This may be related:

February 15, 2012 at 7:49 pm #22094

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.

February 15, 2012 at 9:28 pm #22095