PlanetJava
Custom Search

java-stripes-user
[Top] [All Lists]

Re: Clean URLs failing on form post

Subject: Re: Clean URLs failing on form post
Date: Fri, 4 Feb 2011 07:23:33 +1100
Hi Nikolaos,
Adopting your approach for organising your web resources does work well
as a workaround for this issue, and is presumably why it's not a more
common problem.
I structure my web apps more like you than my last example (except for
the placement of JSPs), and I've now popped my JSPs under WEB-INF too,
so this issue really isn't hurting me any more either.
I also took of the @HandleEvent calls as suggested by Sam (I renamed
"new" to "create").
Things are much smoother now!
Kind regards,
William Rose
________________________________
From: Nikolaos Giannopoulos 
[mailto:[email protected]] 
Sent: Friday, 4 February 2011 2:23 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Sure, you could definitely come up with many ways to hit this particular
issue... and I won't refute that... .  In fact, I wasn't even aware of
it in the 1st place and I Thank You for sharing it with the community.
But, again I would never see it because any web app I build
"essentially" has WebRoot that looks like this:
/css
/img
/js
/WEB-INF
Not sure if this is explicit best practice but if it isn't it sure might
be implicit best practice as many a web app are built this way.
ASIDE:  I say "essentially" b/c we in fact have a structure that starts
with   /static/__ID/[css|img|js]   and when we release __ID is the
release version and we set the expires for everything under /static to 1
year and we will run it through a CDN... but that is all another story
altogether and I guess the only worry I could have is if I had a URL
binding that started with "/static/".... so thanks for the heads up... .
So in your case I would have:
/images
     /jobs
         /add-icon.png
         /del-icon.png
/css
     /edit.css
/WEB-INF
       /jsp
           /jobs
                /edit.jsp
                /list.jsp
And there are NUMEROUS intrinsic design benefits here as:
- you get fewer top level folders... easier to manage... yes you could
make the argument that having things dissected by business area /
ActionBean is easier to manage but I think if you try this you might see
what I am talking about... .
- all your images, css and js are rooted under 1 respective folder and
easily zipped, replaced, scanned, etc...             
- do you really have a different   edit.css   file for different
business areas / ActionBeans?
- when / if you add JS do you really have a different   JS   file for
different business areas / ActionBeans?
- having fewer css / JS files takes advantage of web browser caching,
limits the cost of the network trip hit, etc...
- and I can go on and on... but now we are talking about Application
Design... and grey areas... and are off topic... .
Does this not address your problem / the bug you found?
--Nikolaos
Rose William wrote: 
        Hi Nikolaos,
        It probably is!
        In my case, the only thing in my folder structure was JSPs, so
moving
        them to some other folder structure would fix the issue.
        More generally, though, I thought that part of the magic of
        DynamicMappingFilter was supposed to be that one could have
one's action
        beans appearing to share the same folders as their resources
(e.g. CSS,
        JS, images) and so it ought not matter that the JSPs were there
too.
        Let's say I rearranged my JSPs, but also added some extra
graphics and
        stylesheets:
        /jobs
             /images
                    /add-icon.png
                    /del-icon.png
             /css
                 /edit.css
        /WEB-INF
               /jsp
                   /jobs
                        /edit.jsp
                        /list.jsp
        I still have the same problem with Tomcat adding a / to
        /contextPath/jobs, despite following best practice for placement
of
        JSPs.
        Kind regards,
        William Rose
        Business Intelligence Team Leader
        Information Management
        +61 3 9656 5231   |   Level 8, St Andrews Place, East Melbourne
VIC 3002
        -----Original Message-----
        From: Nikolaos Giannopoulos 
[mailto:[email protected]] 
        Sent: Thursday, 3 February 2011 2:11 PM
        To: Stripes Users List
        Subject: Re: [Stripes-users] Clean URLs failing on form post
        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
                [email protected]
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
        [email protected]
        https://lists.sourceforge.net/lists/listinfo/stripes-users
        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
        [email protected]
        https://lists.sourceforge.net/lists/listinfo/stripes-users
-- 
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. [email protected]
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
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.
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
msgmiddle
<Prev in Thread] Current Thread [Next in Thread>
Current Sitemap | © 2012 planetjava | Contact | Privacy Policy