We discussing two things here :) a) if we should add the gate at all (and I'm referring more to this) and b) the technical implementation of the feature.
I agree that I'm the only one against the Decorator :( And I will definitely not call a vote for such a discussion :) Still, I fail to see a good reason why not to code it into the resource resolver bundle. It's a core feature anyway. *if* we are going to add the decorator, then we should even move the gate api into a separate bundle and make this a 100% optional feature. Adding the implementation now to the resource resolver bundle and maybe come up with a better separation in some time is imho the easier way than adding a decorator which we can't remove later on. Now, another option would be to use OSGi service hooks (might be tricky). The basic idea is to hide the real resource resolver factory from all bundles except the gate implementations bundle which then register a wrapper resource resolver factory that is seen by all other bundles. Not sure of this is doable this way. However it would be a transparent replacement without opening any doors. Carsten 2013/3/6 Bertrand Delacretaz <[email protected]>: > Hi Carsten, > > On Wed, Mar 6, 2013 at 12:45 PM, Carsten Ziegeler <[email protected]> > wrote: >> ...Now Mike has started work and immediately everyone and his dog is >> going back to the old discussion. :(... > > So far, between SLING-2698 and this thread AFAICS you're the only one > who doesn't want the ResourceResolverDecorator option (which can also > be disabled by a default configuration if we want to make it clear > that it's not meant for general use). > > In SLING-2698 Mike indicates he's open to both options, and everybody > in this thread seems to prefer it as well. > > Unless we get more points in favor of the ResourceAccessGate option, > the easiest way to go forward seems to be for you to accept that > emerging consensus. Or start a vote if we cannot reach consensus in > this way. Or come up with another suggestion that allows the access > gate to be clearly isolated as an optional feature (a la > path-based-rtp) instead of being mixed up with the Sling core. > > -Bertrand -- Carsten Ziegeler [email protected]
