Well, compatibility is hard to achieve here. Imagine you have a servlet registered to a path with an extension. That obviously requires the new servlet resolver bundle (evaluating the sling.servlet.resolution property). Therefore it cannot be backwards compatible. It should fail in case you try to run that servlet with an older resolver. Therefore I suggest relying on OSGi capabilities here.
Konrad > On 4. Dec 2019, at 10:30, Carsten Ziegeler <[email protected]> wrote: > > It's important that we are compatible. For the new property I think we should > support two values, one of them being the default (works as today) and one > for the new behaviour. Not specifying the prop then is the same as specifying > the default value. > > I'm not sure if "strict" is a good choice, its not directly visible what it > means > > Regards > Carsten > > Am 03.12.2019 um 15:54 schrieb Bertrand Delacretaz: >> Hi, >> For SLING-8110 I'd like to take into account the >> sling.servlet.extensions and sling.servlet.methods properties, if >> present, on servlets that are mounted using the sling.servlet.paths >> property. >> However that's not backwards compatible, as currently these properties >> are silently ignored if sling.servlet.paths is present (*) >> To keep backwards compatibility, I suggest adding a new optional >> sling.servlet.resolution property that for now can have the value >> "strict". >> If that's present, the new SLING-8110 code takes into account the >> sling.servlet.extensions and sling.servlet.methods properties, if >> present, for a servlet that has a sling.servlet.paths property. >> If sling.servlet.resolution is not set, the resolution behaves as it does >> today. >> WDYT? >> -Bertrand >> (*) As Konrad notes at SLING-8110 the latest annotations make it >> harder to have such ignored properties, but technically nothing >> prevents them from being present > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
