With compatibility I mean that existing code(servlets) work as before,
even if they specified the extensions/methods properties that are
ignored today.
Bertrand's proposal covers that.
And yes, we should rely on capabilities. The servlets resolver bundle
already provides such a capability, so we can build on that one.
If developers use the annotations, we can use the bnd functionality to
automatically generate the requirement if the annotation using the new
functionality is used.
Regards
Carsten
Am 04.12.2019 um 10:33 schrieb Konrad Windszus:
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]
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
