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