William,

Isn't it best practice to place ones JSPs rooted under /WEB-INF.  This 
ensures that your JSPs are never directly accessible from the outside 
while still allowing your ActionBean's to forward to them.

If you followed this then Tomcat nor any other Web Container would 
succeed in placing a slash and matching your JSP structure.

Or am I missing something...?

--Nikoloas




Rose William wrote:
> Hi there,
>  
> I found the recent discussion on the mailing list about clean URLs
> seemingly failing to find the right event handler when a form is POSTed,
> and saw a variety of solutions to creating the URL oneself.
>
> After trying to debug the same issue myself, I think the reason for this
> behaviour is tied up in Tomcat bug 32424 (see
> https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
>
>
> My web app is set up with DynamicMappingFilter applied to /*.
>
> I have a WEB directory structure like this:
>
>    /jobs
>         /edit.jsp
>         /list.jsp
>
> I have an action bean annotated like this:
>
>    @UrlBinding("/jobs/{$event}/{fullName}")
>
> There is a list event, new event and save event:
>
>       //@DefaultHandler
>       @DontBind
>       @HandlesEvent("list")
>       public Resolution list() throws SchedulerException {
>               s_log.debug("in list()");
>               
>               return new ForwardResolution("/jobs/list.jsp");
>       }
>
>       @HandlesEvent("new")
>       @DontValidate
>       public Resolution newJob() throws SchedulerException {
>               s_log.debug("in newJob()");
>               
>               return new ForwardResolution("/jobs/edit.jsp");
>       }
>       
>       @HandlesEvent("save")
>       public Resolution saveJob() throws SchedulerException {
>               
>               return new RedirectResolution(JobAction.class,
> "edit").addParameter("fullName", this.jobDetail.getFullName());
>       }
>
>
>
> In edit.jsp, I have a form like this:
>
>    <stripes:form name="jobEdit" id="jobEditForm"
> beanclass="myorg.action.JobAction">
>        [form fields]
>        <stripes:submit name="save" value="Save" />
>    </stripes:form>
>
>
> What happens is that when the page is rendered, I get HTML like:
>
>         <form id="jobEditForm" name="jobEdit" action="/contextPath/jobs"
> method="post"> 
>
>
> The important thing to note here is that /contextPath/jobs resolves to a
> folder -- the one that contains edit.jsp and possibly other resources.
> Ostensibly, DynamicMappingFilter caters for such things because it waits
> until the request 404's before handling it. And when a link is
> constructed or a form submitted using GET, everything is just fine.
>
> The problem is that Tomcat, as per the bug above, sees that
> /contextPath/jobs is a folder early in the processing of the POSTed form
> and issues a redirect to /contextPath/jobs/. This happens means all the
> POST data is dropped and a GET request to /contextPath/jobs/ with no
> extra parameters is issued.
>
> Hence, Stripes will complain with errors like "No default handler could
> be found for ActionBean", or just show the default handler for that
> action bean (in my case, if I uncommented the @DefaultHandler
> annotation, I would always see the job list).
>
> I think that this is why fixes proposed in the recent thread that
> involved creating the URL differently would end up working -- in the
> end, those URLs would be terminated with a slash, or at least would not
> end up looking like a known directory to Tomcat. Other web containers
> may do the same thing.
>
> So a potential fix for Stripes to work around the fact that Tomcat devs
> consider this "not a bug" is to have the form tag pop a / at the end of
> beanclass based URLs when the method is POST (?).
>
> My workaround is to make my URL patterns not overlap with actual folders
> -- changing jobs to job in @UrlBinding("/job/{$event}/{fullName}") --
> means that the post URL is /contextPath/job, and Tomcat doesn't mess
> with it.
>
> I hope this helps someone avoid spending their morning trying to figure
> out why their by-the-book clean URL is not working!
>
> Kind regards,
>  
> William Rose
>
> This email (including any attachments or links) may contain 
> confidential and/or legally privileged information and is 
> intended only to be read or used by the addressee.  If you 
> are not the intended addressee, any use, distribution, 
> disclosure or copying of this email is strictly 
> prohibited.  
> Confidentiality and legal privilege attached to this email 
> (including any attachments) are not waived or lost by 
> reason of its mistaken delivery to you.
> If you have received this email in error, please delete it 
> and notify us immediately by telephone or email.  Peter 
> MacCallum Cancer Centre provides no guarantee that this 
> transmission is free of virus or that it has not been 
> intercepted or altered and will not be liable for any delay 
> in its receipt.
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>   


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to