You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2019/12/03 14:54:09 UTC
sling.servlet.resolution = strict ?
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
Re: sling.servlet.resolution = strict ?
Posted by Carsten Ziegeler <cz...@apache.org>.
Works for me, too
Carsten
On 28.01.2020 11:20, Bertrand Delacretaz wrote:
> Hi Radu,
>
> On Tue, Jan 28, 2020 at 5:39 PM Radu Cotescu <ra...@apache.org> wrote:
>>> On 28 Jan 2020, at 17:20, Bertrand Delacretaz <bd...@apache.org> wrote:
>>> ... sling.servlet.extpaths = true..
>>>
>> What about “sling.servlet.paths.strict”? A value of false (default) keeps the previous behaviour...
>
> That's indeed a good idea, my favorite so far.
>
> -Bertrand
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: sling.servlet.resolution = strict ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Radu,
On Tue, Jan 28, 2020 at 5:39 PM Radu Cotescu <ra...@apache.org> wrote:
> > On 28 Jan 2020, at 17:20, Bertrand Delacretaz <bd...@apache.org> wrote:
> > ... sling.servlet.extpaths = true..
> >
> What about “sling.servlet.paths.strict”? A value of false (default) keeps the previous behaviour...
That's indeed a good idea, my favorite so far.
-Bertrand
Re: sling.servlet.resolution = strict ?
Posted by Radu Cotescu <ra...@apache.org>.
Hi Bertrand,
> On 28 Jan 2020, at 17:20, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> On Tue, Dec 3, 2019 at 3:54 PM Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> ...For SLING-8110 I'd like to take into account the
>> sling.servlet.extensions and sling.servlet.methods properties...
> ...
>> To keep backwards compatibility, I suggest adding a new optional
>> sling.servlet.resolution property that for now can have the value
>> "strict".
>
> I'm (at last) implementing this. Carsten observed in this thread that
> the meaning of "strict" is not really obvious here so I suggest
> instead:
>
> sling.servlet.extpaths = true
>
What about “sling.servlet.paths.strict”? A value of false (default) keeps the previous behaviour. A value of true means that the other registration properties (extensions, methods, selectors?!) will be taken into consideration.
Thanks,
Radu
Re: sling.servlet.resolution = strict ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Dec 3, 2019 at 3:54 PM Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...For SLING-8110 I'd like to take into account the
> sling.servlet.extensions and sling.servlet.methods properties...
...
> To keep backwards compatibility, I suggest adding a new optional
> sling.servlet.resolution property that for now can have the value
> "strict".
I'm (at last) implementing this. Carsten observed in this thread that
the meaning of "strict" is not really obvious here so I suggest
instead:
sling.servlet.extpaths = true
To activate the SLING-8110 behavior that takes extension, selectors
and HTTP method into account if this property is set on a path-mounted
servlet and if the other existing corresponding properties are set.
This can either mean "extended path-based servlet selection" or
"extension etc. is taken into account".
What do people think?
-Bertrand (oh no - a naming discussion ;-)
Re: sling.servlet.resolution = strict ?
Posted by Konrad Windszus <ko...@gmx.de>.
For b) we can use https://osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/bundle/Requirement.html <https://osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/bundle/Requirement.html> as meta annotation on a new servlet annotation.
That way, bnd will automatically add the according headers to the bundle once such a servlet annotation is found.
Konrad
> On 4. Dec 2019, at 14:42, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> On Wed, Dec 4, 2019 at 11:00 AM Carsten Ziegeler <cz...@apache.org> wrote:
>> ...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....
>
> Thank you Carsten and Konrad for your comments (and Radu for the +1s),
> I agree with the need to be fully backwards compatible and avoid
> surprises. Using OSGi capabilities makes total sense.
>
> I haven't worked much with OSGi capabilities, can you confirm my
> understanding of how they should be used and generated?
>
> We can discuss separately whether "strict" is the right base name.
> Naming is hard ;-)
>
> 1) When this is implemented, the o.a.s.servlets.resolver bundle gets
> an additional (static, in pom.xml) value for its Provide-Capability
> header. Suggested value:
>
> org.apache.sling.servlets.resolver;strict.mode.support:Version=1.0.0
>
> 2) The bnd functionality is modified to add the corresponding
> Require-Capability header (require strict.mode.support >= 1.0.0) when
> building bundles that contain at least one servlet with both a
> sling.servlet.paths and a sling.servlet.resolution service property.
> At this stage I don't know where this needs to be implemented.
>
> -Bertrand
>
> (note to self; https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#d0e2821
> is the Capabilities spec)
Re: sling.servlet.resolution = strict ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 4, 2019 at 2:48 PM Carsten Ziegeler <cz...@apache.org> wrote:
> Am 04.12.2019 um 14:42 schrieb Bertrand Delacretaz:
> >... org.apache.sling.servlets.resolver;strict.mode.support:Version=1.0.0
> >
>
>... osgi.extender;osgi.extender="org.apache.sling.servlets.resolver";version:Version="1.1"
Your variant is simpler indeed, just increment the servlets.resolver
version capability.
> ...I think, what we can do is provide a new version of the sling servlet
> annotations which provide the new mode property. And if these
> annotations are used, we require version 1.1 of the capability...
Makes sense - it won't cover cases where people set the service
properties without using the annotations, but in such a case it's fair
to expect them to also set the Require-Capability accordingly.
Thanks for your input, I think I'm all set for now!
-Bertrand
Re: sling.servlet.resolution = strict ?
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 04.12.2019 um 14:42 schrieb Bertrand Delacretaz:
>
> We can discuss separately whether "strict" is the right base name.
> Naming is hard ;-)
>
:)
> 1) When this is implemented, the o.a.s.servlets.resolver bundle gets
> an additional (static, in pom.xml) value for its Provide-Capability
> header. Suggested value:
>
> org.apache.sling.servlets.resolver;strict.mode.support:Version=1.0.0
>
That's one option. The other option is to increase the version for the
already existing capability.
Right now the bundle provides:
osgi.extender;osgi.extender="org.apache.sling.servlets.resolver";version:Version="1.0"
As we're adding new functionality, we could update that to
osgi.extender;osgi.extender="org.apache.sling.servlets.resolver";version:Version="1.1"
Existing bundles continue to work (they should require version 1.0),
new/updated bundles making use of the new functionality, should require
version 1.1.
I'm saying "should" here as we can't enfore it in all cases.
> 2) The bnd functionality is modified to add the corresponding
> Require-Capability header (require strict.mode.support >= 1.0.0) when
> building bundles that contain at least one servlet with both a
> sling.servlet.paths and a sling.servlet.resolution service property.
> At this stage I don't know where this needs to be implemented.
>
I'm not sure if that is possible. If so, that would be nice.
I think, what we can do is provide a new version of the sling servlet
annotations which provide the new mode property. And if these
annotations are used, we require version 1.1 of the capability.
Now, that means - regardless of the value used for the mode (strict or
default) - the newer resolver bundle is required; but that's probably
fine as the only reason to update to the new annotations is to use the
new functionality.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: sling.servlet.resolution = strict ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 4, 2019 at 11:00 AM Carsten Ziegeler <cz...@apache.org> wrote:
> ...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....
Thank you Carsten and Konrad for your comments (and Radu for the +1s),
I agree with the need to be fully backwards compatible and avoid
surprises. Using OSGi capabilities makes total sense.
I haven't worked much with OSGi capabilities, can you confirm my
understanding of how they should be used and generated?
We can discuss separately whether "strict" is the right base name.
Naming is hard ;-)
1) When this is implemented, the o.a.s.servlets.resolver bundle gets
an additional (static, in pom.xml) value for its Provide-Capability
header. Suggested value:
org.apache.sling.servlets.resolver;strict.mode.support:Version=1.0.0
2) The bnd functionality is modified to add the corresponding
Require-Capability header (require strict.mode.support >= 1.0.0) when
building bundles that contain at least one servlet with both a
sling.servlet.paths and a sling.servlet.resolution service property.
At this stage I don't know where this needs to be implemented.
-Bertrand
(note to self; https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#d0e2821
is the Capabilities spec)
Re: sling.servlet.resolution = strict ?
Posted by Radu Cotescu <ra...@apache.org>.
+1
> On 4 Dec 2019, at 11:00, Carsten Ziegeler <cz...@apache.org> wrote:
>
> 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.
Re: sling.servlet.resolution = strict ?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@apache.org> 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
>> cziegeler@apache.org
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: sling.servlet.resolution = strict ?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@apache.org> 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
> cziegeler@apache.org
Re: sling.servlet.resolution = strict ?
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: sling.servlet.resolution = strict ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Radu,
On Tue, Dec 3, 2019 at 4:44 PM Radu Cotescu <ra...@apache.org> wrote:
> > On 3 Dec 2019, at 15:54, Bertrand Delacretaz <bd...@apache.org> wrote:
> > To keep backwards compatibility, I suggest adding a new optional
> > sling.servlet.resolution property ...
> ...Do we only want this property at the servlet level? I’d probably also add it to the platform and allow it to be configured
> globally as well. By default the engine should work like before...
Good point, the servlet resolution module should be configurable to
make "strict" the default.
-Bertrand
Re: sling.servlet.resolution = strict ?
Posted by Radu Cotescu <ra...@apache.org>.
Hi Bertrand,
> On 3 Dec 2019, at 15:54, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> 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?
Do we only want this property at the servlet level? I’d probably also add it to the platform and allow it to be configured globally as well. By default the engine should work like before.
Regards,
Radu
Re: sling.servlet.resolution = strict ?
Posted by Konrad Windszus <ko...@gmx.de>.
Hi,
In general I like the suggestion, but issues are hard to debug in case a servlet leverages the new feature but the servlet resolver doesn‘t support it. Can’t we work with Require/Provide Capability for that?
Konrad
> Am 03.12.2019 um 15:54 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
> 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