Depending on your use case, you could also just define
/apps/new/handler as a super type for old/handler.
If you don't have any script for old/handler then the new ones are
used - that works for script resolution.

If you have other code checking a resource type of a resource, then
this code should use ResourceUtil.isA
to check if a resource is of some time. In this case the resource type
hierarchy explained above works as
well

Regards
Carsten

2012/6/29 sam ” <[email protected]>:
> Actualny this makes sense because Orange wins by being executed later than
> Apple.
> On Jun 28, 2012 5:56 PM, "sam ”" <[email protected]> wrote:
>
>> It looks like ResourceDecorators are ordered by service.ranking property
>> in ascending order.
>>
>> @Properties({
>>     @Property(name = Constants.SERVICE_RANKING, intValue = 10)
>> })
>> public class  Apple implements ResourceDecorator {
>> ...
>> }
>>
>> @Properties({
>>     @Property(name = Constants.SERVICE_RANKING, intValue = 20)
>> })
>> public class  Orange implements ResourceDecorator {
>> ...
>> }
>>
>>
>> Given above,   Apple is executed first, then Orange, according to:
>>
>> http://svn.apache.org/repos/asf/sling/trunk/bundles/commons/osgi/src/main/java/org/apache/sling/commons/osgi/ServiceUtil.java
>>
>>
>> This is sort of unintuitive to me because there is this:
>>
>> http://www.osgi.org/javadoc/r2/org/osgi/framework/Constants.html#SERVICE_RANKING
>> The default ranking is 0. A service with a ranking of Integer.MAX_VALUE is
>> very likely to be returned as the default service, whereas a service with a
>> ranking of Integer.MIN_VALUE is very unlikely to be returned.
>>
>>
>> Maybe ResourceDecorators should be sorted descending order so that
>> decorators with higher service.ranking  will be executed first?
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 28, 2012 at 5:19 PM, sam ” <[email protected]> wrote:
>>
>>> Created the ticket: https://issues.apache.org/jira/browse/SLING-2526
>>>
>>>  Are all registered and Active  ResourceDecorators  called?
>>> What if I have more than one ResourceDecorator  that sets resourceType
>>> of  a certain resource(s)?  Which decorator wins?
>>>
>>>
>>>
>>>
>>> On Wed, Jun 27, 2012 at 4:19 PM, Justin Edelson 
>>> <[email protected]>wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> On Jun 27, 2012 3:56 PM, "sam ”" <[email protected]> wrote:
>>>> >
>>>> > Thanks Justin.
>>>> > Works well!
>>>>
>>>> Glad to hear.
>>>>
>>>> >
>>>> > =8<=
>>>> >    @Override
>>>> >    public Resource decorate(Resource resource, HttpServletRequest
>>>> request)
>>>> > {
>>>> >        final String resourceType = resource.getResourceType();
>>>> >        if ("old/handler".equals(resourceType)) {
>>>> >            return new ResourceWrapper(resource) {
>>>> >                @Override
>>>> >                public String getResourceType() {
>>>> >                    return "new/handler";
>>>> >                }
>>>> >            };
>>>> >        }
>>>> >        return resource;
>>>> >    }
>>>> >
>>>> > =>8=
>>>> >
>>>> >
>>>> > Is there a way to register my ResourceDecorator service for certain
>>>> > resource types only  instead of that if conditional above?
>>>>
>>>> Not AFAIK, but this seems like it would be a useful feature. Can you
>>>> create
>>>> a JIRA issue?
>>>>
>>>> Justin
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Jun 27, 2012 at 3:06 PM, Justin Edelson <
>>>> [email protected]
>>>> >wrote:
>>>> >
>>>> > > Hi Sam,
>>>> > > ResoureDecorators must be registered add OSGi services.
>>>> > >
>>>> > > Justin
>>>> > > On Jun 27, 2012 3:00 PM, "sam ”" <[email protected]> wrote:
>>>> > >
>>>> > > > Ah thanks.
>>>> > > >
>>>> > > > Is there a way to provide ResourceDecorator implementation in
>>>> script
>>>> > > (jsp)?
>>>> > > > Or, do I have to provide OSGi bundle/component?
>>>> > > >
>>>> > > >
>>>> > > > On Wed, Jun 27, 2012 at 2:34 PM, Justin Edelson <
>>>> [email protected]
>>>> > > > >wrote:
>>>> > > >
>>>> > > > > Hi Sam,
>>>> > > > > You should be able to do this with a  ResourceDecorator service
>>>> to
>>>> > > change
>>>> > > > > the resource type at runtime.
>>>> > > > >
>>>> > > > > Regards,
>>>> > > > > Justin
>>>> > > > > On Jun 27, 2012 2:25 PM, "sam ”" <[email protected]> wrote:
>>>> > > > >
>>>> > > > > > Hey,
>>>> > > > > >
>>>> > > > > > I have a large number of resources with sling:resourceType =
>>>> > > > old/handler
>>>> > > > > >
>>>> > > > > > I don't want to modify their sling:resourceType property.
>>>>  But, I
>>>> > > want
>>>> > > > to
>>>> > > > > > have old/handler actually resolve to  /apps/new/handler
>>>> > > > > >
>>>> > > > > > For example, given a resource:
>>>> > > > > > /content/mypage
>>>> > > > > > whose sling:resourceType = old/hander,
>>>> > > > > >
>>>> > > > > > GET /content/mypage.html
>>>> > > > > > is handled by:
>>>> > > > > > /apps/old/handler/html.jsp
>>>> > > > > >
>>>> > > > > >
>>>> > > > > > Without modifying /content/mypage,  can I have the same GET
>>>> request
>>>> > > be
>>>> > > > > > handled by:
>>>> > > > > > /apps/new/handler/html.jsp   ?
>>>> > > > > >
>>>> > > > > > I tried /etc/maps/oldToNew
>>>> > > > > > sling:internalRedirect = /apps/new/handler$1
>>>> > > > > > sling:match = .*/apps/old/handler(.*)
>>>> > > > > >
>>>> > > > > > GET /apps/old/handler
>>>> > > > > > does redirect to /apps/new/handler.
>>>> > > > > > But, script resolution doesn't seem to use /etc/maps.
>>>> > > > > >
>>>> > > > >
>>>> > > >
>>>> > >
>>>>
>>>
>>>
>>



-- 
Carsten Ziegeler
[email protected]

Reply via email to