A quick fix was to throw a RestartResponseException which renders our
404 page (which sets the correct headers).
However, this seems to go against loose coupling: the product detail
page should throw a 404, and not be bothered with the handling of the
404 by the app or appserver.
So is there a cleaner way to handle this that anyone is aware of?
Op 29-9-2011 14:28, schreef Bas Gooren:
We have the following situation:
The wicket filter is configured to handle 404 responses (by a page
mounted at /404), this is set in web.xml;
We have a stateless (product) page at /shop/product, which contains a
Stateless form which offers the customer the possibility to order.
Some crawlers have apparently indexed the form's action url, eg:
/shop/product/1671/california-sun?wicket:interface=:0:orderform::IFormSubmitListener::
Now in the constructor of the product page we check if the product
exists and is visible. If not, we throw a new
AbortWithWebErrorCodeException( 404 );
This leads to a runtime exception in some cases:
WicketMessage: unable to find component with path orderform on
stateless page [Page class = com.x.y.z.Error404Page, id = 0, version =
0] it could be that the component is inside a repeater make your
component return false in getStatelessHint()
It appears that wicket (1.4.3 in this case) handles the 404, and then
tries to resolve the component path, which is no longer valid, since
we are on the 404 page.
Any ideas how to fix this? We don't want to redirect to another page,
it's important that we send a 404 + friendly page when the product
cannot be shown.
Sebastian