Can you create a quickstart ?
It looks like either javax.servlet.forward.url is not set as attribute
in the HttpServletRequest or Wicket doesn't use it.
I think it is the latter.

On Sat, Oct 8, 2011 at 11:56 PM, Chris Colman
<[email protected]> wrote:
> Looks like the redirect is due to the PRG strategy implementation so it's set 
> to REDIRECT_TO_BUFFER.
>
> (From my, possibly naïve, understanding I thought you only needed PRG when a 
> form submission was involved but it looks like it's applied to every page 
> request).
>
> I probably should keep using the redirect strategy option otherwise I will 
> encounter the double submit problem with forms.
>
> I just need to know how I can get wicket to allow me to do a forward of
>
> www.mysite.com
>
> to a URL of the style
>
> www.mysite.com/content/home/o/123
>
> without performing a redirect that changes the user's browser address field.
>
>>-----Original Message-----
>>From: Chris Colman [mailto:[email protected]]
>>Sent: Saturday, 8 October 2011 10:52 PM
>>To: [email protected]
>>Subject: RE: Forwarding in 1.5 not working like in 1.4
>>
>>Could it be that Wicket sees the original URL as being / (i.e. home page)
>>and so performs a redirect to the home page? Possibly it should be looking
>>at the 'forward' request URL which is not / but "content/home/o/76429" and
>>should be handled directly without a redirect.
>>
>>>-----Original Message-----
>>>From: Chris Colman [mailto:[email protected]]
>>>Sent: Saturday, 8 October 2011 10:28 PM
>>>To: [email protected]
>>>Subject: RE: Forwarding in 1.5 not working like in 1.4
>>>
>>>I have found that the method below appears to return the wrong result for
>>>relativeUrl:
>>>
>>>WebPageRender.java
>>>
>>>            protected void redirectTo(Url url, RequestCycle requestCycle)
>>>            {
>>>                        WebResponse response =
>>>(WebResponse)requestCycle.getResponse();
>>>                        String relativeUrl =
>>>requestCycle.getUrlRenderer().renderUrl(url);
>>>                        response.sendRedirect(relativeUrl);
>>>            }
>>>
>>>On input to the renderUrl method url = "content/home/o/76429?6"
>>>
>>>On return relativeUrl = "76429?6"
>>>
>>>Possibly the problem is in UrlRenderer.renderRelativeUrl(Url url)
>>>
>>>Given that the UrlRender has it's baseUrl as content/home/o/76429 then,
>>>according to my naïve understanding of how the Wicket internals work, the
>>>relative URL it returns should be
>>>
>>>?6
>>>
>>>not
>>>
>>>"76429?6"
>>>
>>>Does this make sense?
>>>
>>>
>>>I'm not quite sure why it is appearing to perform a redirect in the first
>>>place.
>>>
>>>If I point the browser to
>>>
>>>www.mysite.com/content/home/o/76429
>>>
>>>It works fine but if I point it to
>>>
>>>www.mysite.com <http://www.mysite.com/>
>>>
>>>my separate redirector filter will identify this as a URL that needs
>>>forwarding and so it performs a forward via the dispatcher to
>>>www.mysite.com/content/home/o/76429.
>>>
>>>content/home/o/76429 is indeed the servlet path in the request that the
>>>Wicket filter receives but yet it feels the need to do a redirect to the
>>>incorrect URL it derives above then attempts to service that incorrect
>>>redirect request which fails as it is not in the correct format.
>>>
>>>
>>>________________________________
>>>
>>>From: Chris Colman [mailto:[email protected]]
>>>Sent: Friday, 7 October 2011 6:15 PM
>>>To: [email protected]
>>>Subject: Forwarding in 1.5 not working like in 1.4
>>>
>>>We have a separate filter set up to catch parameter-less domain name
>>>requests ( /* ) like:
>>>
>>>www.myurl.com <http://www.myurl.com/>
>>>
>>>and forward them to a bookmarkable home page like:
>>>
>>>www.myurl.com/content/home/o/123
>>>
>>>The extra o/123 is an organization discriminator name/value pair and is
>>>read in by the home page as a parameter.
>>>
>>>The use of a forward means that the address in the user's browser remains
>>>as www.myurl.com <http://www.myurl.com/>  but the actual page rendered is
>>>www.myurl.com/content/home/o/123
>>>
>>>The page mount looks like:
>>>
>>>          pageParametersEncoder = new UrlPathPageParametersEncoder();
>>>
>>>          mount(new MountedMapper("/content/home", HomePage.class,
>>>pageParametersEncoder));
>>>
>>>The code used for the forward inside our separate redirector filter is:
>>>
>>>          RequestDispatcher rd =
>>>req.getRequestDispatcher("/content/home/o/123");
>>>          rd.forward(req, res);
>>>
>>>          This filter then does not chain to the next filter so that the
>>>servlet engine can re-request with the forwarded URL.
>>>
>>>In 1.4 the wicket filter then services this forward request and renders
>>the
>>>page without a problem.
>>>
>>>In 1.5 this no longer works and I've tried many different ideas to get it
>>>working but it just doesn't seem to want to work properly.
>>>
>>>Somehow wicket attempts to render a page with a url of:
>>>
>>>www.myurl.com/123
>>>
>>>In other words the /content/home/o/ part has been stripped from the
>>>"forward to" URL.
>>>
>>>Debugging shows that the wicket request does indeed have the full uri:
>>>
>>>/content/home/o/123 <http://www.myurl.com/content/home/o/123>
>>>
>>>
>>>Any ideas what might be causing this?
>>>
>>>
>>>Yours sincerely,
>>>
>>>Chris Colman
>>>
>>>Pagebloom Team Leader,
>>>Step Ahead Software
>>>
>>>
>>>pagebloom - your business & your website growing together
>>>
>>>Sydney:           (+61 2) 9656 1278     Canberra: (+61 2) 6100 2120
>>>Email: [email protected] <mailto://[email protected]>
>>>Website:
>>>http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
>>>http://develop.stepaheadsoftware.com
>>><blocked::http://develop.stepaheadsoftware.com/>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to