You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Matthias Wessendorf <ma...@matthias-wessendorf.de> on 2004/07/08 18:33:21 UTC

FW: [Myfaces-develop] Fwd: MyFaces - Struts


-----Original Message-----
From: Matthias Wessendorf [mailto:mailings@matthias-wessendorf.de] 
Sent: Thursday, July 08, 2004 6:22 PM
To: 'craigmcc@apache.org'
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: myfaces-develop-admin@lists.sourceforge.net
[mailto:myfaces-develop-admin@lists.sourceforge.net] On Behalf Of
Manfred Geiler
Sent: Wednesday, June 23, 2004 1:14 PM
To: myfaces-develop@lists.sourceforge.net
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 Myfaces-develop@lists.sourceforge.net
> 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 Myfaces-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/myfaces-develop


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org