Just for the record: - Filters registered via @SlingFilter will set the order as Serviceranking
Best regards Dominik On Tue, Jun 18, 2013 at 3:19 PM, Felix Meschberger <fmesc...@adobe.com>wrote: > Hi > > Yes, I am basically in that camp, too, but ... > > In our commercial product (Adobe Experience Manager aka CQ5) I realized > that of the twenty-some filters only four require treatment and that all > four can be "fixed" in a deployed instance by OSGi configuration setting > the service.ranking property to the appropriate value. > > Two of these are actually Sling's I18NFilter and RewriteFilter. > > So, I tend to switch over to the fix-the-implementation-camp. > > Regards > Felix > > Am 18.06.2013 um 14:20 schrieb Bertrand Delacretaz: > > > On Tue, Jun 18, 2013 at 2:04 PM, Felix Meschberger <fmesc...@adobe.com> > wrote: > >> ...We basically have two options: > >> > >> (1) Keep the implementation and fix the documentation. This would allow > us to keep > >> the implementation and maintain backwards compatibility at the expense > of not following the OSGi spec > >> with respect to the service.ranking property... > > > > I'm in favor of this option, including writing integration tests that > > demonstrate it (yes I volunteer ;-) > > > > I don't think the OSGi spec is a problem, we are ordering the services > > based on that, but then you could argue that filter 1 should be called > > first because it's 1, or that filter 123456789 should be called first > > because it has a higher ranking. > > > > Let's not break backwards compatibility based on this arbitrary choice > > of ordering. > > > > -Bertrand > >
