Re: SLING-11974: Spec Compliance vs. Backward compatibility
I added the switch. If anyone wants improvements to this, please directly commit or PR Thanks Carsten On 21.07.2023 06:32, Carsten Ziegeler wrote: Sure, we can make this configurable. Nevertheless, I strongly suggest everyone to not rely on this method returning null for the anonymous case and rather use the other two methods - which always behaved spec compliant. Otherwise you might run into trouble once you combine two sources of code where one is expecting the spec compliant behaviour and the other one is not. From experience, this will sooner or later happen Regards Carsten On 20.07.2023 19:20, Eric Norman wrote: 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 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 -- Carsten Ziegeler Adobe cziege...@apache.org
Re: SLING-11974: Spec Compliance vs. Backward compatibility
Sure, we can make this configurable. Nevertheless, I strongly suggest everyone to not rely on this method returning null for the anonymous case and rather use the other two methods - which always behaved spec compliant. Otherwise you might run into trouble once you combine two sources of code where one is expecting the spec compliant behaviour and the other one is not. From experience, this will sooner or later happen Regards Carsten On 20.07.2023 19:20, Eric Norman wrote: 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 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 -- Carsten Ziegeler Adobe cziege...@apache.org
[jira] [Commented] (SLING-11975) org.apache.sling.launchpad.base.jar fails to load on jdk 11.0.20 because it has malformed Zip64 extra fields
[
https://issues.apache.org/jira/browse/SLING-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745285#comment-17745285
]
Mark Adamcin commented on SLING-11975:
--
[~rombert] [~cziegeler] Would one of you be able to review this?
> org.apache.sling.launchpad.base.jar fails to load on jdk 11.0.20 because it
> has malformed Zip64 extra fields
>
>
> Key: SLING-11975
> URL: https://issues.apache.org/jira/browse/SLING-11975
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
>Affects Versions: Launchpad Base 2.7.6
>Reporter: Mark Adamcin
>Priority: Critical
> Labels: has-pr
>
> I ran into an error when trying to run AEM quickstart locally after upgrading
> my jdk to 11.0.20 ([release
> notes|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html]):
> {quote}core-libs/java.util.jar
> *[➜|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html#JDK-8302483]*
> *Improved ZIP64 Extra Field Validation* (JDK-8302483 (not
> public)){{{}java.util.zip.ZipFile{}}} has been updated to provide additional
> validation of ZIP64 extra fields when opening a ZIP file. This validation may
> be disabled by setting the system property
> {{jdk.util.zip.disableZip64ExtraFieldValidation}} to {{{}true{}}}.{quote}
> it manifested for me as an exception in {{logs/stderr.log}} :
> {code:java}
> 20.07.2023 07:59:22.568 *ERROR* [main] Cannot launch: Cannot install
> jar:file:/opt/code/aem/quickstart/target/author-54594/crx-quickstart/app/cq-quickstart-6.6.0-SNAPSHOT-standalone-quickstart.jar!/resources/org.apache.sling.launchpad.base.jar
> for use
> 20.07.2023 07:59:22.568 *ERROR* [main] java.util.zip.ZipException: Invalid
> CEN header (invalid zip64 extra data field size)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1736)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.checkExtraFields(ZipFile.java:1254)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1701)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1430)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1393)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:742)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:859)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile.(ZipFile.java:257)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile.(ZipFile.java:186)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:348)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:319)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:285)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.commons.osgi.bundleversion.FileBundleVersionInfo.(FileBundleVersionInfo.java:40)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.base.shared.Loader.installLauncherJar(Loader.java:172)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.app.Main.doStart(Main.java:382)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.app.Main.doStart(Main.java:347)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.exec.Bootstrap.run(Bootstrap.java:107)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Quickstart.run(Quickstart.java:272)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Main.(Main.java:918)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Main.main(Main.java:980)
> MAIN process: shutdown hook
> MAIN process: exiting {code}
> This appears to be an issue with the org.apache.sling.launchpad.base
> 7.0.3-2.7.6 jar specifically:
> {code:java}
> $ jar -tf
>
[jira] [Updated] (SLING-11975) org.apache.sling.launchpad.base.jar fails to load on jdk 11.0.20 because it has malformed Zip64 extra fields
[
https://issues.apache.org/jira/browse/SLING-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Adamcin updated SLING-11975:
-
Labels: has-pr (was: )
> org.apache.sling.launchpad.base.jar fails to load on jdk 11.0.20 because it
> has malformed Zip64 extra fields
>
>
> Key: SLING-11975
> URL: https://issues.apache.org/jira/browse/SLING-11975
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
>Affects Versions: Launchpad Base 2.7.6
>Reporter: Mark Adamcin
>Priority: Critical
> Labels: has-pr
>
> I ran into an error when trying to run AEM quickstart locally after upgrading
> my jdk to 11.0.20 ([release
> notes|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html]):
> {quote}core-libs/java.util.jar
> *[➜|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html#JDK-8302483]*
> *Improved ZIP64 Extra Field Validation* (JDK-8302483 (not
> public)){{{}java.util.zip.ZipFile{}}} has been updated to provide additional
> validation of ZIP64 extra fields when opening a ZIP file. This validation may
> be disabled by setting the system property
> {{jdk.util.zip.disableZip64ExtraFieldValidation}} to {{{}true{}}}.{quote}
> it manifested for me as an exception in {{logs/stderr.log}} :
> {code:java}
> 20.07.2023 07:59:22.568 *ERROR* [main] Cannot launch: Cannot install
> jar:file:/opt/code/aem/quickstart/target/author-54594/crx-quickstart/app/cq-quickstart-6.6.0-SNAPSHOT-standalone-quickstart.jar!/resources/org.apache.sling.launchpad.base.jar
> for use
> 20.07.2023 07:59:22.568 *ERROR* [main] java.util.zip.ZipException: Invalid
> CEN header (invalid zip64 extra data field size)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1736)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.checkExtraFields(ZipFile.java:1254)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1701)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1430)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1393)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:742)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:859)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile.(ZipFile.java:257)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.zip.ZipFile.(ZipFile.java:186)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:348)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:319)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.util.jar.JarFile.(JarFile.java:285)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.commons.osgi.bundleversion.FileBundleVersionInfo.(FileBundleVersionInfo.java:40)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.base.shared.Loader.installLauncherJar(Loader.java:172)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.app.Main.doStart(Main.java:382)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> org.apache.sling.launchpad.app.Main.doStart(Main.java:347)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.exec.Bootstrap.run(Bootstrap.java:107)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Quickstart.run(Quickstart.java:272)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Main.(Main.java:918)
> 20.07.2023 07:59:22.568 *ERROR* [main] at
> com.adobe.granite.quickstart.base.impl.Main.main(Main.java:980)
> MAIN process: shutdown hook
> MAIN process: exiting {code}
> This appears to be an issue with the org.apache.sling.launchpad.base
> 7.0.3-2.7.6 jar specifically:
> {code:java}
> $ jar -tf
>
[jira] [Created] (SLING-11975) org.apache.sling.launchpad.base.jar fails to load on jdk 11.0.20 because it has malformed Zip64 extra fields
Mark Adamcin created SLING-11975:
Summary: org.apache.sling.launchpad.base.jar fails to load on jdk
11.0.20 because it has malformed Zip64 extra fields
Key: SLING-11975
URL: https://issues.apache.org/jira/browse/SLING-11975
Project: Sling
Issue Type: Bug
Components: Launchpad
Affects Versions: Launchpad Base 2.7.6
Reporter: Mark Adamcin
I ran into an error when trying to run AEM quickstart locally after upgrading
my jdk to 11.0.20 ([release
notes|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html]):
{quote}core-libs/java.util.jar
*[➜|https://www.oracle.com/java/technologies/javase/11-0-20-relnotes.html#JDK-8302483]*
*Improved ZIP64 Extra Field Validation* (JDK-8302483 (not
public)){{{}java.util.zip.ZipFile{}}} has been updated to provide additional
validation of ZIP64 extra fields when opening a ZIP file. This validation may
be disabled by setting the system property
{{jdk.util.zip.disableZip64ExtraFieldValidation}} to {{{}true{}}}.{quote}
it manifested for me as an exception in {{logs/stderr.log}} :
{code:java}
20.07.2023 07:59:22.568 *ERROR* [main] Cannot launch: Cannot install
jar:file:/opt/code/aem/quickstart/target/author-54594/crx-quickstart/app/cq-quickstart-6.6.0-SNAPSHOT-standalone-quickstart.jar!/resources/org.apache.sling.launchpad.base.jar
for use
20.07.2023 07:59:22.568 *ERROR* [main] java.util.zip.ZipException: Invalid CEN
header (invalid zip64 extra data field size)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1736)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$Source.checkExtraFields(ZipFile.java:1254)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1701)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1430)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1393)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:742)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:859)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile.(ZipFile.java:257)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.zip.ZipFile.(ZipFile.java:186)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.jar.JarFile.(JarFile.java:348)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.jar.JarFile.(JarFile.java:319)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.util.jar.JarFile.(JarFile.java:285)
20.07.2023 07:59:22.568 *ERROR* [main] at
org.apache.sling.commons.osgi.bundleversion.FileBundleVersionInfo.(FileBundleVersionInfo.java:40)
20.07.2023 07:59:22.568 *ERROR* [main] at
org.apache.sling.launchpad.base.shared.Loader.installLauncherJar(Loader.java:172)
20.07.2023 07:59:22.568 *ERROR* [main] at
org.apache.sling.launchpad.app.Main.doStart(Main.java:382)
20.07.2023 07:59:22.568 *ERROR* [main] at
org.apache.sling.launchpad.app.Main.doStart(Main.java:347)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
20.07.2023 07:59:22.568 *ERROR* [main] at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
20.07.2023 07:59:22.568 *ERROR* [main] at
com.adobe.granite.quickstart.base.impl.exec.Bootstrap.run(Bootstrap.java:107)
20.07.2023 07:59:22.568 *ERROR* [main] at
com.adobe.granite.quickstart.base.impl.Quickstart.run(Quickstart.java:272)
20.07.2023 07:59:22.568 *ERROR* [main] at
com.adobe.granite.quickstart.base.impl.Main.(Main.java:918)
20.07.2023 07:59:22.568 *ERROR* [main] at
com.adobe.granite.quickstart.base.impl.Main.main(Main.java:980)
MAIN process: shutdown hook
MAIN process: exiting {code}
This appears to be an issue with the org.apache.sling.launchpad.base
7.0.3-2.7.6 jar specifically:
{code:java}
$ jar -tf
~/.m2/repository/org/apache/sling/org.apache.sling.launchpad.base/7.0.3-2.7.6/org.apache.sling.launchpad.base-7.0.3-2.7.6.jar
java.util.zip.ZipException: Invalid CEN header (invalid zip64 extra data field
size)
at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1736)
at
java.base/java.util.zip.ZipFile$Source.checkExtraFields(ZipFile.java:1254)
at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1701)
at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1430)
at
Re: SLING-11974: Spec Compliance vs. Backward compatibility
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 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
Re: SLING-11974: Spec Compliance vs. Backward compatibility
Good point, I updated them https://github.com/apache/sling-org-apache-sling-api/commit/b76ab7e07c79dab4cd89eb25784848c2f5ad2732 Regards Carsten On 20.07.2023 15:22, Robert Munteanu wrote: +/** + * Returns a java.security.Principal object containing + * the name of the current authenticated user. + * + * Note: This method deviates from the parent interface and never returns null, + * even whenthe user is not authenticated. + * + * @return a java.security.Principal containing + * the name of the user making this request; never + * null + */ +@NotNull +Principal getUserPrincipal(); -- Carsten Ziegeler Adobe cziege...@apache.org
[jira] [Updated] (SLING-11974) Regression caused by SLING-11825 - change in request getUserPrincipal
[ https://issues.apache.org/jira/browse/SLING-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-11974: - Fix Version/s: API 2.27.4 > Regression caused by SLING-11825 - change in request getUserPrincipal > - > > Key: SLING-11974 > URL: https://issues.apache.org/jira/browse/SLING-11974 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.14.0, Engine 2.15.0, Engine 2.15.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: API 2.27.4, Engine 2.15.4 > > > With SLING-11825 getUserPrincipal will always return null for the anonymous > user. While this change is spec compliant it is a change in behaviour which > is actually breaking users of Sling. > Therefore we should revert that change > While in theory we could provide a switch to toggle the behaviour, I don't > think there is very little value to complicate our code and configuration > setup - the old behaviour has been in place for many many years -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [sling-org-apache-sling-graphql-core] sonarcloud[bot] commented on pull request #29: SLING-11458 - fixed a regresssion for the original Ticket SLING-9626
sonarcloud[bot] commented on PR #29: URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/29#issuecomment-1644034452 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-graphql-core=29) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=29=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=29=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-graphql-core=29=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=CODE_SMELL) [1 Code Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-graphql-core=29=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=29=new_coverage=list) [100.0% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=29=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=29=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-graphql-core=29=new_duplicated_lines_density=list) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: SLING-11974: Spec Compliance vs. Backward compatibility
On Thu, 2023-07-20 at 14:34 +0200, Carsten Ziegeler wrote:
> Sure, the question is where?
>
> I looked at our existing docs, and we actually document how to check
> for
> anonymous access. But that is a little bit hidden, embedded in
> outdated
> docs
We can start with the javadoc of the interface, something like
diff --git
a/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
b/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
index 776e613..fa32b59 100644
--- a/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
+++ b/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
@@ -18,6 +18,7 @@
*/
package org.apache.sling.api;
+import java.security.Principal;
import java.util.Enumeration;
import java.util.List;
import java.util.Locale;
@@ -274,4 +275,18 @@ public interface SlingHttpServletRequest extends
HttpServletRequest, Adaptable {
* @return The request progress tracker.
*/
@NotNull RequestProgressTracker getRequestProgressTracker();
+
+/**
+ * Returns a java.security.Principal object
containing
+ * the name of the current authenticated user.
+ *
+ * Note: This method deviates from the parent
interface and never returns null,
+ * even whenthe user is not authenticated.
+ *
+ * @return a java.security.Principal
containing
+ * the name of the user making this request;
never
+ * null
+ */
+@NotNull
+Principal getUserPrincipal();
}
>
> Regards
> Carsten
>
> On 20.07.2023 13:06, Jörg Hoh wrote:
> > Should we document that in this case we are not spec compliant for
> > backwards compatibility reasons?
> >
> > Am Do., 20. Juli 2023 um 12:53 Uhr schrieb Carsten Ziegeler <
> > cziege...@apache.org>:
> >
> > > I think there is no one solution fits all here. As always it
> > > depends.
> > >
> > > In general we should try to be spec compliant - unless there is a
> > > good
> > > reason not to. There could be different reasons.
> > >
> > > In this particular case, imho there is a good reason to not be
> > > compliant. We have a huge user base and the non spec compliant
> > > behaviour
> > > is in there for many many years. There is a chance that some of
> > > our
> > > users rely on this behaviour. If we change it, we break our
> > > users. Which
> > > actually happened in this case.
> > >
> > > In addition, in this case if users are trying out our non spec
> > > compliant
> > > method they will immediately see that it is not compliant during
> > > development/testing.
> > >
> > > Regards
> > > Carsten
> > >
> > > On 20.07.2023 12:28, Konrad Windszus 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
> > >
> > > --
> > > Carsten Ziegeler
> > > Adobe
> > > cziege...@apache.org
> > >
> >
> >
>
Re: Integration problem Eclipse <> Sling 12
Hi Juerg, It would help, if you can try testing the latest SNAPSHOT as outlined in https://sling.apache.org/documentation/development/ide-tooling.html#update-site-installation (there is a p2 update site at https://nightlies.apache.org/sling/eclipse/) The upcoming version has lots of issues fixed (including compatibility with newer Eclipse versions): https://issues.apache.org/jira/projects/SLING/versions/12342835 Let us know if you encounter issues not yet reported Thanks, Konrad > On 20. Jul 2023, at 14:05, JCR wrote: > > On 18.07.23 16:06, JCR wrote: >> Hello >> >> I run Sling 12 docker oak-tar on an Ubuntu Server. >> >> Connecting to it with Eclipse, I've seen the pretty weirdest thing ever. The >> Eclipse plugin 1.2.2, tested with Eclipse versions 2020-03, 2021-03 and >> 2022-03 (on 2023-03, the plugin turned out to be not installable), both on >> Win11 and Ubuntu 22/04 clients, are far from working properly with the >> mentioned server instance. >> >> Creating in Eclipse a folder and subsequently creating, say, a JSP and an >> HTL file, one seeming deletes the other upon saving it the Sling server. >> For example, I have content.html and edit.jsp in the same folder. When >> saving content.html, then edit.jsp would disappear on the server. It takes >> an extra "Send to Sling Server..." cmd in Eclipse on edit.jsp in order to >> re-create it on the server. >> >> No error reporting or any other indication of a problem is given... Hence, I >> frankly wonder what causes the problem. >> >> Any hints or similar experiences out there? >> >> Thanks, >> Juerg >> > Solved, but... > > After testing several Eclipse versions and, testwise, connecting even to a > Sling11 instance, all these settings resulted in the same erratic behaviour > described above. Hence, I finally decided to remove the entire project from > eclipse and rebuild it. That solved the problem. > > The cause for this is hard to identify as no error messages or the like were > given. But I must assume that it is a compatibility issue between Eclipse > 2023-03 and the Sling 1.2.2 plugin which was used to originally build the > project. The Sling plugin 1.2.2 has come into its years and compatibility > issues with Eclipse 2023-03 showed up at installation time already... So I > wonder who in the DEV community maintains the plugin, looks like it requires > an update urgently. > > Best, > Juerg >
Re: SLING-11974: Spec Compliance vs. Backward compatibility
Hi, yes I'm heavily opting for 2) :) you know I initially approved your PR thinking that this should not break any of Sling's users. Well, today I know that this assumption was wrong. I know of several users which currently rely on the wrong behaviour - and changing it breaks them. The longer a behaviour exists the more likely it is used by someone. As there are other means to check for an anonymous request and we have at least one documented and the other one used throughout the code base, I think it is in this case more important to not break our users. Of course as Jörg pointed out we should somehow document this. Regards Carsten On 20.07.2023 14:37, Konrad Windszus wrote: On 20. Jul 2023, at 12:53, Carsten Ziegeler wrote: I think there is no one solution fits all here. As always it depends. Yes, I agree with that. I was referring to this specific use case. In general we should try to be spec compliant - unless there is a good reason not to. There could be different reasons. In this particular case, imho there is a good reason to not be compliant. We have a huge user base and the non spec compliant behaviour is in there for many many years. There is a chance that some of our users rely on this behaviour. If we change it, we break our users. Which actually happened in this case. The argument for how long a bug does exist does not matter to much to me TBH, let us always strive to improve/fix things. Also if we break some customer this does not necessarily warrant that we don’t fix stuff, if the custom code in this case if clearly relying on spec incompatible behaviour. In addition, in this case if users are trying out our non spec compliant method they will immediately see that it is not compliant during development/testing. Not necessarily this is caught during tests (although I agree it should be). I stumbled upon this and it costed me some time to figure this out. Also this will be reported otherwise again (for good reasons) But I see, that you are opting for 2) in this case :-) Konrad Regards Carsten On 20.07.2023 12:28, Konrad Windszus 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 -- Carsten Ziegeler Adobe cziege...@apache.org -- Carsten Ziegeler Adobe cziege...@apache.org
Re: SLING-11974: Spec Compliance vs. Backward compatibility
> On 20. Jul 2023, at 12:53, Carsten Ziegeler wrote: > > I think there is no one solution fits all here. As always it depends. Yes, I agree with that. I was referring to this specific use case. > > In general we should try to be spec compliant - unless there is a good reason > not to. There could be different reasons. > > In this particular case, imho there is a good reason to not be compliant. We > have a huge user base and the non spec compliant behaviour is in there for > many many years. There is a chance that some of our users rely on this > behaviour. If we change it, we break our users. Which actually happened in > this case. The argument for how long a bug does exist does not matter to much to me TBH, let us always strive to improve/fix things. Also if we break some customer this does not necessarily warrant that we don’t fix stuff, if the custom code in this case if clearly relying on spec incompatible behaviour. > > In addition, in this case if users are trying out our non spec compliant > method they will immediately see that it is not compliant during > development/testing. Not necessarily this is caught during tests (although I agree it should be). I stumbled upon this and it costed me some time to figure this out. Also this will be reported otherwise again (for good reasons) But I see, that you are opting for 2) in this case :-) Konrad > > Regards > Carsten > > On 20.07.2023 12:28, Konrad Windszus 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 > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org
Re: SLING-11974: Spec Compliance vs. Backward compatibility
Sure, the question is where? I looked at our existing docs, and we actually document how to check for anonymous access. But that is a little bit hidden, embedded in outdated docs Regards Carsten On 20.07.2023 13:06, Jörg Hoh wrote: Should we document that in this case we are not spec compliant for backwards compatibility reasons? Am Do., 20. Juli 2023 um 12:53 Uhr schrieb Carsten Ziegeler < cziege...@apache.org>: I think there is no one solution fits all here. As always it depends. In general we should try to be spec compliant - unless there is a good reason not to. There could be different reasons. In this particular case, imho there is a good reason to not be compliant. We have a huge user base and the non spec compliant behaviour is in there for many many years. There is a chance that some of our users rely on this behaviour. If we change it, we break our users. Which actually happened in this case. In addition, in this case if users are trying out our non spec compliant method they will immediately see that it is not compliant during development/testing. Regards Carsten On 20.07.2023 12:28, Konrad Windszus 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 -- Carsten Ziegeler Adobe cziege...@apache.org -- Carsten Ziegeler Adobe cziege...@apache.org
Re: Integration problem Eclipse <> Sling 12
On 18.07.23 16:06, JCR wrote: Hello I run Sling 12 docker oak-tar on an Ubuntu Server. Connecting to it with Eclipse, I've seen the pretty weirdest thing ever. The Eclipse plugin 1.2.2, tested with Eclipse versions 2020-03, 2021-03 and 2022-03 (on 2023-03, the plugin turned out to be not installable), both on Win11 and Ubuntu 22/04 clients, are far from working properly with the mentioned server instance. Creating in Eclipse a folder and subsequently creating, say, a JSP and an HTL file, one seeming deletes the other upon saving it the Sling server. For example, I have content.html and edit.jsp in the same folder. When saving content.html, then edit.jsp would disappear on the server. It takes an extra "Send to Sling Server..." cmd in Eclipse on edit.jsp in order to re-create it on the server. No error reporting or any other indication of a problem is given... Hence, I frankly wonder what causes the problem. Any hints or similar experiences out there? Thanks, Juerg Solved, but... After testing several Eclipse versions and, testwise, connecting even to a Sling11 instance, all these settings resulted in the same erratic behaviour described above. Hence, I finally decided to remove the entire project from eclipse and rebuild it. That solved the problem. The cause for this is hard to identify as no error messages or the like were given. But I must assume that it is a compatibility issue between Eclipse 2023-03 and the Sling 1.2.2 plugin which was used to originally build the project. The Sling plugin 1.2.2 has come into its years and compatibility issues with Eclipse 2023-03 showed up at installation time already... So I wonder who in the DEV community maintains the plugin, looks like it requires an update urgently. Best, Juerg
Re: SLING-11974: Spec Compliance vs. Backward compatibility
Should we document that in this case we are not spec compliant for backwards compatibility reasons? Am Do., 20. Juli 2023 um 12:53 Uhr schrieb Carsten Ziegeler < cziege...@apache.org>: > I think there is no one solution fits all here. As always it depends. > > In general we should try to be spec compliant - unless there is a good > reason not to. There could be different reasons. > > In this particular case, imho there is a good reason to not be > compliant. We have a huge user base and the non spec compliant behaviour > is in there for many many years. There is a chance that some of our > users rely on this behaviour. If we change it, we break our users. Which > actually happened in this case. > > In addition, in this case if users are trying out our non spec compliant > method they will immediately see that it is not compliant during > development/testing. > > Regards > Carsten > > On 20.07.2023 12:28, Konrad Windszus 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 > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
Re: SLING-11974: Spec Compliance vs. Backward compatibility
I think there is no one solution fits all here. As always it depends. In general we should try to be spec compliant - unless there is a good reason not to. There could be different reasons. In this particular case, imho there is a good reason to not be compliant. We have a huge user base and the non spec compliant behaviour is in there for many many years. There is a chance that some of our users rely on this behaviour. If we change it, we break our users. Which actually happened in this case. In addition, in this case if users are trying out our non spec compliant method they will immediately see that it is not compliant during development/testing. Regards Carsten On 20.07.2023 12:28, Konrad Windszus 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 -- Carsten Ziegeler Adobe cziege...@apache.org
SLING-11974: Spec Compliance vs. Backward compatibility
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
Re: [VOTE] Release Apache Sling Auth Core 1.6.2
+1 Am Do., 20. Juli 2023 um 07:19 Uhr schrieb Carsten Ziegeler < cziege...@apache.org>: > Hi, > > We solved 1 issue in this release: > https://issues.apache.org/jira/browse/SLING-11867 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2771 > > You can use this UNIX script to download the release and verify the > signatures: > > https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 2771 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
RE: [VOTE] Release Apache Sling Auth Core 1.6.2
+1 stefan
Re: [VOTE] Release Apache Sling GraphQL Core 0.0.22
+1 (non-binding) Thank to Radu for cutting the release for me due to my travel. - Andy > On Jul 20, 2023, at 9:49 AM, Radu Cotescu wrote: > > Hi, > > We solved 1 issue in this release: > https://issues.apache.org/jira/browse/SLING/fixforversion/12353082 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2772/ > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2772 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards, > Radu Cotescu
[VOTE] Release Apache Sling GraphQL Core 0.0.22
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12353082 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2772/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2772 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards, Radu Cotescu
[jira] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout
[ https://issues.apache.org/jira/browse/SLING-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10901: - Fix Version/s: GraphQL Core 0.0.24 (was: GraphQL Core 0.0.22) > Allow terminating a GraphQL query after a configured timeout > > > Key: SLING-10901 > URL: https://issues.apache.org/jira/browse/SLING-10901 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.24 > > > Since expensive GraphQL queries could lead to a DoS attack, it would be worth > allowing a system administrator to configure the maximum execution time of a > query. When a long running query is interrupted, the returned error should be > transparent for the GraphQL engine, so that the client knows exactly why the > query failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11920) Expose Object Type Names in Selected Field
[
https://issues.apache.org/jira/browse/SLING-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11920.
--
Resolution: Fixed
> Expose Object Type Names in Selected Field
> --
>
> Key: SLING-11920
> URL: https://issues.apache.org/jira/browse/SLING-11920
> Project: Sling
> Issue Type: Bug
>Affects Versions: GraphQL Core 0.0.20
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Critical
> Fix For: GraphQL Core 0.0.22
>
>
> Intermediary fields are not exposed as Selected Fields in Graphql-java and so
> it was added as list of Object Type Name.
> Now for handling '... on ' we need to expose these Object Type
> Names so that a client can deal with them.
> If we have a query where we have a inline fragments
> ([https://graphql.org/learn/queries/#inline-fragments]) like:
> {code:java}
> {
>image {
> ... on ImageRef {
> type{code}
> Then in the graphql-java 15.0 there is an inlined field called *ImageRef* but
> that is now gone in 20.1. Instead we have a list of Object Type Names in a
> field and in our example *type* would have Objet Type Names:
> {*}["ImageRef"]{*}. So for a client to obtain the type of the inlined
> fragments this data must be exposed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [sling-org-apache-sling-graphql-core] schaefa merged pull request #36: SLING-11920 - Expose Object Type Names as replacement for Inlined Fragments
schaefa merged PR #36: URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/36 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Release Apache Sling Auth Core 1.6.2
On Thu, 2023-07-20 at 07:19 +0200, Carsten Ziegeler wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
