-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Rossmueller Sent: Thursday, June 24, 2004 1:53 AM To: [EMAIL PROTECTED] Subject: Re: [Myfaces-develop] Fwd: MyFaces - Struts
Manfred Geiler wrote: > Matthias, Oliver, > > After some investigation I found out the following: > The RI works, because they always default to extension mapping. So, > like MyFaces they won't find the right mapping in the web.xml, but > since they do not handle this as an error condition, it works. > > Matthias, > Your patch might work in many cases but there are scenarios where it > is subject to fail. The addressed loop's purpose is to find the actual > servlet mapping that led to the faces request. Your patch would cut > off the comparison of the actual extension and the mapping extension. > So the loop would always exit on the very first extension mapping. > This will miss the goal. Imagine two mappings in web.xml: one > extension mapping for struts "*.do", one mapping for direct calls to > faces "*.jsf". > If there is a "*.jsf" call, the loop will find the first "*.do" > mapping and assume, that this is the seeked mapping. On a navigation > the destination viewId will get the wrong extension .do instead of > .jsf and the following request will wrongly go to struts. > > There are two possible solutions I think: > 1. Write a StrutsJspViewHandlerImpl as Oliver suggested > -1 from me, because different configuration needed for struts > > 2. After the loop finishes without a match: instead of throwing an > exception, log a warning only (struts folk can set the log severity > for JspViewHandlerImpl to error if they feel bothered) and return > null. Of course, depending methods must handle this default case. > +1 from me, because the mapping is not that critical (it works or it > works not, it won't change daily for an application), we get a > warning, which is enough hint if there are problems and we are more RI > compatible Manfred, the MyFaces implementation is correct in this aspect and I don't think we should clone the bugs of the RI just because struts relies on them. I hope spec-compliant does not mean we have to have the same bugs the RI has ;-)? By the way, if the RI is fixed, struts will not work there any longer, too. So the clean solution from my point of view is to fix the issue in struts. For example it would be possible to wrap the servlet request before the FacesContext is created. The wrapper takes the uri of the view to be displayed to simulate a valid jsf servlet path for the view manager. What do you think? Oliver > > Thanks, > Manfred > > >> Oliver >> >> i used the examples, that were shipped via struts-faces. >> >> there is a *link* to URL >> http://localhost:8080/struts-faces/editRegistration.do?action=Create >> >> okay, struts does it's way (the FacesRequestProcessor of >> integration-lib) >> >> Action.clazz gets processed. it returns an ActionForward-Objekt. >> (called "success"), but in struts-config the Actionforward points to >> a path "/registration.faces". ok fine. >> >> in FacesRequestProcessor, that is used instead of *default* >> RequestProcessor, the method "doForward()" checks, if URI >> (/registration.faces) is an Struts-Request. >> it is not that case. >> >> so it creates a FacesContext <code> >> // Create a FacesContext for this request if necessary >> LifecycleFactory lf = (LifecycleFactory) >> FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY); >> Lifecycle lifecycle = // FIXME - alternative lifecycle ids >> lf.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE); >> FacesContext context = FacesContext.getCurrentInstance(); >> if (context == null) { >> if (log.isTraceEnabled()) { >> log.trace(" Creating new FacesContext for '" + uri + >> "'"); >> } >> FacesContextFactory fcf = (FacesContextFactory) >> >> FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY); >> context = >> fcf.getFacesContext(servlet.getServletContext(), >> request, >> response, lifecycle); >> } >> </code> >> >> after that it creates a new ViewRoot, delegates the context to our >> JSPViewHandler, finally it calls responseComplete() <code> >> // Create a new view root >> ViewHandler vh = context.getApplication().getViewHandler(); >> if (log.isTraceEnabled()) { >> log.trace(" Creating new view for '" + uri + "'"); >> } >> context.setViewRoot(vh.createView(context, uri)); >> >> // Cause the view to be rendered >> if (log.isTraceEnabled()) { >> log.trace(" Rendering view for '" + uri + "'"); >> } >> lifecycle.render(context); >> context.responseComplete(); >> </code> >> >> >> so the Servlet-Path is still the *.do - thing, >> >> that code works *directly* with RI, >> >>> This will be the correct one in your case but might be wrong in some >>> other case. >> >> >> >> >> jupp :-) that was the reason of my question. >> do you need any more information on that? >> >> Cheers, >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by Black Hat Briefings & Training. Attend >> Black Hat Briefings & Training, Las Vegas July 24-29 - digital self >> defense, top technical experts, no vendor pitches, unmatched >> networking opportunities. Visit www.blackhat.com >> _______________________________________________ >> Myfaces-develop mailing list [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/myfaces-develop >> >> >> . >> > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. Attend > Black Hat Briefings & Training, Las Vegas July 24-29 - digital self > defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Myfaces-develop mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/myfaces-develop ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Myfaces-develop mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/myfaces-develop --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
