-----Original Message----- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 6:22 PM To: '[EMAIL PROTECTED]' Subject: FW: [Myfaces-develop] Fwd: MyFaces - Struts
Hey Craig, this email (from manfred geiler) i missed after that oliver pointed out, that RI has a bug. do you need more? Matthias -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Geiler Sent: Wednesday, June 23, 2004 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [Myfaces-develop] Fwd: MyFaces - Struts 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 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
