Re: No 404 error is raised
Alex, as a workaround for almost the same issue I wrote this module: https://gist.github.com/3360101 It accomplishes three things: *) The default PageRenderDispatcher will skip Index pages. *) There is a new Dispatcher that will deal with the Index pages but it's configured after all the other dispatchers with after:* *) This new Dispatcher mandates that Index pages MUST NOT have a context. It forces EMPTY_CONTEXT on the Index pages. if you feel adventurous enough you can try it out and see if it fits your needs. I hope it helps Alejandro. On Wed, Sep 5, 2012 at 10:30 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Wed, Sep 5, 2012 at 1:22 PM, Alex Kotchnev akoch...@gmail.com wrote: This is quite a pesky problem. I tried going w/ the Start page approach mentioned in https://issues.apache.org/jira/browse/TAP5-879?attachmentOrder=desc ; however, as it appears the approach w/ Start pages no longer works (and they're deprecated anyway). It certainly is a surprise when the app never returns a 404 and always sends the user to the index page, but it's not a terrible surprise as the user gets to see a real page with content . Try tapestry-routing (http://tynamo.org/tapestry-routing+guide) with a Home page and @Route(/) rule plus no Index pages. That should give you the expected behavior. Kalle On Mon, Aug 20, 2012 at 9:36 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Mon, 20 Aug 2012 19:18:30 -0300, Howard Lewis Ship hls...@gmail.com wrote: I'm considering a change for Tapestry 5.4 where the ValueEncoder, responsible for converting portions of the URL into the page activation context, will have a new method that defines what it expects to see in its portion of the URL, in terms of a regular expression. Shouldn't we have a different encoder specific for URLs (with ValueEncoder as a fallback) and leave ValueEncoder more focused on dealing with form fields? This way, we can handle this validation without changing ValueEncoder. -- Thiago H. de Paula Figueiredo --**--**- To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.orgusers-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
This is quite a pesky problem. I tried going w/ the Start page approach mentioned in https://issues.apache.org/jira/browse/TAP5-879?attachmentOrder=desc ; however, as it appears the approach w/ Start pages no longer works (and they're deprecated anyway). It certainly is a surprise when the app never returns a 404 and always sends the user to the index page, but it's not a terrible surprise as the user gets to see a real page with content . I'll look forward to the 5.4 solution. Cheers, Alex K On Mon, Aug 20, 2012 at 9:36 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Mon, 20 Aug 2012 19:18:30 -0300, Howard Lewis Ship hls...@gmail.com wrote: I'm considering a change for Tapestry 5.4 where the ValueEncoder, responsible for converting portions of the URL into the page activation context, will have a new method that defines what it expects to see in its portion of the URL, in terms of a regular expression. Shouldn't we have a different encoder specific for URLs (with ValueEncoder as a fallback) and leave ValueEncoder more focused on dealing with form fields? This way, we can handle this validation without changing ValueEncoder. -- Thiago H. de Paula Figueiredo --**--**- To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.orgusers-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
On Wed, Sep 5, 2012 at 1:22 PM, Alex Kotchnev akoch...@gmail.com wrote: This is quite a pesky problem. I tried going w/ the Start page approach mentioned in https://issues.apache.org/jira/browse/TAP5-879?attachmentOrder=desc ; however, as it appears the approach w/ Start pages no longer works (and they're deprecated anyway). It certainly is a surprise when the app never returns a 404 and always sends the user to the index page, but it's not a terrible surprise as the user gets to see a real page with content . Try tapestry-routing (http://tynamo.org/tapestry-routing+guide) with a Home page and @Route(/) rule plus no Index pages. That should give you the expected behavior. Kalle On Mon, Aug 20, 2012 at 9:36 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Mon, 20 Aug 2012 19:18:30 -0300, Howard Lewis Ship hls...@gmail.com wrote: I'm considering a change for Tapestry 5.4 where the ValueEncoder, responsible for converting portions of the URL into the page activation context, will have a new method that defines what it expects to see in its portion of the URL, in terms of a regular expression. Shouldn't we have a different encoder specific for URLs (with ValueEncoder as a fallback) and leave ValueEncoder more focused on dealing with form fields? This way, we can handle this validation without changing ValueEncoder. -- Thiago H. de Paula Figueiredo --**--**- To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.orgusers-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
Well I got it to work by combining Info from here:
http://thread.gmane.org/gmane.comp.java.tapestry.user/64654/focus=64655
and here:
http://tapestry.apache.org/error-page-recipe.html
Index.java page:
Object onActivate(Object obj) {
return Error404.class;
}
Error404.java:
public class Error404
{
@Property
@Inject
@Symbol(SymbolConstants.PRODUCTION_MODE)
private boolean productionMode;
@Inject
private RequestGlobals requestGlobals;
public void setupRender() {
requestGlobals.getHTTPServletResponse().setStatus(HttpServletResponse.SC_NOT_FOUND);
}
}
TML:
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_3.xsd;
head
titleResource not found./title
/head
body
Page or resource not found.
br/
t:if test=! productionMode
http://bit.ly/Rcfayf
/t:if
/body
/html
Cheers
Russell John-Baptiste
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p5715638.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
I'm considering a change for Tapestry 5.4 where the ValueEncoder,
responsible for converting portions of the URL into the page
activation context, will have a new method that defines what it
expects to see in its portion of the URL, in terms of a regular
expression.
Thus a URL such as:
/account/1234
would match when when the type of value for the page activation
context is a number, or an entity with a numeric primary key.
A URL like
/account/style.css
The style.css would not match the numeric regular expression, and
Tapestry would continue its search for a matching activation event
handler and, failing that, a matching page.
This would take a bit of work; when processing event handlers for
pages, it will be necessary to determine the type of each field, find
the ValueEncoder for that type, etc.
I should be able to do this as ValueEncoder2, and have some simple
smarts about upgrading ValueEncoder to ValueEncoder2.
On Mon, Aug 20, 2012 at 2:42 PM, RJB III rjb...@yahoo.com wrote:
Well I got it to work by combining Info from here:
http://thread.gmane.org/gmane.comp.java.tapestry.user/64654/focus=64655
and here:
http://tapestry.apache.org/error-page-recipe.html
Index.java page:
Object onActivate(Object obj) {
return Error404.class;
}
Error404.java:
public class Error404
{
@Property
@Inject
@Symbol(SymbolConstants.PRODUCTION_MODE)
private boolean productionMode;
@Inject
private RequestGlobals requestGlobals;
public void setupRender() {
requestGlobals.getHTTPServletResponse().setStatus(HttpServletResponse.SC_NOT_FOUND);
}
}
TML:
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_3.xsd;
head
titleResource not found./title
/head
body
Page or resource not found.
br/
t:if test=! productionMode
http://bit.ly/Rcfayf
/t:if
/body
/html
Cheers
Russell John-Baptiste
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p5715638.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
On Mon, 20 Aug 2012 19:18:30 -0300, Howard Lewis Ship hls...@gmail.com wrote: I'm considering a change for Tapestry 5.4 where the ValueEncoder, responsible for converting portions of the URL into the page activation context, will have a new method that defines what it expects to see in its portion of the URL, in terms of a regular expression. Shouldn't we have a different encoder specific for URLs (with ValueEncoder as a fallback) and leave ValueEncoder more focused on dealing with form fields? This way, we can handle this validation without changing ValueEncoder. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
I think the best approach is to leverage the ignored paths mechanism. That is early in the response processing pipeline, and will have a good chance to ignore what should be ignored. Can somebody please explain how I can work around this for the novice here? :) Help very appreciated! -- View this message in context: http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p3214941.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
On Thu, Oct 14, 2010 at 11:16 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: As the JIRA ticket says, this is expected behavior. In your case, /blabla is considered a request to / (Index) with one activation context parameter 'blabla' as there's no page named 'blabla'. Correct and acknowledged but I personally find it somehow tricky to understand for a novice and is perfectly legal to want it to return 404 error. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
Hmm... that's true, the Start page is broken as well in 5.2 - you can't get it to return 404s anymore using Start page the same way as in 5.1. That's a showstopper for upgrading one of my apps to 5.2. I bet there's a way to restore the old behavior, anyone solved this already? Kalle On Fri, Oct 15, 2010 at 12:19 AM, Massimo Lusetti mluse...@gmail.com wrote: On Thu, Oct 14, 2010 at 11:16 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: As the JIRA ticket says, this is expected behavior. In your case, /blabla is considered a request to / (Index) with one activation context parameter 'blabla' as there's no page named 'blabla'. Correct and acknowledged but I personally find it somehow tricky to understand for a novice and is perfectly legal to want it to return 404 error. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
As the JIRA ticket says, this is expected behavior. In your case, /blabla is considered a request to / (Index) with one activation context parameter 'blabla' as there's no page named 'blabla'. I was just wondering why the ticket is still 'Open' and has a patch that apparently was never actually used... Hmm... that's true, the Start page is broken as well in 5.2 - you can't get it to return 404s anymore using Start page the same way as in 5.1. So the solution should be renaming it 'Start.tml' (could be documented somewhere *g*)? I used 5.2 straight away without 5.1 because I needed the Spring 3 support. Could you open a JIRA issue then? - it might be better if an experienced tapestry user opens it :) Cheers! -- View this message in context: http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p3213305.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
Hi,
we've been running into this also.
Fixed this by creating a custom 404 page and setting this as the default start
page.
FourOhFour.tml
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_0_0.xsd;
head
meta http-equiv=Refresh content=0; url=${starturl} /
/head
body
Page not found
/body
/html
And FourOhFour.java
import org.apache.tapestry5.Link;
import org.apache.tapestry5.annotations.AfterRender;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.apache.tapestry5.services.PageRenderLinkSource;
import org.apache.tapestry5.services.Response;
public class FourOhFour
{
@Inject
private Response response;
@Inject
private PageRenderLinkSource resources;
@AfterRender
public void afterRender()
{
response.setStatus(404);
}
public Link getStartURL()
{
return resources.createPageRenderLink(SomeOtherStartPage.class);
}
}
And in AppModule we set the default start page to our FourOhFour page
public static void contributeApplicationDefaults(
MappedConfigurationString, String
configuration)
{
configuration.add(SymbolConstants.START_PAGE_NAME,
FourOhFour);
}
Hope this helps.
M.
Am 15.10.2010 um 10:09 schrieb stephanos:
As the JIRA ticket says, this is expected behavior. In your case, /blabla
is considered a request to / (Index) with one activation context parameter
'blabla' as there's no page named 'blabla'.
I was just wondering why the ticket is still 'Open' and has a patch that
apparently was never actually used...
Hmm... that's true, the Start page is broken as well in 5.2 - you
can't get it to return 404s anymore using Start page the same way as
in 5.1.
So the solution should be renaming it 'Start.tml' (could be documented
somewhere *g*)? I used 5.2 straight away without 5.1 because I needed the
Spring 3 support. Could you open a JIRA issue then? - it might be better if
an experienced tapestry user opens it :)
Cheers!
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p3213305.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
This is a tricky error to fix. At issue is the fact that the page
activation context can, theoretically, look like anything: strings,
numbers, path-like-stuff, whatever. The layers of conversion from the
path in the URL to, ultimately, numbers or entity objects happens
very, very late. In theory, the number of values, and their type, may
vary from request to request (in practice, this is highly doubtful!).
By the time Tapestry gets to the point where it can figure out if the
page activation context is valid, it's actually past the point where
it has committed to handling the request.
I can imagine fixing this by adding a new event to the page lifecycle
that allows the page to look at the event context and decide whether
to continue. However, this would either have to be kludged into some
existing place it doesn't belong, or will require some changes to
public APIs.
I think the best approach is to leverage the ignored paths mechanism.
That is early in the response processing pipeline, and will have a
good chance to ignore what should be ignored.
On Fri, Oct 15, 2010 at 1:27 AM, Moritz Gmelin moritz.gme...@gmx.de wrote:
Hi,
we've been running into this also.
Fixed this by creating a custom 404 page and setting this as the default
start page.
FourOhFour.tml
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_0_0.xsd;
head
meta http-equiv=Refresh content=0; url=${starturl} /
/head
body
Page not found
/body
/html
And FourOhFour.java
import org.apache.tapestry5.Link;
import org.apache.tapestry5.annotations.AfterRender;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.apache.tapestry5.services.PageRenderLinkSource;
import org.apache.tapestry5.services.Response;
public class FourOhFour
{
�...@inject
private Response response;
�...@inject
private PageRenderLinkSource resources;
�...@afterrender
public void afterRender()
{
response.setStatus(404);
}
public Link getStartURL()
{
return
resources.createPageRenderLink(SomeOtherStartPage.class);
}
}
And in AppModule we set the default start page to our FourOhFour page
public static void contributeApplicationDefaults(
MappedConfigurationString, String
configuration)
{
configuration.add(SymbolConstants.START_PAGE_NAME,
FourOhFour);
}
Hope this helps.
M.
Am 15.10.2010 um 10:09 schrieb stephanos:
As the JIRA ticket says, this is expected behavior. In your case, /blabla
is considered a request to / (Index) with one activation context parameter
'blabla' as there's no page named 'blabla'.
I was just wondering why the ticket is still 'Open' and has a patch that
apparently was never actually used...
Hmm... that's true, the Start page is broken as well in 5.2 - you
can't get it to return 404s anymore using Start page the same way as
in 5.1.
So the solution should be renaming it 'Start.tml' (could be documented
somewhere *g*)? I used 5.2 straight away without 5.1 because I needed the
Spring 3 support. Could you open a JIRA issue then? - it might be better if
an experienced tapestry user opens it :)
Cheers!
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-tp3212773p3213305.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No 404 error is raised
On Thu, 14 Oct 2010 17:17:49 -0300, stephanos stephan.beh...@gmail.com wrote: Hi guys, Hi! I'm making my first steps with Tapestry 5.2 and find one thing very peculiar: All requests seem to go to the Index page (Index.tml in 'root') by default - even if the path does not exist! Example with page Index.tml and Login.tml: / - Index /blabla - Index /login - Login /login2 - Index As the JIRA ticket says, this is expected behavior. In your case, /blabla is considered a request to / (Index) with one activation context parameter 'blabla' as there's no page named 'blabla'. -- Thiago H. de Paula Figueiredo Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate Coordenador e professor da Especialização em Engenharia de Software com Ênfase em Java da Faculdade Pitágoras http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
