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.
>> > > > > >
>> > > > >
>> > > >
>> > >
>>
>
>
