You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kalle Korhonen <ka...@gmail.com> on 2010/07/05 01:05:46 UTC
Using PageResponseRenderer.render() in T5.2?
(Related to Tynamo's tapestry-security,
http://tynamo.org/tapestry-security+guide)
A custom exception handler added as an advice for the default one
wants to handle some specific type of exceptions and proceeds to call
PageResponseRenderer.render() in those cases. This works without
issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
"org.apache.tapestry5.ioc.internal.util.TapestryException: The
identity of the active page for this request has not yet been
established". To fix the issue, I can call the newly added
RequestGlobabls.storeActivePageName(String pageName) before call to
render(). While it's an easy fix, it'd be nicer if
PageResponseRenderer.render() would just do that internally. Is there
some reason why this would be a bad idea?
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jul 27, 2010 at 2:12 PM, Christophe Cordenier
<ch...@gmail.com> wrote:
> Right, not being able to use form component in exception page is a problem.
> But i still believe that using a redirect or a send error better suits for
> security concerns. Also, active page is also used to identify loopback URL
> that decides whether or not to reset page on loopback... That's why i have
> doubts to change it in the PageResponseRenderer
> Am still looking for the best solution
Ok, thanks for the explanation and all the effort you've put into
this. Saw your other email on this on the dev list as well - I don't
think you need to specifically worry about library incompatibility, at
least in this case - I can easily hack up something together for now
and refactor later.
Kalle
>
> 2010/7/27 Kalle Korhonen <ka...@gmail.com>
>
>> On Tue, Jul 27, 2010 at 8:05 AM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
>> > 2010/7/27 Kalle Korhonen <ka...@gmail.com>
>> >> Very good, that's what I thought. Makes sense now why calling it in
>> >> PageResponseRender may not necessarily be the right place but there
>> >> doesn't seem to be a lot of wiggle room for this case. Well I trust
>> >> you to figure out something better than I could :)
>> >>
>> > To be complete, my opinion is that you should set it in your API since
>> you
>> > are doing something specific for multiple Tapestry version support, my
>> worry
>> > is that in your case you depend on the API to do so...
>>
>> Sorry, not sure if I follow. Regardless of the multiple Tapestry
>> version support, I can certainly fix it in the library myself now but
>> are saying that the general case (what if the exception page has a
>> form) is invalid? One could just claim it's a limitation of the
>> framework but why?
>>
>> Kalle
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
Right, not being able to use form component in exception page is a problem.
But i still believe that using a redirect or a send error better suits for
security concerns. Also, active page is also used to identify loopback URL
that decides whether or not to reset page on loopback... That's why i have
doubts to change it in the PageResponseRenderer
Am still looking for the best solution
2010/7/27 Kalle Korhonen <ka...@gmail.com>
> On Tue, Jul 27, 2010 at 8:05 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > 2010/7/27 Kalle Korhonen <ka...@gmail.com>
> >> Very good, that's what I thought. Makes sense now why calling it in
> >> PageResponseRender may not necessarily be the right place but there
> >> doesn't seem to be a lot of wiggle room for this case. Well I trust
> >> you to figure out something better than I could :)
> >>
> > To be complete, my opinion is that you should set it in your API since
> you
> > are doing something specific for multiple Tapestry version support, my
> worry
> > is that in your case you depend on the API to do so...
>
> Sorry, not sure if I follow. Regardless of the multiple Tapestry
> version support, I can certainly fix it in the library myself now but
> are saying that the general case (what if the exception page has a
> form) is invalid? One could just claim it's a limitation of the
> framework but why?
>
> Kalle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jul 27, 2010 at 8:05 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> 2010/7/27 Kalle Korhonen <ka...@gmail.com>
>> Very good, that's what I thought. Makes sense now why calling it in
>> PageResponseRender may not necessarily be the right place but there
>> doesn't seem to be a lot of wiggle room for this case. Well I trust
>> you to figure out something better than I could :)
>>
> To be complete, my opinion is that you should set it in your API since you
> are doing something specific for multiple Tapestry version support, my worry
> is that in your case you depend on the API to do so...
Sorry, not sure if I follow. Regardless of the multiple Tapestry
version support, I can certainly fix it in the library myself now but
are saying that the general case (what if the exception page has a
form) is invalid? One could just claim it's a limitation of the
framework but why?
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
2010/7/27 Kalle Korhonen <ka...@gmail.com>
> On Mon, Jul 26, 2010 at 11:48 PM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
> >> SecurityFilter is a ComponentRequestFilter. If I contribute it right
> >> after "InitializeActivePageName", the fairly comprehensive integration
> >> tests for the module pass so it seems that would do it. Should have
> >> found that out and tried it before myself. But wouldn't the wrong page
> >> be stored as the active page in this case or does it not matter?
> >>
> > Right it matters : you will not be able to pre-allocate form control
> > names... I have to look deeper to see where storeActivePageName() should
> be
> > called to work properly with every type of request...
>
> Very good, that's what I thought. Makes sense now why calling it in
> PageResponseRender may not necessarily be the right place but there
> doesn't seem to be a lot of wiggle room for this case. Well I trust
> you to figure out something better than I could :)
>
To be complete, my opinion is that you should set it in your API since you
are doing something specific for multiple Tapestry version support, my worry
is that in your case you depend on the API to do so...
>
> Thanks to Ville for the symbol version tip!
>
> Kalle
>
>
> >> This is not directly related to the issue, but assuming the above
> >> solution is the right way to go about it and given that
> >> InitializeActivePageName didn't exist in T5.1, what's the best way for
> >> checking the version of the core library at runtime (so I can
> >> contribute it differently depending on the version)?
> >>
> >> Kalle
> >>
> >>
> >> >> > Actually, i am not against applying your patch, but as
> >> >> PageResponseRenderer
> >> >> > is internal, as a new committer i am definitely cautious in what i
> am
> >> >> doing
> >> >> > and committing ;)
> >> >>
> >> >> No worries, I fully understand where you are coming from. The code
> >> >> worked as is for T5.1 and I already experimentally modified it to
> call
> >> >> storeActivePageName() from outside just to verify that'd be enough
> for
> >> >> T5.2. So it's not a matter of making it work, but making it work the
> >> >> right way. Although we both may end up spending more time on it this
> >> >> way, I much prefer spending my resources on validating the concept
> >> >> than just hacking it in.
> >> >>
> >> >> So in the above case, we don't really want to replace the
> >> >> RequestExceptionHandler as handling the non-security related
> >> >> exceptions are delegated back to the original, but if somebody
> >> >> replaces the DefaultRequestExceptionHandler with one that contains a
> >> >> form on it, it'd throw an exception as well (just putting together
> >> >> what you said and reading the code), right? Hopefully that proves the
> >> >> need for the fix.
> >> >>
> >> >> Kalle
> >> >>
> >> >>
> >> >> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
> >> >> >
> >> >> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
> >> >> >> <ch...@gmail.com> wrote:
> >> >> >> > I am currently working on this JIRA, i have seen that the
> >> >> >> getActivatePage()
> >> >> >> > is only called to pre allocate names in Form component so it
> should
> >> >> have.
> >> >> >> So
> >> >> >> > i guess the page you are returning contains a Form.
> >> >> >>
> >> >> >> Right and thanks so much Christophe for taking a look at the
> issue.
> >> >> >>
> >> >> >> > Despite it sound right that PageResponseRenderer should set the
> >> active
> >> >> >> page,
> >> >> >> > don't you think that in case of a security exception it would be
> >> >> easier
> >> >> >> to
> >> >> >> > send an HTTP error and let the application developer use
> standard
> >> >> web.xml
> >> >> >> > request dispatching to configure the page to display ?
> >> >> >>
> >> >> >> Specifically in the case of security exception, no, I don't think
> >> >> >> that'd be easier. While it's an option, I don't see what the
> >> advantage
> >> >> >> would be. The exception handler in tapestry-security catches the
> >> >> >> exception, sets the error code and renders the configured page.
> >> >> >> Configuring the page somewhere else (in standard web.xml) seems to
> me
> >> >> >> like an unnecessary complication compared to contributing
> >> >> >> configuration.
> >> >> >>
> >> >> >> Security exception aside, in the general case http error codes
> alone
> >> >> >> wouldn't be enough to differentiate all the different error cases.
> >> I'm
> >> >> >> not strongly against exploring alternatives, but it makes sense to
> me
> >> >> >> that PageResponseRenderer would set the active page and I don't
> see
> >> >> >> any disadvantages in doing so, do you?
> >> >> >>
> >> >> >> Kalle
> >> >> >>
> >> >> >>
> >> >> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
> >> >> >> >> Pretty please, any committer? It's a one-liner to fix
> >> >> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch
> is
> >> >> >> >> attached.
> >> >> >> >>
> >> >> >> >> Kalle
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <
> pierce@paceap.com
> >> >
> >> >> >> wrote:
> >> >> >> >> >
> >> >> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> >> >> >> >> >
> >> >> >> >> >> Sorry to be a pest, but how could I find a champion to apply
> >> the
> >> >> >> patch
> >> >> >> >> >> for TAP5-1201? I understand Howard's busy and his time is
> >> probably
> >> >> >> >> >> better spent on bigger issues than this, but I hope that
> some
> >> >> other
> >> >> >> >> >> committer would be able to pick this up and apply the
> one-line
> >> >> change
> >> >> >> >> >> that would restore functionality that existed in T5.1. It's
> my
> >> >> >> >> >> understanding its perfectly safe to do as suggested so we
> can't
> >> go
> >> >> >> >> >> that far off even if somebody wants to refactor it later.
> >> >> >> >> >
> >> >> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail:
> users-unsubscribe@tapestry.apache.org
> >> >> >> >> > For additional commands, e-mail:
> users-help@tapestry.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> >> >> For additional commands, e-mail:
> users-help@tapestry.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Christophe Cordenier.
> >> >> >> >
> >> >> >> > Committer on Apache Tapestry 5
> >> >> >> > Co-creator of wooki @wookicentral.com
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Christophe Cordenier.
> >> >> >
> >> >> > Committer on Apache Tapestry 5
> >> >> > Co-creator of wooki @wookicentral.com
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Christophe Cordenier.
> >> >
> >> > Committer on Apache Tapestry 5
> >> > Co-creator of wooki @wookicentral.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Jul 26, 2010 at 11:48 PM, Christophe Cordenier
<ch...@gmail.com> wrote:
> 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> SecurityFilter is a ComponentRequestFilter. If I contribute it right
>> after "InitializeActivePageName", the fairly comprehensive integration
>> tests for the module pass so it seems that would do it. Should have
>> found that out and tried it before myself. But wouldn't the wrong page
>> be stored as the active page in this case or does it not matter?
>>
> Right it matters : you will not be able to pre-allocate form control
> names... I have to look deeper to see where storeActivePageName() should be
> called to work properly with every type of request...
Very good, that's what I thought. Makes sense now why calling it in
PageResponseRender may not necessarily be the right place but there
doesn't seem to be a lot of wiggle room for this case. Well I trust
you to figure out something better than I could :)
Thanks to Ville for the symbol version tip!
Kalle
>> This is not directly related to the issue, but assuming the above
>> solution is the right way to go about it and given that
>> InitializeActivePageName didn't exist in T5.1, what's the best way for
>> checking the version of the core library at runtime (so I can
>> contribute it differently depending on the version)?
>>
>> Kalle
>>
>>
>> >> > Actually, i am not against applying your patch, but as
>> >> PageResponseRenderer
>> >> > is internal, as a new committer i am definitely cautious in what i am
>> >> doing
>> >> > and committing ;)
>> >>
>> >> No worries, I fully understand where you are coming from. The code
>> >> worked as is for T5.1 and I already experimentally modified it to call
>> >> storeActivePageName() from outside just to verify that'd be enough for
>> >> T5.2. So it's not a matter of making it work, but making it work the
>> >> right way. Although we both may end up spending more time on it this
>> >> way, I much prefer spending my resources on validating the concept
>> >> than just hacking it in.
>> >>
>> >> So in the above case, we don't really want to replace the
>> >> RequestExceptionHandler as handling the non-security related
>> >> exceptions are delegated back to the original, but if somebody
>> >> replaces the DefaultRequestExceptionHandler with one that contains a
>> >> form on it, it'd throw an exception as well (just putting together
>> >> what you said and reading the code), right? Hopefully that proves the
>> >> need for the fix.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> >> >
>> >> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
>> >> >> <ch...@gmail.com> wrote:
>> >> >> > I am currently working on this JIRA, i have seen that the
>> >> >> getActivatePage()
>> >> >> > is only called to pre allocate names in Form component so it should
>> >> have.
>> >> >> So
>> >> >> > i guess the page you are returning contains a Form.
>> >> >>
>> >> >> Right and thanks so much Christophe for taking a look at the issue.
>> >> >>
>> >> >> > Despite it sound right that PageResponseRenderer should set the
>> active
>> >> >> page,
>> >> >> > don't you think that in case of a security exception it would be
>> >> easier
>> >> >> to
>> >> >> > send an HTTP error and let the application developer use standard
>> >> web.xml
>> >> >> > request dispatching to configure the page to display ?
>> >> >>
>> >> >> Specifically in the case of security exception, no, I don't think
>> >> >> that'd be easier. While it's an option, I don't see what the
>> advantage
>> >> >> would be. The exception handler in tapestry-security catches the
>> >> >> exception, sets the error code and renders the configured page.
>> >> >> Configuring the page somewhere else (in standard web.xml) seems to me
>> >> >> like an unnecessary complication compared to contributing
>> >> >> configuration.
>> >> >>
>> >> >> Security exception aside, in the general case http error codes alone
>> >> >> wouldn't be enough to differentiate all the different error cases.
>> I'm
>> >> >> not strongly against exploring alternatives, but it makes sense to me
>> >> >> that PageResponseRenderer would set the active page and I don't see
>> >> >> any disadvantages in doing so, do you?
>> >> >>
>> >> >> Kalle
>> >> >>
>> >> >>
>> >> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>> >> >> >> Pretty please, any committer? It's a one-liner to fix
>> >> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>> >> >> >> attached.
>> >> >> >>
>> >> >> >> Kalle
>> >> >> >>
>> >> >> >>
>> >> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pierce@paceap.com
>> >
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>> >> >> >> >
>> >> >> >> >> Sorry to be a pest, but how could I find a champion to apply
>> the
>> >> >> patch
>> >> >> >> >> for TAP5-1201? I understand Howard's busy and his time is
>> probably
>> >> >> >> >> better spent on bigger issues than this, but I hope that some
>> >> other
>> >> >> >> >> committer would be able to pick this up and apply the one-line
>> >> change
>> >> >> >> >> that would restore functionality that existed in T5.1. It's my
>> >> >> >> >> understanding its perfectly safe to do as suggested so we can't
>> go
>> >> >> >> >> that far off even if somebody wants to refactor it later.
>> >> >> >> >
>> >> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Christophe Cordenier.
>> >> >> >
>> >> >> > Committer on Apache Tapestry 5
>> >> >> > Co-creator of wooki @wookicentral.com
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Christophe Cordenier.
>> >> >
>> >> > Committer on Apache Tapestry 5
>> >> > Co-creator of wooki @wookicentral.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Committer on Apache Tapestry 5
>> > Co-creator of wooki @wookicentral.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Jul 26, 2010 at 11:48 PM, Christophe Cordenier
<ch...@gmail.com> wrote:
> 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> SecurityFilter is a ComponentRequestFilter. If I contribute it right
>> after "InitializeActivePageName", the fairly comprehensive integration
>> tests for the module pass so it seems that would do it. Should have
>> found that out and tried it before myself. But wouldn't the wrong page
>> be stored as the active page in this case or does it not matter?
>>
> Right it matters : you will not be able to pre-allocate form control
> names... I have to look deeper to see where storeActivePageName() should be
> called to work properly with every type of request...
Very good, that's what I thought. Makes sense now why calling it in
PageResponseRender may not necessarily be the right place but there
doesn't seem to be a lot of wiggle room for this case. Well I trust
you to figure out something better than I could :)
Thanks to Ville for the symbol version tip!
Kalle
>> This is not directly related to the issue, but assuming the above
>> solution is the right way to go about it and given that
>> InitializeActivePageName didn't exist in T5.1, what's the best way for
>> checking the version of the core library at runtime (so I can
>> contribute it differently depending on the version)?
>>
>> Kalle
>>
>>
>> >> > Actually, i am not against applying your patch, but as
>> >> PageResponseRenderer
>> >> > is internal, as a new committer i am definitely cautious in what i am
>> >> doing
>> >> > and committing ;)
>> >>
>> >> No worries, I fully understand where you are coming from. The code
>> >> worked as is for T5.1 and I already experimentally modified it to call
>> >> storeActivePageName() from outside just to verify that'd be enough for
>> >> T5.2. So it's not a matter of making it work, but making it work the
>> >> right way. Although we both may end up spending more time on it this
>> >> way, I much prefer spending my resources on validating the concept
>> >> than just hacking it in.
>> >>
>> >> So in the above case, we don't really want to replace the
>> >> RequestExceptionHandler as handling the non-security related
>> >> exceptions are delegated back to the original, but if somebody
>> >> replaces the DefaultRequestExceptionHandler with one that contains a
>> >> form on it, it'd throw an exception as well (just putting together
>> >> what you said and reading the code), right? Hopefully that proves the
>> >> need for the fix.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> >> >
>> >> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
>> >> >> <ch...@gmail.com> wrote:
>> >> >> > I am currently working on this JIRA, i have seen that the
>> >> >> getActivatePage()
>> >> >> > is only called to pre allocate names in Form component so it should
>> >> have.
>> >> >> So
>> >> >> > i guess the page you are returning contains a Form.
>> >> >>
>> >> >> Right and thanks so much Christophe for taking a look at the issue.
>> >> >>
>> >> >> > Despite it sound right that PageResponseRenderer should set the
>> active
>> >> >> page,
>> >> >> > don't you think that in case of a security exception it would be
>> >> easier
>> >> >> to
>> >> >> > send an HTTP error and let the application developer use standard
>> >> web.xml
>> >> >> > request dispatching to configure the page to display ?
>> >> >>
>> >> >> Specifically in the case of security exception, no, I don't think
>> >> >> that'd be easier. While it's an option, I don't see what the
>> advantage
>> >> >> would be. The exception handler in tapestry-security catches the
>> >> >> exception, sets the error code and renders the configured page.
>> >> >> Configuring the page somewhere else (in standard web.xml) seems to me
>> >> >> like an unnecessary complication compared to contributing
>> >> >> configuration.
>> >> >>
>> >> >> Security exception aside, in the general case http error codes alone
>> >> >> wouldn't be enough to differentiate all the different error cases.
>> I'm
>> >> >> not strongly against exploring alternatives, but it makes sense to me
>> >> >> that PageResponseRenderer would set the active page and I don't see
>> >> >> any disadvantages in doing so, do you?
>> >> >>
>> >> >> Kalle
>> >> >>
>> >> >>
>> >> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>> >> >> >> Pretty please, any committer? It's a one-liner to fix
>> >> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>> >> >> >> attached.
>> >> >> >>
>> >> >> >> Kalle
>> >> >> >>
>> >> >> >>
>> >> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pierce@paceap.com
>> >
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>> >> >> >> >
>> >> >> >> >> Sorry to be a pest, but how could I find a champion to apply
>> the
>> >> >> patch
>> >> >> >> >> for TAP5-1201? I understand Howard's busy and his time is
>> probably
>> >> >> >> >> better spent on bigger issues than this, but I hope that some
>> >> other
>> >> >> >> >> committer would be able to pick this up and apply the one-line
>> >> change
>> >> >> >> >> that would restore functionality that existed in T5.1. It's my
>> >> >> >> >> understanding its perfectly safe to do as suggested so we can't
>> go
>> >> >> >> >> that far off even if somebody wants to refactor it later.
>> >> >> >> >
>> >> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Christophe Cordenier.
>> >> >> >
>> >> >> > Committer on Apache Tapestry 5
>> >> >> > Co-creator of wooki @wookicentral.com
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Christophe Cordenier.
>> >> >
>> >> > Committer on Apache Tapestry 5
>> >> > Co-creator of wooki @wookicentral.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Committer on Apache Tapestry 5
>> > Co-creator of wooki @wookicentral.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi !
2010/7/26 Kalle Korhonen <ka...@gmail.com>
> On Mon, Jul 26, 2010 at 3:17 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
> >> On Sun, Jul 25, 2010 at 11:45 PM, Christophe Cordenier
> >> <ch...@gmail.com> wrote:
> > Actually i was not thinking about catching the exception at the filter
> level
> > since Tapestry does it well and as you said, decoration should do the
> trick,
> > but simply let Tapestry initialize its context (ActivatePage) In fact i
> was
> > wondering, does your security filter implement a ComponentRequestFilter
> or a
> > RequestFilter ?
>
> Ah yes, forgive me for being a little slow here. Yes, the
> SecurityFilter is a ComponentRequestFilter. If I contribute it right
> after "InitializeActivePageName", the fairly comprehensive integration
> tests for the module pass so it seems that would do it. Should have
> found that out and tried it before myself. But wouldn't the wrong page
> be stored as the active page in this case or does it not matter?
>
Right it matters : you will not be able to pre-allocate form control
names... I have to look deeper to see where storeActivePageName() should be
called to work properly with every type of request...
>
> This is not directly related to the issue, but assuming the above
> solution is the right way to go about it and given that
> InitializeActivePageName didn't exist in T5.1, what's the best way for
> checking the version of the core library at runtime (so I can
> contribute it differently depending on the version)?
>
> Kalle
>
>
> >> > Actually, i am not against applying your patch, but as
> >> PageResponseRenderer
> >> > is internal, as a new committer i am definitely cautious in what i am
> >> doing
> >> > and committing ;)
> >>
> >> No worries, I fully understand where you are coming from. The code
> >> worked as is for T5.1 and I already experimentally modified it to call
> >> storeActivePageName() from outside just to verify that'd be enough for
> >> T5.2. So it's not a matter of making it work, but making it work the
> >> right way. Although we both may end up spending more time on it this
> >> way, I much prefer spending my resources on validating the concept
> >> than just hacking it in.
> >>
> >> So in the above case, we don't really want to replace the
> >> RequestExceptionHandler as handling the non-security related
> >> exceptions are delegated back to the original, but if somebody
> >> replaces the DefaultRequestExceptionHandler with one that contains a
> >> form on it, it'd throw an exception as well (just putting together
> >> what you said and reading the code), right? Hopefully that proves the
> >> need for the fix.
> >>
> >> Kalle
> >>
> >>
> >> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
> >> >
> >> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
> >> >> <ch...@gmail.com> wrote:
> >> >> > I am currently working on this JIRA, i have seen that the
> >> >> getActivatePage()
> >> >> > is only called to pre allocate names in Form component so it should
> >> have.
> >> >> So
> >> >> > i guess the page you are returning contains a Form.
> >> >>
> >> >> Right and thanks so much Christophe for taking a look at the issue.
> >> >>
> >> >> > Despite it sound right that PageResponseRenderer should set the
> active
> >> >> page,
> >> >> > don't you think that in case of a security exception it would be
> >> easier
> >> >> to
> >> >> > send an HTTP error and let the application developer use standard
> >> web.xml
> >> >> > request dispatching to configure the page to display ?
> >> >>
> >> >> Specifically in the case of security exception, no, I don't think
> >> >> that'd be easier. While it's an option, I don't see what the
> advantage
> >> >> would be. The exception handler in tapestry-security catches the
> >> >> exception, sets the error code and renders the configured page.
> >> >> Configuring the page somewhere else (in standard web.xml) seems to me
> >> >> like an unnecessary complication compared to contributing
> >> >> configuration.
> >> >>
> >> >> Security exception aside, in the general case http error codes alone
> >> >> wouldn't be enough to differentiate all the different error cases.
> I'm
> >> >> not strongly against exploring alternatives, but it makes sense to me
> >> >> that PageResponseRenderer would set the active page and I don't see
> >> >> any disadvantages in doing so, do you?
> >> >>
> >> >> Kalle
> >> >>
> >> >>
> >> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
> >> >> >> Pretty please, any committer? It's a one-liner to fix
> >> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
> >> >> >> attached.
> >> >> >>
> >> >> >> Kalle
> >> >> >>
> >> >> >>
> >> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pierce@paceap.com
> >
> >> >> wrote:
> >> >> >> >
> >> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> >> >> >> >
> >> >> >> >> Sorry to be a pest, but how could I find a champion to apply
> the
> >> >> patch
> >> >> >> >> for TAP5-1201? I understand Howard's busy and his time is
> probably
> >> >> >> >> better spent on bigger issues than this, but I hope that some
> >> other
> >> >> >> >> committer would be able to pick this up and apply the one-line
> >> change
> >> >> >> >> that would restore functionality that existed in T5.1. It's my
> >> >> >> >> understanding its perfectly safe to do as suggested so we can't
> go
> >> >> >> >> that far off even if somebody wants to refactor it later.
> >> >> >> >
> >> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Regards,
> >> >> > Christophe Cordenier.
> >> >> >
> >> >> > Committer on Apache Tapestry 5
> >> >> > Co-creator of wooki @wookicentral.com
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Christophe Cordenier.
> >> >
> >> > Committer on Apache Tapestry 5
> >> > Co-creator of wooki @wookicentral.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Ville Virtanen <vi...@cerion.fi>.
Hi
I've always used symbol tapestry.version
(org.apache.tapestry5.SymbolConstants.TAPESTRY_VERSION) and parsed it from
that. Just get rid of the dots and then 5.1.0.5 becomes 5105, easy to
convert to integer and perform all kinds of less than, equals or is greater
than comparisons.
- Ville
Kalle Korhonen-2 wrote:
>
> On Mon, Jul 26, 2010 at 3:17 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
>> 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>>> On Sun, Jul 25, 2010 at 11:45 PM, Christophe Cordenier
>>> <ch...@gmail.com> wrote:
>> Actually i was not thinking about catching the exception at the filter
>> level
>> since Tapestry does it well and as you said, decoration should do the
>> trick,
>> but simply let Tapestry initialize its context (ActivatePage) In fact i
>> was
>> wondering, does your security filter implement a ComponentRequestFilter
>> or a
>> RequestFilter ?
>
> Ah yes, forgive me for being a little slow here. Yes, the
> SecurityFilter is a ComponentRequestFilter. If I contribute it right
> after "InitializeActivePageName", the fairly comprehensive integration
> tests for the module pass so it seems that would do it. Should have
> found that out and tried it before myself. But wouldn't the wrong page
> be stored as the active page in this case or does it not matter?
>
> This is not directly related to the issue, but assuming the above
> solution is the right way to go about it and given that
> InitializeActivePageName didn't exist in T5.1, what's the best way for
> checking the version of the core library at runtime (so I can
> contribute it differently depending on the version)?
>
> Kalle
>
>
>>> > Actually, i am not against applying your patch, but as
>>> PageResponseRenderer
>>> > is internal, as a new committer i am definitely cautious in what i am
>>> doing
>>> > and committing ;)
>>>
>>> No worries, I fully understand where you are coming from. The code
>>> worked as is for T5.1 and I already experimentally modified it to call
>>> storeActivePageName() from outside just to verify that'd be enough for
>>> T5.2. So it's not a matter of making it work, but making it work the
>>> right way. Although we both may end up spending more time on it this
>>> way, I much prefer spending my resources on validating the concept
>>> than just hacking it in.
>>>
>>> So in the above case, we don't really want to replace the
>>> RequestExceptionHandler as handling the non-security related
>>> exceptions are delegated back to the original, but if somebody
>>> replaces the DefaultRequestExceptionHandler with one that contains a
>>> form on it, it'd throw an exception as well (just putting together
>>> what you said and reading the code), right? Hopefully that proves the
>>> need for the fix.
>>>
>>> Kalle
>>>
>>>
>>> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>>> >
>>> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
>>> >> <ch...@gmail.com> wrote:
>>> >> > I am currently working on this JIRA, i have seen that the
>>> >> getActivatePage()
>>> >> > is only called to pre allocate names in Form component so it should
>>> have.
>>> >> So
>>> >> > i guess the page you are returning contains a Form.
>>> >>
>>> >> Right and thanks so much Christophe for taking a look at the issue.
>>> >>
>>> >> > Despite it sound right that PageResponseRenderer should set the
>>> active
>>> >> page,
>>> >> > don't you think that in case of a security exception it would be
>>> easier
>>> >> to
>>> >> > send an HTTP error and let the application developer use standard
>>> web.xml
>>> >> > request dispatching to configure the page to display ?
>>> >>
>>> >> Specifically in the case of security exception, no, I don't think
>>> >> that'd be easier. While it's an option, I don't see what the
>>> advantage
>>> >> would be. The exception handler in tapestry-security catches the
>>> >> exception, sets the error code and renders the configured page.
>>> >> Configuring the page somewhere else (in standard web.xml) seems to me
>>> >> like an unnecessary complication compared to contributing
>>> >> configuration.
>>> >>
>>> >> Security exception aside, in the general case http error codes alone
>>> >> wouldn't be enough to differentiate all the different error cases.
>>> I'm
>>> >> not strongly against exploring alternatives, but it makes sense to me
>>> >> that PageResponseRenderer would set the active page and I don't see
>>> >> any disadvantages in doing so, do you?
>>> >>
>>> >> Kalle
>>> >>
>>> >>
>>> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>>> >> >> Pretty please, any committer? It's a one-liner to fix
>>> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>>> >> >> attached.
>>> >> >>
>>> >> >> Kalle
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com>
>>> >> wrote:
>>> >> >> >
>>> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>>> >> >> >
>>> >> >> >> Sorry to be a pest, but how could I find a champion to apply
>>> the
>>> >> patch
>>> >> >> >> for TAP5-1201? I understand Howard's busy and his time is
>>> probably
>>> >> >> >> better spent on bigger issues than this, but I hope that some
>>> other
>>> >> >> >> committer would be able to pick this up and apply the one-line
>>> change
>>> >> >> >> that would restore functionality that existed in T5.1. It's my
>>> >> >> >> understanding its perfectly safe to do as suggested so we can't
>>> go
>>> >> >> >> that far off even if somebody wants to refactor it later.
>>> >> >> >
>>> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> ---------------------------------------------------------------------
>>> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Regards,
>>> >> > Christophe Cordenier.
>>> >> >
>>> >> > Committer on Apache Tapestry 5
>>> >> > Co-creator of wooki @wookicentral.com
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Christophe Cordenier.
>>> >
>>> > Committer on Apache Tapestry 5
>>> > Co-creator of wooki @wookicentral.com
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Regards,
>> Christophe Cordenier.
>>
>> Committer on Apache Tapestry 5
>> Co-creator of wooki @wookicentral.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Using-PageResponseRenderer.render%28%29-in-T5.2--tp29071753p29269797.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Jul 26, 2010 at 3:17 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> On Sun, Jul 25, 2010 at 11:45 PM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
> Actually i was not thinking about catching the exception at the filter level
> since Tapestry does it well and as you said, decoration should do the trick,
> but simply let Tapestry initialize its context (ActivatePage) In fact i was
> wondering, does your security filter implement a ComponentRequestFilter or a
> RequestFilter ?
Ah yes, forgive me for being a little slow here. Yes, the
SecurityFilter is a ComponentRequestFilter. If I contribute it right
after "InitializeActivePageName", the fairly comprehensive integration
tests for the module pass so it seems that would do it. Should have
found that out and tried it before myself. But wouldn't the wrong page
be stored as the active page in this case or does it not matter?
This is not directly related to the issue, but assuming the above
solution is the right way to go about it and given that
InitializeActivePageName didn't exist in T5.1, what's the best way for
checking the version of the core library at runtime (so I can
contribute it differently depending on the version)?
Kalle
>> > Actually, i am not against applying your patch, but as
>> PageResponseRenderer
>> > is internal, as a new committer i am definitely cautious in what i am
>> doing
>> > and committing ;)
>>
>> No worries, I fully understand where you are coming from. The code
>> worked as is for T5.1 and I already experimentally modified it to call
>> storeActivePageName() from outside just to verify that'd be enough for
>> T5.2. So it's not a matter of making it work, but making it work the
>> right way. Although we both may end up spending more time on it this
>> way, I much prefer spending my resources on validating the concept
>> than just hacking it in.
>>
>> So in the above case, we don't really want to replace the
>> RequestExceptionHandler as handling the non-security related
>> exceptions are delegated back to the original, but if somebody
>> replaces the DefaultRequestExceptionHandler with one that contains a
>> form on it, it'd throw an exception as well (just putting together
>> what you said and reading the code), right? Hopefully that proves the
>> need for the fix.
>>
>> Kalle
>>
>>
>> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>> >
>> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
>> >> <ch...@gmail.com> wrote:
>> >> > I am currently working on this JIRA, i have seen that the
>> >> getActivatePage()
>> >> > is only called to pre allocate names in Form component so it should
>> have.
>> >> So
>> >> > i guess the page you are returning contains a Form.
>> >>
>> >> Right and thanks so much Christophe for taking a look at the issue.
>> >>
>> >> > Despite it sound right that PageResponseRenderer should set the active
>> >> page,
>> >> > don't you think that in case of a security exception it would be
>> easier
>> >> to
>> >> > send an HTTP error and let the application developer use standard
>> web.xml
>> >> > request dispatching to configure the page to display ?
>> >>
>> >> Specifically in the case of security exception, no, I don't think
>> >> that'd be easier. While it's an option, I don't see what the advantage
>> >> would be. The exception handler in tapestry-security catches the
>> >> exception, sets the error code and renders the configured page.
>> >> Configuring the page somewhere else (in standard web.xml) seems to me
>> >> like an unnecessary complication compared to contributing
>> >> configuration.
>> >>
>> >> Security exception aside, in the general case http error codes alone
>> >> wouldn't be enough to differentiate all the different error cases. I'm
>> >> not strongly against exploring alternatives, but it makes sense to me
>> >> that PageResponseRenderer would set the active page and I don't see
>> >> any disadvantages in doing so, do you?
>> >>
>> >> Kalle
>> >>
>> >>
>> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>> >> >> Pretty please, any committer? It's a one-liner to fix
>> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>> >> >> attached.
>> >> >>
>> >> >> Kalle
>> >> >>
>> >> >>
>> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com>
>> >> wrote:
>> >> >> >
>> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>> >> >> >
>> >> >> >> Sorry to be a pest, but how could I find a champion to apply the
>> >> patch
>> >> >> >> for TAP5-1201? I understand Howard's busy and his time is probably
>> >> >> >> better spent on bigger issues than this, but I hope that some
>> other
>> >> >> >> committer would be able to pick this up and apply the one-line
>> change
>> >> >> >> that would restore functionality that existed in T5.1. It's my
>> >> >> >> understanding its perfectly safe to do as suggested so we can't go
>> >> >> >> that far off even if somebody wants to refactor it later.
>> >> >> >
>> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>> >> >> >
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Christophe Cordenier.
>> >> >
>> >> > Committer on Apache Tapestry 5
>> >> > Co-creator of wooki @wookicentral.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Committer on Apache Tapestry 5
>> > Co-creator of wooki @wookicentral.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
2010/7/26 Kalle Korhonen <ka...@gmail.com>
> On Sun, Jul 25, 2010 at 11:45 PM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > As this concept has been introduced in 5.2, i am currently looking at the
> > first purpose of it. Where have you implemented the security layer in the
> > Tapestry pipeline ?
>
> It's an advice to RequestExceptionHandler - whether a decorator or an
> advice I don't think it would matter in this case.
>
> > Should you security request filter be inserted after the
> > InitializeActivePageName filter solve your problem ?
>
> There's a security filter as well of course for binding the security
> the context and for doing url-based security etc. but the security
> exception can be thrown from several different levels so I don't think
> I could generically catch and handle the security exceptions at the
> filter level, leaving decorating the exception handler as the best
> option AFAIK.
>
Actually i was not thinking about catching the exception at the filter level
since Tapestry does it well and as you said, decoration should do the trick,
but simply let Tapestry initialize its context (ActivatePage) In fact i was
wondering, does your security filter implement a ComponentRequestFilter or a
RequestFilter ?
> > Actually, i am not against applying your patch, but as
> PageResponseRenderer
> > is internal, as a new committer i am definitely cautious in what i am
> doing
> > and committing ;)
>
> No worries, I fully understand where you are coming from. The code
> worked as is for T5.1 and I already experimentally modified it to call
> storeActivePageName() from outside just to verify that'd be enough for
> T5.2. So it's not a matter of making it work, but making it work the
> right way. Although we both may end up spending more time on it this
> way, I much prefer spending my resources on validating the concept
> than just hacking it in.
>
> So in the above case, we don't really want to replace the
> RequestExceptionHandler as handling the non-security related
> exceptions are delegated back to the original, but if somebody
> replaces the DefaultRequestExceptionHandler with one that contains a
> form on it, it'd throw an exception as well (just putting together
> what you said and reading the code), right? Hopefully that proves the
> need for the fix.
>
> Kalle
>
>
> > 2010/7/26 Kalle Korhonen <ka...@gmail.com>
> >
> >> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
> >> <ch...@gmail.com> wrote:
> >> > I am currently working on this JIRA, i have seen that the
> >> getActivatePage()
> >> > is only called to pre allocate names in Form component so it should
> have.
> >> So
> >> > i guess the page you are returning contains a Form.
> >>
> >> Right and thanks so much Christophe for taking a look at the issue.
> >>
> >> > Despite it sound right that PageResponseRenderer should set the active
> >> page,
> >> > don't you think that in case of a security exception it would be
> easier
> >> to
> >> > send an HTTP error and let the application developer use standard
> web.xml
> >> > request dispatching to configure the page to display ?
> >>
> >> Specifically in the case of security exception, no, I don't think
> >> that'd be easier. While it's an option, I don't see what the advantage
> >> would be. The exception handler in tapestry-security catches the
> >> exception, sets the error code and renders the configured page.
> >> Configuring the page somewhere else (in standard web.xml) seems to me
> >> like an unnecessary complication compared to contributing
> >> configuration.
> >>
> >> Security exception aside, in the general case http error codes alone
> >> wouldn't be enough to differentiate all the different error cases. I'm
> >> not strongly against exploring alternatives, but it makes sense to me
> >> that PageResponseRenderer would set the active page and I don't see
> >> any disadvantages in doing so, do you?
> >>
> >> Kalle
> >>
> >>
> >> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
> >> >> Pretty please, any committer? It's a one-liner to fix
> >> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
> >> >> attached.
> >> >>
> >> >> Kalle
> >> >>
> >> >>
> >> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com>
> >> wrote:
> >> >> >
> >> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> >> >> >
> >> >> >> Sorry to be a pest, but how could I find a champion to apply the
> >> patch
> >> >> >> for TAP5-1201? I understand Howard's busy and his time is probably
> >> >> >> better spent on bigger issues than this, but I hope that some
> other
> >> >> >> committer would be able to pick this up and apply the one-line
> change
> >> >> >> that would restore functionality that existed in T5.1. It's my
> >> >> >> understanding its perfectly safe to do as suggested so we can't go
> >> >> >> that far off even if somebody wants to refactor it later.
> >> >> >
> >> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
> >> >> >
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Christophe Cordenier.
> >> >
> >> > Committer on Apache Tapestry 5
> >> > Co-creator of wooki @wookicentral.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Jul 25, 2010 at 11:45 PM, Christophe Cordenier
<ch...@gmail.com> wrote:
> As this concept has been introduced in 5.2, i am currently looking at the
> first purpose of it. Where have you implemented the security layer in the
> Tapestry pipeline ?
It's an advice to RequestExceptionHandler - whether a decorator or an
advice I don't think it would matter in this case.
> Should you security request filter be inserted after the
> InitializeActivePageName filter solve your problem ?
There's a security filter as well of course for binding the security
the context and for doing url-based security etc. but the security
exception can be thrown from several different levels so I don't think
I could generically catch and handle the security exceptions at the
filter level, leaving decorating the exception handler as the best
option AFAIK.
> Actually, i am not against applying your patch, but as PageResponseRenderer
> is internal, as a new committer i am definitely cautious in what i am doing
> and committing ;)
No worries, I fully understand where you are coming from. The code
worked as is for T5.1 and I already experimentally modified it to call
storeActivePageName() from outside just to verify that'd be enough for
T5.2. So it's not a matter of making it work, but making it work the
right way. Although we both may end up spending more time on it this
way, I much prefer spending my resources on validating the concept
than just hacking it in.
So in the above case, we don't really want to replace the
RequestExceptionHandler as handling the non-security related
exceptions are delegated back to the original, but if somebody
replaces the DefaultRequestExceptionHandler with one that contains a
form on it, it'd throw an exception as well (just putting together
what you said and reading the code), right? Hopefully that proves the
need for the fix.
Kalle
> 2010/7/26 Kalle Korhonen <ka...@gmail.com>
>
>> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
>> > I am currently working on this JIRA, i have seen that the
>> getActivatePage()
>> > is only called to pre allocate names in Form component so it should have.
>> So
>> > i guess the page you are returning contains a Form.
>>
>> Right and thanks so much Christophe for taking a look at the issue.
>>
>> > Despite it sound right that PageResponseRenderer should set the active
>> page,
>> > don't you think that in case of a security exception it would be easier
>> to
>> > send an HTTP error and let the application developer use standard web.xml
>> > request dispatching to configure the page to display ?
>>
>> Specifically in the case of security exception, no, I don't think
>> that'd be easier. While it's an option, I don't see what the advantage
>> would be. The exception handler in tapestry-security catches the
>> exception, sets the error code and renders the configured page.
>> Configuring the page somewhere else (in standard web.xml) seems to me
>> like an unnecessary complication compared to contributing
>> configuration.
>>
>> Security exception aside, in the general case http error codes alone
>> wouldn't be enough to differentiate all the different error cases. I'm
>> not strongly against exploring alternatives, but it makes sense to me
>> that PageResponseRenderer would set the active page and I don't see
>> any disadvantages in doing so, do you?
>>
>> Kalle
>>
>>
>> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>> >> Pretty please, any committer? It's a one-liner to fix
>> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>> >> attached.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com>
>> wrote:
>> >> >
>> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>> >> >
>> >> >> Sorry to be a pest, but how could I find a champion to apply the
>> patch
>> >> >> for TAP5-1201? I understand Howard's busy and his time is probably
>> >> >> better spent on bigger issues than this, but I hope that some other
>> >> >> committer would be able to pick this up and apply the one-line change
>> >> >> that would restore functionality that existed in T5.1. It's my
>> >> >> understanding its perfectly safe to do as suggested so we can't go
>> >> >> that far off even if somebody wants to refactor it later.
>> >> >
>> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Committer on Apache Tapestry 5
>> > Co-creator of wooki @wookicentral.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
As this concept has been introduced in 5.2, i am currently looking at the
first purpose of it. Where have you implemented the security layer in the
Tapestry pipeline ?
Should you security request filter be inserted after the
InitializeActivePageName filter solve your problem ?
Actually, i am not against applying your patch, but as PageResponseRenderer
is internal, as a new committer i am definitely cautious in what i am doing
and committing ;)
2010/7/26 Kalle Korhonen <ka...@gmail.com>
> On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > I am currently working on this JIRA, i have seen that the
> getActivatePage()
> > is only called to pre allocate names in Form component so it should have.
> So
> > i guess the page you are returning contains a Form.
>
> Right and thanks so much Christophe for taking a look at the issue.
>
> > Despite it sound right that PageResponseRenderer should set the active
> page,
> > don't you think that in case of a security exception it would be easier
> to
> > send an HTTP error and let the application developer use standard web.xml
> > request dispatching to configure the page to display ?
>
> Specifically in the case of security exception, no, I don't think
> that'd be easier. While it's an option, I don't see what the advantage
> would be. The exception handler in tapestry-security catches the
> exception, sets the error code and renders the configured page.
> Configuring the page somewhere else (in standard web.xml) seems to me
> like an unnecessary complication compared to contributing
> configuration.
>
> Security exception aside, in the general case http error codes alone
> wouldn't be enough to differentiate all the different error cases. I'm
> not strongly against exploring alternatives, but it makes sense to me
> that PageResponseRenderer would set the active page and I don't see
> any disadvantages in doing so, do you?
>
> Kalle
>
>
> > 2010/7/20 Kalle Korhonen <ka...@gmail.com>
> >> Pretty please, any committer? It's a one-liner to fix
> >> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
> >> attached.
> >>
> >> Kalle
> >>
> >>
> >> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com>
> wrote:
> >> >
> >> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> >> >
> >> >> Sorry to be a pest, but how could I find a champion to apply the
> patch
> >> >> for TAP5-1201? I understand Howard's busy and his time is probably
> >> >> better spent on bigger issues than this, but I hope that some other
> >> >> committer would be able to pick this up and apply the one-line change
> >> >> that would restore functionality that existed in T5.1. It's my
> >> >> understanding its perfectly safe to do as suggested so we can't go
> >> >> that far off even if somebody wants to refactor it later.
> >> >
> >> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Jul 25, 2010 at 5:35 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> I am currently working on this JIRA, i have seen that the getActivatePage()
> is only called to pre allocate names in Form component so it should have. So
> i guess the page you are returning contains a Form.
Right and thanks so much Christophe for taking a look at the issue.
> Despite it sound right that PageResponseRenderer should set the active page,
> don't you think that in case of a security exception it would be easier to
> send an HTTP error and let the application developer use standard web.xml
> request dispatching to configure the page to display ?
Specifically in the case of security exception, no, I don't think
that'd be easier. While it's an option, I don't see what the advantage
would be. The exception handler in tapestry-security catches the
exception, sets the error code and renders the configured page.
Configuring the page somewhere else (in standard web.xml) seems to me
like an unnecessary complication compared to contributing
configuration.
Security exception aside, in the general case http error codes alone
wouldn't be enough to differentiate all the different error cases. I'm
not strongly against exploring alternatives, but it makes sense to me
that PageResponseRenderer would set the active page and I don't see
any disadvantages in doing so, do you?
Kalle
> 2010/7/20 Kalle Korhonen <ka...@gmail.com>
>> Pretty please, any committer? It's a one-liner to fix
>> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
>> attached.
>>
>> Kalle
>>
>>
>> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com> wrote:
>> >
>> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>> >
>> >> Sorry to be a pest, but how could I find a champion to apply the patch
>> >> for TAP5-1201? I understand Howard's busy and his time is probably
>> >> better spent on bigger issues than this, but I hope that some other
>> >> committer would be able to pick this up and apply the one-line change
>> >> that would restore functionality that existed in T5.1. It's my
>> >> understanding its perfectly safe to do as suggested so we can't go
>> >> that far off even if somebody wants to refactor it later.
>> >
>> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi Kalle,
I am currently working on this JIRA, i have seen that the getActivatePage()
is only called to pre allocate names in Form component so it should have. So
i guess the page you are returning contains a Form.
Despite it sound right that PageResponseRenderer should set the active page,
don't you think that in case of a security exception it would be easier to
send an HTTP error and let the application developer use standard web.xml
request dispatching to configure the page to display ?
Cheers
2010/7/20 Kalle Korhonen <ka...@gmail.com>
> Pretty please, any committer? It's a one-liner to fix
> https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
> attached.
>
> Kalle
>
>
> On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com> wrote:
> >
> > On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> >
> >> Sorry to be a pest, but how could I find a champion to apply the patch
> >> for TAP5-1201? I understand Howard's busy and his time is probably
> >> better spent on bigger issues than this, but I hope that some other
> >> committer would be able to pick this up and apply the one-line change
> >> that would restore functionality that existed in T5.1. It's my
> >> understanding its perfectly safe to do as suggested so we can't go
> >> that far off even if somebody wants to refactor it later.
> >
> > Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
Pretty please, any committer? It's a one-liner to fix
https://issues.apache.org/jira/browse/TAP5-1201 and the patch is
attached.
Kalle
On Mon, Jul 19, 2010 at 2:23 PM, Pierce Wetter <pi...@paceap.com> wrote:
>
> On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
>
>> Sorry to be a pest, but how could I find a champion to apply the patch
>> for TAP5-1201? I understand Howard's busy and his time is probably
>> better spent on bigger issues than this, but I hope that some other
>> committer would be able to pick this up and apply the one-line change
>> that would restore functionality that existed in T5.1. It's my
>> understanding its perfectly safe to do as suggested so we can't go
>> that far off even if somebody wants to refactor it later.
>
> Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Pierce Wetter <pi...@paceap.com>.
On Jul 9, 2010, at 1:40 PM, Kalle Korhonen wrote:
> Sorry to be a pest, but how could I find a champion to apply the patch
> for TAP5-1201? I understand Howard's busy and his time is probably
> better spent on bigger issues than this, but I hope that some other
> committer would be able to pick this up and apply the one-line change
> that would restore functionality that existed in T5.1. It's my
> understanding its perfectly safe to do as suggested so we can't go
> that far off even if somebody wants to refactor it later.
Ditto, since I'm using tapestry-security with 5.2-SNAPSHOT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
Sorry to be a pest, but how could I find a champion to apply the patch
for TAP5-1201? I understand Howard's busy and his time is probably
better spent on bigger issues than this, but I hope that some other
committer would be able to pick this up and apply the one-line change
that would restore functionality that existed in T5.1. It's my
understanding its perfectly safe to do as suggested so we can't go
that far off even if somebody wants to refactor it later.
Kalle
On Tue, Jul 6, 2010 at 4:47 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Attached a patch to https://issues.apache.org/jira/browse/TAP5-1201
> (sorry if I'm being pushy about it but I'd rather have it resolved in
> the core than work around the issue in the add-on library).
>
> Kalle
>
>
> On Mon, Jul 5, 2010 at 2:23 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> https://issues.apache.org/jira/browse/TAP5-1015? Doesn't quite seem to
>> fit my use case unless you'd be willing to add to/change the
>> RequestExceptionHandler interface.
>>
>> Kalle
>>
>>
>> On Mon, Jul 5, 2010 at 2:13 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>> Perhaps; actually there's another outstanding issue (I don't have time
>>> to look it up) that asks for the ability to render an alternate page
>>> from the activate event handler ... without sending a redirect. That
>>> might fit in with your needs as well.
>>>
>>> On Mon, Jul 5, 2010 at 1:59 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Thanks Howard. Understandable and yes, I realize PageResponseRenderer
>>>> is internal but as I see it, adding the call makes sense for this use
>>>> case and shouldn't cause problems even if it's called "just in case".
>>>> Opened https://issues.apache.org/jira/browse/TAP5-1201 for it.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Mon, Jul 5, 2010 at 10:34 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>>>> I suppose it could; just a case of unexpected use of the APIs. As
>>>>> currently coded, we assume that the active page is identified by the
>>>>> component event or page render dispatcher.
>>>>>
>>>>> On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> (Related to Tynamo's tapestry-security,
>>>>>> http://tynamo.org/tapestry-security+guide)
>>>>>>
>>>>>> A custom exception handler added as an advice for the default one
>>>>>> wants to handle some specific type of exceptions and proceeds to call
>>>>>> PageResponseRenderer.render() in those cases. This works without
>>>>>> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
>>>>>> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
>>>>>> identity of the active page for this request has not yet been
>>>>>> established". To fix the issue, I can call the newly added
>>>>>> RequestGlobabls.storeActivePageName(String pageName) before call to
>>>>>> render(). While it's an easy fix, it'd be nicer if
>>>>>> PageResponseRenderer.render() would just do that internally. Is there
>>>>>> some reason why this would be a bad idea?
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
Attached a patch to https://issues.apache.org/jira/browse/TAP5-1201
(sorry if I'm being pushy about it but I'd rather have it resolved in
the core than work around the issue in the add-on library).
Kalle
On Mon, Jul 5, 2010 at 2:23 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/TAP5-1015? Doesn't quite seem to
> fit my use case unless you'd be willing to add to/change the
> RequestExceptionHandler interface.
>
> Kalle
>
>
> On Mon, Jul 5, 2010 at 2:13 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Perhaps; actually there's another outstanding issue (I don't have time
>> to look it up) that asks for the ability to render an alternate page
>> from the activate event handler ... without sending a redirect. That
>> might fit in with your needs as well.
>>
>> On Mon, Jul 5, 2010 at 1:59 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Thanks Howard. Understandable and yes, I realize PageResponseRenderer
>>> is internal but as I see it, adding the call makes sense for this use
>>> case and shouldn't cause problems even if it's called "just in case".
>>> Opened https://issues.apache.org/jira/browse/TAP5-1201 for it.
>>>
>>> Kalle
>>>
>>>
>>> On Mon, Jul 5, 2010 at 10:34 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>>> I suppose it could; just a case of unexpected use of the APIs. As
>>>> currently coded, we assume that the active page is identified by the
>>>> component event or page render dispatcher.
>>>>
>>>> On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> (Related to Tynamo's tapestry-security,
>>>>> http://tynamo.org/tapestry-security+guide)
>>>>>
>>>>> A custom exception handler added as an advice for the default one
>>>>> wants to handle some specific type of exceptions and proceeds to call
>>>>> PageResponseRenderer.render() in those cases. This works without
>>>>> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
>>>>> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
>>>>> identity of the active page for this request has not yet been
>>>>> established". To fix the issue, I can call the newly added
>>>>> RequestGlobabls.storeActivePageName(String pageName) before call to
>>>>> render(). While it's an easy fix, it'd be nicer if
>>>>> PageResponseRenderer.render() would just do that internally. Is there
>>>>> some reason why this would be a bad idea?
>>>>>
>>>>> Kalle
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
https://issues.apache.org/jira/browse/TAP5-1015? Doesn't quite seem to
fit my use case unless you'd be willing to add to/change the
RequestExceptionHandler interface.
Kalle
On Mon, Jul 5, 2010 at 2:13 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Perhaps; actually there's another outstanding issue (I don't have time
> to look it up) that asks for the ability to render an alternate page
> from the activate event handler ... without sending a redirect. That
> might fit in with your needs as well.
>
> On Mon, Jul 5, 2010 at 1:59 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Thanks Howard. Understandable and yes, I realize PageResponseRenderer
>> is internal but as I see it, adding the call makes sense for this use
>> case and shouldn't cause problems even if it's called "just in case".
>> Opened https://issues.apache.org/jira/browse/TAP5-1201 for it.
>>
>> Kalle
>>
>>
>> On Mon, Jul 5, 2010 at 10:34 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>> I suppose it could; just a case of unexpected use of the APIs. As
>>> currently coded, we assume that the active page is identified by the
>>> component event or page render dispatcher.
>>>
>>> On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> (Related to Tynamo's tapestry-security,
>>>> http://tynamo.org/tapestry-security+guide)
>>>>
>>>> A custom exception handler added as an advice for the default one
>>>> wants to handle some specific type of exceptions and proceeds to call
>>>> PageResponseRenderer.render() in those cases. This works without
>>>> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
>>>> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
>>>> identity of the active page for this request has not yet been
>>>> established". To fix the issue, I can call the newly added
>>>> RequestGlobabls.storeActivePageName(String pageName) before call to
>>>> render(). While it's an easy fix, it'd be nicer if
>>>> PageResponseRenderer.render() would just do that internally. Is there
>>>> some reason why this would be a bad idea?
>>>>
>>>> Kalle
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Perhaps; actually there's another outstanding issue (I don't have time
to look it up) that asks for the ability to render an alternate page
from the activate event handler ... without sending a redirect. That
might fit in with your needs as well.
On Mon, Jul 5, 2010 at 1:59 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Thanks Howard. Understandable and yes, I realize PageResponseRenderer
> is internal but as I see it, adding the call makes sense for this use
> case and shouldn't cause problems even if it's called "just in case".
> Opened https://issues.apache.org/jira/browse/TAP5-1201 for it.
>
> Kalle
>
>
> On Mon, Jul 5, 2010 at 10:34 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> I suppose it could; just a case of unexpected use of the APIs. As
>> currently coded, we assume that the active page is identified by the
>> component event or page render dispatcher.
>>
>> On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> (Related to Tynamo's tapestry-security,
>>> http://tynamo.org/tapestry-security+guide)
>>>
>>> A custom exception handler added as an advice for the default one
>>> wants to handle some specific type of exceptions and proceeds to call
>>> PageResponseRenderer.render() in those cases. This works without
>>> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
>>> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
>>> identity of the active page for this request has not yet been
>>> established". To fix the issue, I can call the newly added
>>> RequestGlobabls.storeActivePageName(String pageName) before call to
>>> render(). While it's an easy fix, it'd be nicer if
>>> PageResponseRenderer.render() would just do that internally. Is there
>>> some reason why this would be a bad idea?
>>>
>>> Kalle
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Kalle Korhonen <ka...@gmail.com>.
Thanks Howard. Understandable and yes, I realize PageResponseRenderer
is internal but as I see it, adding the call makes sense for this use
case and shouldn't cause problems even if it's called "just in case".
Opened https://issues.apache.org/jira/browse/TAP5-1201 for it.
Kalle
On Mon, Jul 5, 2010 at 10:34 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I suppose it could; just a case of unexpected use of the APIs. As
> currently coded, we assume that the active page is identified by the
> component event or page render dispatcher.
>
> On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> (Related to Tynamo's tapestry-security,
>> http://tynamo.org/tapestry-security+guide)
>>
>> A custom exception handler added as an advice for the default one
>> wants to handle some specific type of exceptions and proceeds to call
>> PageResponseRenderer.render() in those cases. This works without
>> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
>> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
>> identity of the active page for this request has not yet been
>> established". To fix the issue, I can call the newly added
>> RequestGlobabls.storeActivePageName(String pageName) before call to
>> render(). While it's an easy fix, it'd be nicer if
>> PageResponseRenderer.render() would just do that internally. Is there
>> some reason why this would be a bad idea?
>>
>> Kalle
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Using PageResponseRenderer.render() in T5.2?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I suppose it could; just a case of unexpected use of the APIs. As
currently coded, we assume that the active page is identified by the
component event or page render dispatcher.
On Sun, Jul 4, 2010 at 4:05 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> (Related to Tynamo's tapestry-security,
> http://tynamo.org/tapestry-security+guide)
>
> A custom exception handler added as an advice for the default one
> wants to handle some specific type of exceptions and proceeds to call
> PageResponseRenderer.render() in those cases. This works without
> issues in T5.1 but in T5.2 ComponentSource.getActivePage() throws
> "org.apache.tapestry5.ioc.internal.util.TapestryException: The
> identity of the active page for this request has not yet been
> established". To fix the issue, I can call the newly added
> RequestGlobabls.storeActivePageName(String pageName) before call to
> render(). While it's an easy fix, it'd be nicer if
> PageResponseRenderer.render() would just do that internally. Is there
> some reason why this would be a bad idea?
>
> Kalle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org