Carsten, unfortunately, it seems that the problem is more complicated than how you have described it. There have been 2 public releases of org.apache.sling.engine with the fix from SLING-11825 included. People (including me) have already migrated to those releases and made changes to their code to compensate for that difference and if you change it back to the previous way then we have to revert those changes again. I shouldn't have to revert spec compliant code to be bug compatible with someone else's old (and wrong) code.
Why can't you just temporarily make the behavior configurable in the near term? Default to the #2 behavior if that is the most common scenario and then declare that the old behavior is deprecated. If the configuration resolves to #2 then simply log a warning about usage of the non-spec behavior and indicate that the wrong behavior may be removed in some future release. This log message and perhaps some hints in the README or other documentation can nudge the community toward changing their code to use the spec compliant behavior. Regards, -Eric On Thu, Jul 20, 2023 at 3:28 AM Konrad Windszus <k...@apache.org> wrote: > Hi, > Carsten just reverted the fix from > https://issues.apache.org/jira/browse/SLING-11825 in > https://issues.apache.org/jira/browse/SLING-11974. > The fix is correct according to the Servlet Spec, but it seems some > customer rely on Sling behaving not spec compliant here. > The question is what weighs more: > 1) Spec compliance to make it easier for most new/existing users as > otherwise behaviour differs from Javadoc and underlying Spec. > 2) Backwards compatibility for those users who rely on this spec > incompatibility. > > > In my opinion I would clearly go for 1) but I would like to hear other > opinions. > > Thanks, > Konrad
