You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Justin Edelson <ju...@apache.org> on 2012/02/11 02:19:51 UTC

[VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

As described here: https://issues.apache.org/jira/browse/SLING-2411, we
do not currently have a way of enforcing that ResourceResolver clients invoke
resolve(HttpServletRequest, String) when they are doing a resolve
inside a request
context. The net effect of this is that implementors of ResourceDecorator have
inconsistent results.

I've uploaded a strawman patch to
https://issues.apache.org/jira/browse/SLING-2411 to
illustrate how this might be solved using a ThreadLocal. However, I
personally feel
like we should just go ahead and deprecate this method and I'd like to
call a vote for it.

Please vote:
[ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
[ ] 0
[ ] -1 - don't deprecate

Note - if you vote -1, please provide an alternative. It could be the
strawman, it could be
something else, but I'd really like to see this fixed.

Thanks
Justin

Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Alexander Klimetschek <ak...@adobe.com>.
+1 (non binding)

Based on my experience, a ResourceDecorator almost never applies globally to all resources all the time, but is very often based on request-dependent information (such as parameters).

Cheers,
Alex

Am 13.02.2012 um 11:05 schrieb Felix Meschberger:

> 
> Hi
> 
> Am 11.02.2012 um 02:19 schrieb Justin Edelson:
> 
>> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
>> do not currently have a way of enforcing that ResourceResolver clients invoke
>> resolve(HttpServletRequest, String) when they are doing a resolve
>> inside a request
>> context. The net effect of this is that implementors of ResourceDecorator have
>> inconsistent results.
>> 
>> I've uploaded a strawman patch to
>> https://issues.apache.org/jira/browse/SLING-2411 to
>> illustrate how this might be solved using a ThreadLocal. However, I
>> personally feel
>> like we should just go ahead and deprecate this method and I'd like to
>> call a vote for it.
>> 
>> Please vote:
>> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
>> [ ] 0
>> [ ] -1 - don't deprecate
>> 
>> Note - if you vote -1, please provide an alternative. It could be the
>> strawman, it could be
>> something else, but I'd really like to see this fixed.
> 
> +1 to deprecate.
> 
> Regards
> Felix
> 
>> 
>> Thanks
>> Justin
> 

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel


Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Felix Meschberger <fm...@adobe.com>.
Hi

Am 11.02.2012 um 02:19 schrieb Justin Edelson:

> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
> do not currently have a way of enforcing that ResourceResolver clients invoke
> resolve(HttpServletRequest, String) when they are doing a resolve
> inside a request
> context. The net effect of this is that implementors of ResourceDecorator have
> inconsistent results.
> 
> I've uploaded a strawman patch to
> https://issues.apache.org/jira/browse/SLING-2411 to
> illustrate how this might be solved using a ThreadLocal. However, I
> personally feel
> like we should just go ahead and deprecate this method and I'd like to
> call a vote for it.
> 
> Please vote:
> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> [ ] 0
> [ ] -1 - don't deprecate
> 
> Note - if you vote -1, please provide an alternative. It could be the
> strawman, it could be
> something else, but I'd really like to see this fixed.

+1 to deprecate.

Regards
Felix

> 
> Thanks
> Justin


Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Felix Meschberger <fm...@adobe.com>.
Am 13.02.2012 um 22:15 schrieb Bertrand Delacretaz:

> On Sat, Feb 11, 2012 at 2:19 AM, Justin Edelson <ju...@apache.org> wrote:
>> ...Please vote..
> 
> +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> 
> Just to be clear, as I don't think this was clearly mentioned in this
> thread, this means keeping the first method of this interface as is,
> and deprecating the second one:
> 
> interface ResourceDecorator {
>    Resource decorate(Resource)
    @Deprecated
>    Resource decorate(Resource, HttpServletRequest)
> }
> 

Yes.

Regards
Felix


> Note that http://sling.apache.org/site/wrap-or-decorate-resources.html
> will have to be updated as well.
> 
> -Bertrand


Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Feb 11, 2012 at 2:19 AM, Justin Edelson <ju...@apache.org> wrote:
> ...Please vote..

+1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Just to be clear, as I don't think this was clearly mentioned in this
thread, this means keeping the first method of this interface as is,
and deprecating the second one:

interface ResourceDecorator {
    Resource decorate(Resource)
    Resource decorate(Resource, HttpServletRequest)
}

Note that http://sling.apache.org/site/wrap-or-decorate-resources.html
will have to be updated as well.

-Bertrand

[RESULT] [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Justin Edelson <ju...@apache.org>.
The vote to deprecate ResourceDecorator.decorate(Resource,
HttpServletRequest) has passed with the following votes:

+1 (binding): Justin Edelson, Felix Meschberger, Bertrand Delacretaz
+1 (non-binding): Antonio Sanso

Note - Alexander Klimetschek originally voted +1, but privately
emailed me to retract his vote.

I will post a link to this thread on
https://issues.apache.org/jira/browse/SLING-2411 and make the
corresponding code and documentation changes.

On Fri, Feb 10, 2012 at 8:19 PM, Justin Edelson <ju...@apache.org> wrote:
> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
> do not currently have a way of enforcing that ResourceResolver clients invoke
> resolve(HttpServletRequest, String) when they are doing a resolve
> inside a request
> context. The net effect of this is that implementors of ResourceDecorator have
> inconsistent results.
>
> I've uploaded a strawman patch to
> https://issues.apache.org/jira/browse/SLING-2411 to
> illustrate how this might be solved using a ThreadLocal. However, I
> personally feel
> like we should just go ahead and deprecate this method and I'd like to
> call a vote for it.
>
> Please vote:
> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> [ ] 0
> [ ] -1 - don't deprecate
>
> Note - if you vote -1, please provide an alternative. It could be the
> strawman, it could be
> something else, but I'd really like to see this fixed.
>
> Thanks
> Justin

Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Posted by Antonio Sanso <as...@adobe.com>.
+1 (non-binding)

Regards

Antonio

On Feb 11, 2012, at 2:19 AM, Justin Edelson wrote:

> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
> do not currently have a way of enforcing that ResourceResolver clients invoke
> resolve(HttpServletRequest, String) when they are doing a resolve
> inside a request
> context. The net effect of this is that implementors of ResourceDecorator have
> inconsistent results.
> 
> I've uploaded a strawman patch to
> https://issues.apache.org/jira/browse/SLING-2411 to
> illustrate how this might be solved using a ThreadLocal. However, I
> personally feel
> like we should just go ahead and deprecate this method and I'd like to
> call a vote for it.
> 
> Please vote:
> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> [ ] 0
> [ ] -1 - don't deprecate
> 
> Note - if you vote -1, please provide an alternative. It could be the
> strawman, it could be
> something else, but I'd really like to see this fixed.
> 
> Thanks
> Justin