RE: Forwarding in 1.5 not working like in 1.4
I've just noticed that some of the .js resources seem to be loading from different addresses. I'm using 1.5.2 with the UrlRenderer patch to fix the forwarding issue. Depending on the page it appears like the same .js is requested at two different URLs. Presumably the browser will perform a download each time as it will cache each differently according to their different URLs. servlet path: /content/home/wicket/resource/org.apache.wicket.markup.html.WicketEventR eference/wicket-event-ver-131926433.js /wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wick et-event-ver-131926433.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Forwarding in 1.5 not working like in 1.4
this is a general problem with forwarding. instead of forwarding why dont you just 302? -igor On Fri, Oct 21, 2011 at 11:33 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I've just noticed that some of the .js resources seem to be loading from different addresses. I'm using 1.5.2 with the UrlRenderer patch to fix the forwarding issue. Depending on the page it appears like the same .js is requested at two different URLs. Presumably the browser will perform a download each time as it will cache each differently according to their different URLs. servlet path: /content/home/wicket/resource/org.apache.wicket.markup.html.WicketEventR eference/wicket-event-ver-131926433.js /wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wick et-event-ver-131926433.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Forwarding in 1.5 not working like in 1.4
The reason I don't do a 302 is I don't want the browser's address bar to change + for SEO. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Saturday, 22 October 2011 5:52 PM To: users@wicket.apache.org Subject: Re: Forwarding in 1.5 not working like in 1.4 this is a general problem with forwarding. instead of forwarding why dont you just 302? -igor On Fri, Oct 21, 2011 at 11:33 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I've just noticed that some of the .js resources seem to be loading from different addresses. I'm using 1.5.2 with the UrlRenderer patch to fix the forwarding issue. Depending on the page it appears like the same .js is requested at two different URLs. Presumably the browser will perform a download each time as it will cache each differently according to their different URLs. servlet path: /content/home/wicket/resource/org.apache.wicket.markup.html.WicketEventR eference/wicket-event-ver-131926433.js /wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wick et-event-ver-131926433.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Forwarding in 1.5 not working like in 1.4 [Fixed - was using older 1.5 jars]
After creating a QuickStart and not being able to reproduce the problem I
discovered that my original app was linking with an earlier 1.5 snapshot. Once
I linked with the latest snapshot jars it magically worked - yeehah!
-Original Message-
From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
Sent: Monday, 10 October 2011 9:57 AM
To: users@wicket.apache.org
Subject: RE: Forwarding in 1.5 not working like in 1.4
Will do.
Chris
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Sunday, 9 October 2011 6:07 PM
To: users@wicket.apache.org
Subject: Re: Forwarding in 1.5 not working like in 1.4
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
chr...@stepaheadsoftware.com 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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:52 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:28 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
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
RE: Forwarding in 1.5 not working like in 1.4
Will do.
Chris
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Sunday, 9 October 2011 6:07 PM
To: users@wicket.apache.org
Subject: Re: Forwarding in 1.5 not working like in 1.4
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
chr...@stepaheadsoftware.com 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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:52 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:28 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
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:
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:chr...@stepaheadsoftware.com]
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
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: chr...@stepahead.com.au mailto://chr...@stepahead.com.au
Website:
http://www.pagebloom.com blocked::http://www.pagebloom.com/
http://develop.stepaheadsoftware.com
blocked::http://develop.stepaheadsoftware.com/
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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:28 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
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: chr...@stepahead.com.au mailto://chr...@stepahead.com.au
Website:
http://www.pagebloom.com blocked::http://www.pagebloom.com/
http://develop.stepaheadsoftware.com
blocked::http://develop.stepaheadsoftware.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Forwarding in 1.5 not working like in 1.4
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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:52 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Saturday, 8 October 2011 10:28 PM
To: users@wicket.apache.org
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:chr...@stepaheadsoftware.com]
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
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: chr...@stepahead.com.au mailto://chr...@stepahead.com.au
Website:
http://www.pagebloom.com blocked::http://www.pagebloom.com/
http://develop.stepaheadsoftware.com
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: chr...@stepahead.com.au mailto://chr...@stepahead.com.au Website: http://www.pagebloom.com blocked::http://www.pagebloom.com/ http://develop.stepaheadsoftware.com blocked::http://develop.stepaheadsoftware.com/
