Re: Final call for TAP5-2070
Any other though on this ? On Wed, Jul 31, 2013 at 7:56 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: Already voted :) On Jul 31, 2013, at 12:30 PM, Massimo Lusetti mluse...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: As long it's a 404 in both production and development mode I'm fine with that. BTW anyone interested in this could go to the issue page on Jira and vote for it. -- Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Massimo Lusetti
Re: Final call for TAP5-2070
Big +1 for me. I currently use the following code in the index page to work
around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, Resource not found.);
21 }
On Jul 31, 2013, at 10:14 AM, Massimo Lusetti mluse...@gmail.com wrote:
Hi devs,
I would like to have
https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
go to beta stage.
I mainly want to decide if the current behavior is acceptable for the
majority or we need to change it, then we can discuss on the implementation.
Please comment.
--
Massimo Lusetti
Re: Final call for TAP5-2070
+1
On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
Big +1 for me. I currently use the following code in the index page to
work around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, Resource not found.);
21 }
On Jul 31, 2013, at 10:14 AM, Massimo Lusetti mluse...@gmail.com wrote:
Hi devs,
I would like to have
https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
go to beta stage.
I mainly want to decide if the current behavior is acceptable for the
majority or we need to change it, then we can discuss on the
implementation.
Please comment.
--
Massimo Lusetti
Re: Final call for TAP5-2070
Could this be a case where we want one behavior in development (a Tapestry
error) and another in production (a 404 status)?
On Wed, Jul 31, 2013 at 8:38 AM, Dimitris Zenios
dimitris.zen...@gmail.comwrote:
+1
On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak lpri...@hope.nyc.ny.us
wrote:
Big +1 for me. I currently use the following code in the index page to
work around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, Resource not found.);
21 }
On Jul 31, 2013, at 10:14 AM, Massimo Lusetti mluse...@gmail.com
wrote:
Hi devs,
I would like to have
https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
go to beta stage.
I mainly want to decide if the current behavior is acceptable for the
majority or we need to change it, then we can discuss on the
implementation.
Please comment.
--
Massimo Lusetti
--
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
Re: Final call for TAP5-2070
I would say no.
The behavior in production.and development mode differences in general is a bad
idea. This will preclude valid testing in development.
On Jul 31, 2013, at 10:51 AM, Howard Lewis Ship hls...@gmail.com wrote:
Could this be a case where we want one behavior in development (a Tapestry
error) and another in production (a 404 status)?
On Wed, Jul 31, 2013 at 8:38 AM, Dimitris Zenios
dimitris.zen...@gmail.comwrote:
+1
On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak lpri...@hope.nyc.ny.us
wrote:
Big +1 for me. I currently use the following code in the index page to
work around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, Resource not found.);
21 }
On Jul 31, 2013, at 10:14 AM, Massimo Lusetti mluse...@gmail.com
wrote:
Hi devs,
I would like to have
https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
go to beta stage.
I mainly want to decide if the current behavior is acceptable for the
majority or we need to change it, then we can discuss on the
implementation.
Please comment.
--
Massimo Lusetti
--
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: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: I would say no. The behavior in production.and development mode differences in general is a bad idea. This will preclude valid testing in development. It would be the same situation of the ExceptionReport page and it would go hand to hand with the excellent feedback given by the whole framework, let's read this way: Hey dev you're accessing page X which doesn't declare an activation context Y so this is considered an error and will result in a 404 within production -- Massimo Lusetti
Re: Final call for TAP5-2070
You can have your cake and eat it! It's valid for a 404 response to have a body and a content type. On 31 Jul 2013 17:07, Massimo Lusetti mluse...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: I would say no. The behavior in production.and development mode differences in general is a bad idea. This will preclude valid testing in development. It would be the same situation of the ExceptionReport page and it would go hand to hand with the excellent feedback given by the whole framework, let's read this way: Hey dev you're accessing page X which doesn't declare an activation context Y so this is considered an error and will result in a 404 within production -- Massimo Lusetti
Re: Final call for TAP5-2070
As I see its not the same at all. The exception report behavior is the same only the text is different. Here you are proposing completely different error and behavior in production and in development. Intent is not the same. What if someone intercepts all exceptions and emails production support? Other custom behavior would all be broken. On Jul 31, 2013, at 11:07 AM, Massimo Lusetti mluse...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: I would say no. The behavior in production.and development mode differences in general is a bad idea. This will preclude valid testing in development. It would be the same situation of the ExceptionReport page and it would go hand to hand with the excellent feedback given by the whole framework, let's read this way: Hey dev you're accessing page X which doesn't declare an activation context Y so this is considered an error and will result in a 404 within production -- Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
On Wed, Jul 31, 2013 at 6:31 PM, Lance Java lance.j...@googlemail.comwrote: You can have your cake and eat it! It's valid for a 404 response to have a body and a content type. Fine, let's put it this way: In dev mode is valuable to have and explanation of what happened while in prod mod simply a 404 so it could be caught by the servlet error dispatcher, the one configured in web.xml ? -- Massimo Lusetti
Re: Final call for TAP5-2070
As long it's a 404 in both production and development mode I'm fine with that. On Jul 31, 2013, at 11:42 AM, Massimo Lusetti mluse...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:31 PM, Lance Java lance.j...@googlemail.comwrote: You can have your cake and eat it! It's valid for a 404 response to have a body and a content type. Fine, let's put it this way: In dev mode is valuable to have and explanation of what happened while in prod mod simply a 404 so it could be caught by the servlet error dispatcher, the one configured in web.xml ? -- Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: As long it's a 404 in both production and development mode I'm fine with that. BTW anyone interested in this could go to the issue page on Jira and vote for it. -- Massimo Lusetti
Re: Final call for TAP5-2070
Already voted :) On Jul 31, 2013, at 12:30 PM, Massimo Lusetti mluse...@gmail.com wrote: On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: As long it's a 404 in both production and development mode I'm fine with that. BTW anyone interested in this could go to the issue page on Jira and vote for it. -- Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
