[jira] [Updated] (SLING-9478) Expose the full stack trace for PostConstruct exceptions
[
https://issues.apache.org/jira/browse/SLING-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9478:
Fix Version/s: (was: Sling Models Impl 1.4.16)
Sling Models Impl 1.4.18
> Expose the full stack trace for PostConstruct exceptions
>
>
> Key: SLING-9478
> URL: https://issues.apache.org/jira/browse/SLING-9478
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.18
>
>
> Currently any InvocationTargetException is stripped in
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/80b1dea63615ea5be8252241d6147bce9552fa8e/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L756
> as it is replaced by the more generic PostConstruct exception stripping the
> the reflection part of the call stack.
> That may lead to exceptions like
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> Identifier cannot be correctly instantiated by the Use API
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:227)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> com.adobe.cq.sightly.internal.extensions.IncludeExtension.call(IncludeExtension.java:72)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.header_html.render(header_html.java:41)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 198 common frames omitted
> Caused by: org.apache.sling.api.SlingException: Cannot get
> DefaultSlingScript: Identifier cannot be correctly instantiated by
> the Use API
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:510)
> [org.apache.sling.scripting.core:2.0.56]
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:222)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> ... 206 common frames omitted
> Caused by: org.apache.sling.scripting.sightly.SightlyException: Identifier
> cannot be correctly instantiated by the Use API
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.content_html.render(content_html.java:43)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 207 common frames omitted
> Caused by: org.apache.sling.models.factory.PostConstructException:
> Post-construct method has thrown an exception for model class
> at
> org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:774)
[jira] [Updated] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
[
https://issues.apache.org/jira/browse/SLING-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9674:
Fix Version/s: (was: Sling Models Impl 1.4.16)
Sling Models Impl 1.4.18
Sling Models Impl 1.4.18
> Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
> -
>
> Key: SLING-9674
> URL: https://issues.apache.org/jira/browse/SLING-9674
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.18
>
>
> The {{ChildResourceInjector}} always returns one/multiple Resource objects
> which makes it impossible to use those return values with another Sling Model
> requiring the adaptable {{SlingHttpServletRequest}}.
> A solution from ACS Commons introduced
> https://adobe-consulting-services.github.io/acs-aem-commons/features/sling-model-injectors/child-resource-from-request/index.html
> in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1920.
> There should be a solution built into Sling which allows for easier Sling
> Model aggregation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-8923) Jackson Sling Model Exporter for application/xml needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8923: Fix Version/s: (was: Sling Models Impl 1.4.16) Sling Models Impl 1.4.18 Sling Models Impl 1.4.18 > Jackson Sling Model Exporter for application/xml needs correct character > encoding > - > > Key: SLING-8923 > URL: https://issues.apache.org/jira/browse/SLING-8923 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Sumanth >Priority: Major > Fix For: Sling Models Impl 1.4.18 > > Attachments: image-2019-12-17-09-18-52-797.png > > > Incorrect Character encoding was identified in the below issue > https://issues.apache.org/jira/browse/SLING-7344 > and the fix was provided only for application/json Content-type. > This issue needs to be fixed even for application/xml type > > Currently, this is being set to iso-8859-1, which would be problem with > Special Characters. > > !image-2019-12-17-09-18-52-797.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9036) Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
[
https://issues.apache.org/jira/browse/SLING-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9036:
Fix Version/s: (was: Sling Models Impl 1.4.16)
Sling Models Impl 1.4.18
Sling Models Impl 1.4.18
> Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
> --
>
> Key: SLING-9036
> URL: https://issues.apache.org/jira/browse/SLING-9036
> Project: Sling
> Issue Type: New Feature
> Components: Sling Models
>Reporter: Henry Kuijpers
>Priority: Major
> Fix For: Sling Models Impl 1.4.18
>
>
> Sling Model:
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> MySlingModel.class)
> class MySlingModel {
> @Inject
> public MySlingModel(@Self SlingHttpServletRequest req) {
> logger.log(req.getResourceBundle().getClass().getName());
> }
> }
> {code}
> Calling code:
> {code:java}
> // req obtained via JSP/HTL
> final SlingHttpServletRequest myWrappedReq = new
> SlingHttpServletRequestWrapper(req) {
> @Override
> public ResourceBundle getResourceBundle() {
> return new MyCustomResourceBundle();
> }
> };
>
> final MySlingModel myModel = myWrappedReq.adaptTo(MySlingModel.class);
> {code}
> I would expect the log file to contain "MyCustomResourceBundle". Instead it
> contains "NullResourceBundle".
> This is because the request is being "unwrapped" when doing the adaptTo()
> call: It keeps on delegating to the wrapped request. This should not have
> happened, i.e. how can we otherwise overwrite (parts of) requests and
> resources?
> See also:
> [https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/wrappers/SlingHttpServletRequestWrapper.java#L147]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9834) [Sling Models] Caching bug with reused Servlet requests
[ https://issues.apache.org/jira/browse/SLING-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9834. - Resolution: Fixed > [Sling Models] Caching bug with reused Servlet requests > --- > > Key: SLING-9834 > URL: https://issues.apache.org/jira/browse/SLING-9834 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.14 >Reporter: Christophe Jelger >Assignee: Radu Cotescu >Priority: Major > Fix For: Sling Models Impl 1.4.16 > > Time Spent: 3h > Remaining Estimate: 0h > > The fix from https://issues.apache.org/jira/browse/SLING-9781 introduces > another unexpected issue because a container like Jetty may reuse > ServletRequest objects, so this means that Sling models might be cached > across different HTTP requests because of the unwrapping introduced by > SLING-9781. > After a quick discussion with [~cziegeler] and [~justin], it is actually best > to use the ServletRequest attributes to store the cached models and avoid any > unwrapping. > I'll provide a PR with a fix. > cc: [~radu] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9834) [Sling Models] Caching bug with reused Servlet requests
[ https://issues.apache.org/jira/browse/SLING-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-9834: --- Assignee: Radu Cotescu > [Sling Models] Caching bug with reused Servlet requests > --- > > Key: SLING-9834 > URL: https://issues.apache.org/jira/browse/SLING-9834 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.4.14 >Reporter: Christophe Jelger >Assignee: Radu Cotescu >Priority: Major > Fix For: Sling Models Impl 1.4.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The fix from https://issues.apache.org/jira/browse/SLING-9781 introduces > another unexpected issue because a container like Jetty may reuse > ServletRequest objects, so this means that Sling models might be cached > across different HTTP requests because of the unwrapping introduced by > SLING-9781. > After a quick discussion with [~cziegeler] and [~justin], it is actually best > to use the ServletRequest attributes to store the cached models and avoid any > unwrapping. > I'll provide a PR with a fix. > cc: [~radu] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9755) Make annotation parsing in ModelPackageBundleListener.analyzeClass() more lenient
[
https://issues.apache.org/jira/browse/SLING-9755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9755.
---
> Make annotation parsing in ModelPackageBundleListener.analyzeClass() more
> lenient
> -
>
> Key: SLING-9755
> URL: https://issues.apache.org/jira/browse/SLING-9755
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I have seen an exception like this
> {code}
> [ERROR] myPackage.MyTest.testMethod Time elapsed: 0.052 s <<< ERROR!
> java.lang.annotation.AnnotationFormatError: Invalid default: public abstract
> java.lang.Class com.adobe.granite.haf.annotations.ApiModel.modelLookup()
> at java.lang.reflect.Method.getDefaultValue(Method.java:612)
> at
> sun.reflect.annotation.AnnotationType.(AnnotationType.java:132)
> at
> sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:85)
> at
> sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:266)
> at
> sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120)
> at
> sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
> at java.lang.Class.createAnnotationData(Class.java:3521)
> at java.lang.Class.annotationData(Class.java:3510)
> at java.lang.Class.getAnnotation(Class.java:3415)
> at
> org.apache.sling.models.impl.ModelPackageBundleListener.analyzeClass(ModelPackageBundleListener.java:145)
> at
> org.apache.sling.models.impl.ModelPackageBundleListener.addingBundle(ModelPackageBundleListener.java:125)
> at
> org.apache.sling.models.impl.ModelPackageBundleListener.addingBundle(ModelPackageBundleListener.java:52)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:420)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.sendBundleEvent(MockBundleContext.java:383)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.sendBundleEvent(MockOsgi.java:62)
> at
> org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.addModelsForPackages(ModelAdapterFactoryUtil.java:95)
> at
> org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.addModelsForManifestEntries(ModelAdapterFactoryUtil.java:128)
> at
> org.apache.sling.testing.mock.sling.context.SlingContextImpl.registerDefaultServices(SlingContextImpl.java:187)
> at
> io.wcm.testing.mock.aem.context.AemContextImpl.registerDefaultServices(AemContextImpl.java:67)
> at
> org.apache.sling.testing.mock.sling.context.SlingContextImpl.setUp(SlingContextImpl.java:131)
> at
> io.wcm.testing.mock.aem.context.AemContextImpl.setUp(AemContextImpl.java:94)
> at
> io.wcm.testing.mock.aem.junit.AemContext.access$100(AemContext.java:49)
> at
> io.wcm.testing.mock.aem.junit.AemContext$1.before(AemContext.java:183)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at
> org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.evaluateStatement(PowerMockJUnit47RunnerDelegateImpl.java:107)
> at
> org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82)
> at
> org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:298)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50)
> at
> org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:218)
> at
> org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:160)
> at
>
[jira] [Closed] (SLING-8858) Model Cache causes NPE in sling.models.impl 1.4.10+
[
https://issues.apache.org/jira/browse/SLING-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-8858.
---
> Model Cache causes NPE in sling.models.impl 1.4.10+
> ---
>
> Key: SLING-8858
> URL: https://issues.apache.org/jira/browse/SLING-8858
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.10
> Environment: Java SE 1.8.0_231
>Reporter: Frank Pauleickhoff
>Assignee: Dan Klco
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In AEM 6.4 ServicePack 6 we face NullPointerExceptions when using the Sling
> model cache that used to work before (in SP 3).
> *Exception Stacktrace is:*
> {code:java}
> 22.11.2019 15:29:22.525 *ERROR* [127.0.0.1 [1574432957337] GET
> /content/mypage.html HTTP/1.1]
> org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> SlingException
> org.apache.sling.scripting.sightly.SightlyException:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> Identifier xx.xxx.MyModel cannot be correctly instantiated by the Use API
> [...]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.sling.models.impl.ModelAdapterFactory.internalCreateModel(ModelAdapterFactory.java:407)
> at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:314)
> {code}
> Problem seems to be related to introduction of WeakReferences in SLING-7586.
> Without knowing any details and being deeply into the Sling Model Caching
> implementation, I think a null-check is missing for "SoftReference" in Line
> 407:
> {code:java}
> SoftReference SoftReference = adaptableCache.get(requestedType);
> ModelType cachedObject = (ModelType) SoftReference.get();
> {code}
> That seems to cause caching to throw NPE for any not yet cached model.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9781) [Sling Models] Caching doesn't work with Wrapped requests
[
https://issues.apache.org/jira/browse/SLING-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9781.
---
> [Sling Models] Caching doesn't work with Wrapped requests
> -
>
> Key: SLING-9781
> URL: https://issues.apache.org/jira/browse/SLING-9781
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Christophe Jelger
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The caching of Sling models doesn't work when the original
> {{SlingHttpServletRequest}} is wrapped in a request wrapper, like this is
> typically done in HTL scripts with the {{OnDemandReaderRequest}} wrapper.
> The solution is to use the original request when caching models so that any
> wrapping does not interfere with the caching. When someone enables caching
> for a model adapted from request, I think the expectation is that caching
> does happen whenever the original request is wrapped.
> I'll provide a PR with a fix.
> cc: [~justinedelson] [~radu] as discussed in Slack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9829) data-sly-element should correctly handle void elements
Radu Cotescu created SLING-9829:
---
Summary: data-sly-element should correctly handle void elements
Key: SLING-9829
URL: https://issues.apache.org/jira/browse/SLING-9829
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Compiler 1.2.0-1.4.0, Scripting HTL
Compiler 1.1.0-1.4.0, Scripting HTL Compiler 1.0.0, Scripting Sightly Engine
1.0.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Compiler 1.2.12-1.4.0
The current implementation of {{data-sly-element}} doesn't correctly handle
void elements which will replace the original element on which the block
element was placed:
When {{$\{item.element.name}}} evaluates to {{link}} or {{meta}}, the element
will have a closing tag in the following example, although both {{link}} and
{{meta}} are void elements:
{code:html}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9816) Lookup jsp includes from the class path if not found locally
[ https://issues.apache.org/jira/browse/SLING-9816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9816. - Resolution: Fixed Implemented in [commit 3b994fe|https://github.com/apache/sling-jspc-maven-plugin/commit/3b994fe152b8df8e62164a43f73f105158f87588]. > Lookup jsp includes from the class path if not found locally > > > Key: SLING-9816 > URL: https://issues.apache.org/jira/browse/SLING-9816 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: JSPC Maven Plugin 2.2.2 >Reporter: Karl Pauls >Assignee: Radu Cotescu >Priority: Major > Fix For: JSPC Maven Plugin 2.2.4 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > When compiling a jsp that has an include it would be good if the jspc could > try to find the included jsp from the class path if it doesn't exist locally > (similar to what happens with taglibs). > This way, it would be possible to include jsps coming from a different > project just by adding a dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9493) Upgrade to bnd 5.1.0
[ https://issues.apache.org/jira/browse/SLING-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9493. --- > Upgrade to bnd 5.1.0 > > > Key: SLING-9493 > URL: https://issues.apache.org/jira/browse/SLING-9493 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Bundle Parent 39 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 40 > > > Upgrade to the newest bnd 5.1.0 > ([https://github.com/bndtools/bnd/wiki/Changes-in-5.1.0]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9451) Do not trim stack traces by default
[ https://issues.apache.org/jira/browse/SLING-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9451. --- > Do not trim stack traces by default > --- > > Key: SLING-9451 > URL: https://issues.apache.org/jira/browse/SLING-9451 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Parent 39 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > > Both maven-surefire-plugin and maven-failsafe-plugin should not trim stack > traces > (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace) > by default. For a discussion around that also see > https://issues.apache.org/jira/browse/SUREFIRE-1226. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9775) Improve JaCoCo code coverage setup
[
https://issues.apache.org/jira/browse/SLING-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9775.
---
> Improve JaCoCo code coverage setup
> --
>
> Key: SLING-9775
> URL: https://issues.apache.org/jira/browse/SLING-9775
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control, General
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Parent 40
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> While the parent pom defines a good setup for the JaCoCo Maven Plugin, the
> integration with JaCoCo - configurations for the {{surefire}} and
> {{failsafe}} plugins - has to be performed in each project using the parent
> pom. This leads to inconsistent configurations and sometimes not all coverage
> is correctly reported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9652) Parent: Add ci-management to parent pom
[ https://issues.apache.org/jira/browse/SLING-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9652. --- > Parent: Add ci-management to parent pom > --- > > Key: SLING-9652 > URL: https://issues.apache.org/jira/browse/SLING-9652 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Parent 39 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > > https://maven.apache.org/pom.html#Continuous_Integration_Management -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9796) Add support for using Unions
[
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9796.
-
Resolution: Fixed
Implemented in [commit
16919c9|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/16919c929e31bef083dd5d9c4314a16f9ada5666].
> Add support for using Unions
>
>
> Key: SLING-9796
> URL: https://issues.apache.org/jira/browse/SLING-9796
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Adrian Kozma
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.8
>
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is
> not supporting the *Union* type, however there's a way to implement it.
> 1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3]
> adding the following lines
> - based on the graphql-java documentation [4] the TypeResolver returns the
> schema ObjectType based on the current result item instance
> {code:java}
> List unionTypes =
> typeRegistry.getTypes(UnionTypeDefinition.class);
> for (UnionTypeDefinition type : unionTypes) {
> TypeResolver typeResolver = env -> {
> Object javaObject = env.getObject();
> // schema contains only one union definition:
> // "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
> // hardcoding to force return the object type Type1
> return env.getSchema().getObjectType("Type1");
> };
> builder.type(type.getName(), typeWriting ->
> typeWriting.typeResolver(typeResolver));
> }
> {code}
> 2. General solution
> The suggested solution would be to extend
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external
> callable, following the pattern how it was implemented in case of data
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a
> TypeProvider can decide which Object Type needs to be returned. The condition
> is based on the result item (javaObject) which is constructed by the data
> fetcher (external callable). Therefore, to match the logic, the TypeResolver
> should be callable (OSGI component) which could be detected by directives
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
> name: String,
> options: String = "",
> source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") =
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3]
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
> [4]
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9800) Extract a service to be able to execute GraphQL queries directly
[ https://issues.apache.org/jira/browse/SLING-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212320#comment-17212320 ] Radu Cotescu commented on SLING-9800: - I've improved the API based on your suggestions in [commit 0e0d29d|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/0e0d29da4efda5eec0545fcf76853ab5bef4e2dd]. > Extract a service to be able to execute GraphQL queries directly > > > Key: SLING-9800 > URL: https://issues.apache.org/jira/browse/SLING-9800 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.8 > > > In the current implementation of the GraphQL Core bundle queries can only be > executed via a GraphQL Servlet that needs to be configured or via server-side > scripts. It would be good if the queries could also be executed directly, > without the need for a request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9806) Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
[
https://issues.apache.org/jira/browse/SLING-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9806.
---
> Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
>
>
> Key: SLING-9806
> URL: https://issues.apache.org/jira/browse/SLING-9806
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Commons Johnzon 1.2.6
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{org.apache.sling.commons.johnzon}} is a wrapper over
> {{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
> correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
> that it can still not be deployed as is in Sling, without also deploying
> SPI-Fly - see JOHNZON-108 for context.
> Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in
> a Sling deployment, the OSGi packages that
> {{org.apache.johnzon:johnzon-core}} exports should be re-exported by
> {{org.apache.sling.commons.johnzon}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9800) Extract a service to be able to execute GraphQL queries directly
[ https://issues.apache.org/jira/browse/SLING-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9800. - Resolution: Fixed Implemented in [commit cb4fb76|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/cb4fb76]. > Extract a service to be able to execute GraphQL queries directly > > > Key: SLING-9800 > URL: https://issues.apache.org/jira/browse/SLING-9800 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.8 > > > In the current implementation of the GraphQL Core bundle queries can only be > executed via a GraphQL Servlet that needs to be configured or via server-side > scripts. It would be good if the queries could also be executed directly, > without the need for a request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8738) Trigger an error during build if an API uses a private reference in its public methods' signatures
[
https://issues.apache.org/jira/browse/SLING-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8738:
Fix Version/s: (was: Bundle Parent 40)
Bundle Parent 41
> Trigger an error during build if an API uses a private reference in its
> public methods' signatures
> --
>
> Key: SLING-8738
> URL: https://issues.apache.org/jira/browse/SLING-8738
> Project: Sling
> Issue Type: Improvement
> Components: General
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Bundle Parent 41
>
>
> Following the discussion from https://github.com/bndtools/bnd/issues/3444, we
> should add the provided {{-fixupmessages}} instruction to our bundle parent
> pom, in order to make sure that APIs that we export cannot reference private
> references in their public method signatures.
> This is more of a precaution, rather than a fix for a Sling issue.
> Projects using the bundle parent pom can override the bnd instruction
> locally, if needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9729) Bundle-Parent: Check if resolvable against latest Sling Starter
[ https://issues.apache.org/jira/browse/SLING-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9729: Fix Version/s: (was: Bundle Parent 40) Bundle Parent 41 > Bundle-Parent: Check if resolvable against latest Sling Starter > --- > > Key: SLING-9729 > URL: https://issues.apache.org/jira/browse/SLING-9729 > Project: Sling > Issue Type: Improvement > Components: General >Affects Versions: Bundle Parent 39 >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 41 > > > With SLING-9491 an OSGi repository index is being generated for Sling > Starter. Every bundle should be resolvable against that repository index (to > ensure compatibility with the latest Sling Starter). > To achieve that an approach like in > https://github.com/apache/jackrabbit-filevault/blob/0b3c4cb5a99d14e3d0ae881d7864806ed950c622/parent/pom.xml#L177 > should be used. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9189) release:perform issues [WARNING] The requested profile "pom.xml" could not be activated because it does not exist.
[
https://issues.apache.org/jira/browse/SLING-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9189:
Fix Version/s: (was: Parent 40)
Parent 41
Parent 41
> release:perform issues [WARNING] The requested profile "pom.xml" could not be
> activated because it does not exist.
> --
>
> Key: SLING-9189
> URL: https://issues.apache.org/jira/browse/SLING-9189
> Project: Sling
> Issue Type: Bug
> Components: General
>Affects Versions: Parent 38
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: Parent 41
>
>
> During the {{mvn release:perform}} execution the following line in the log
> can be observed
> {code}
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD SUCCESS
> [INFO] [INFO]
>
> [INFO] [INFO] Total time: 25.851 s
> [INFO] [INFO] Finished at: 2020-03-09T19:59:04+01:00
> [INFO] [INFO]
>
> [INFO] [WARNING] The requested profile "pom.xml" could not be activated
> because it does not exist.
> [INFO] phase cleanup
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9611) Enforce setting the "project.build.outputTimestamp" property
[ https://issues.apache.org/jira/browse/SLING-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9611: Fix Version/s: (was: Parent 40) Parent 41 > Enforce setting the "project.build.outputTimestamp" property > > > Key: SLING-9611 > URL: https://issues.apache.org/jira/browse/SLING-9611 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Parent 41 > > > The property is required for reproducible builds and should therefore be > enforced > ([https://maven.apache.org/guides/mini/guide-reproducible-builds.html#how-do-i-configure-my-maven-build]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-7534: Fix Version/s: (was: Parent 40) Parent 41 Parent 41 > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 41 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9463) Document reproducible builds and check automatically via check-staged-release
[ https://issues.apache.org/jira/browse/SLING-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9463: Fix Version/s: (was: Parent 40) Parent 41 Parent 41 > Document reproducible builds and check automatically via check-staged-release > - > > Key: SLING-9463 > URL: https://issues.apache.org/jira/browse/SLING-9463 > Project: Sling > Issue Type: Improvement > Components: Documentation, General >Reporter: Konrad Windszus >Priority: Major > Fix For: Parent 41 > > > With SLING-9307 and SLING-8951 all builds relying Parent 39 or newer should > be reproducible. Still some parts are missing: > # buildinfo files should be uploaded along with the artifacts > ([https://maven.apache.org/guides/mini/guide-reproducible-builds.html]) which > allows to easily reproduce build (as they contain info about linebreaks and > major JDK versions). > # The check-staged-release.sh should be updated accordingly to optionally > try rebuilding and comparing with the given checksums. > # > [https://sling.apache.org/documentation/development/release-management.html] > should be extended with how to properly check a release after a vote. > # There should be some documentation covering how end-users could reproduce > builds. > # On the downloads page ([https://sling.apache.org/downloads.cgi]) there > should be a link to the buildinfo files for new/reproducible releases > pointing to downloads.apache.org. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9509) Merge all enforcer rules into one execution
[ https://issues.apache.org/jira/browse/SLING-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9509: Fix Version/s: (was: Bundle Parent 40) (was: Parent 40) Parent 41 Parent 41 > Merge all enforcer rules into one execution > --- > > Key: SLING-9509 > URL: https://issues.apache.org/jira/browse/SLING-9509 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Parent 41 > > > Currently each enforcer rule is being enforced in a dedicated execution. > Instead a single execution should enforce all rules. This has two advantages: > # execution is faster > # less output in Maven log -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9796) Add support for using Unions
[
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9796:
---
Assignee: Radu Cotescu
> Add support for using Unions
>
>
> Key: SLING-9796
> URL: https://issues.apache.org/jira/browse/SLING-9796
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Adrian Kozma
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.8
>
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is
> not supporting the *Union* type, however there's a way to implement it.
> 1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3]
> adding the following lines
> - based on the graphql-java documentation [4] the TypeResolver returns the
> schema ObjectType based on the current result item instance
> {code:java}
> List unionTypes =
> typeRegistry.getTypes(UnionTypeDefinition.class);
> for (UnionTypeDefinition type : unionTypes) {
> TypeResolver typeResolver = env -> {
> Object javaObject = env.getObject();
> // schema contains only one union definition:
> // "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
> // hardcoding to force return the object type Type1
> return env.getSchema().getObjectType("Type1");
> };
> builder.type(type.getName(), typeWriting ->
> typeWriting.typeResolver(typeResolver));
> }
> {code}
> 2. General solution
> The suggested solution would be to extend
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external
> callable, following the pattern how it was implemented in case of data
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a
> TypeProvider can decide which Object Type needs to be returned. The condition
> is based on the result item (javaObject) which is constructed by the data
> fetcher (external callable). Therefore, to match the logic, the TypeResolver
> should be callable (OSGI component) which could be detected by directives
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
> name: String,
> options: String = "",
> source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") =
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3]
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
> [4]
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9783) The HTL compiler will trigger a NPE if a null value should be written into an HTML attribute
[
https://issues.apache.org/jira/browse/SLING-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9783.
---
> The HTL compiler will trigger a NPE if a null value should be written into an
> HTML attribute
>
>
> Key: SLING-9783
> URL: https://issues.apache.org/jira/browse/SLING-9783
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.8-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Compiler 1.2.10-1.4.0, Scripting HTL
> Testing Content 1.0.24-1.4.0, Scripting HTL Testing 1.0.26-1.4.0
>
>
> SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
> correctly check if an attribute should be displayed or not when the evaluated
> expression returns a {{null}} value.
> The following code example will generate a NPE:
> {code:html}
>
[jira] [Closed] (SLING-9655) Caching support for the GraphQL core
[ https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9655. --- > Caching support for the GraphQL core > > > Key: SLING-9655 > URL: https://issues.apache.org/jira/browse/SLING-9655 > Project: Sling > Issue Type: Task > Components: GraphQL >Affects Versions: GraphQL Core 0.0.4 >Reporter: Bertrand Delacretaz >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > We've discussed [on our dev > list|https://lists.apache.org/thread.html/r00652fa5bc54f96bb3ec01264905d9a1f36677a71070fa1b724570f9%40%3Cdev.sling.apache.org%3E] > how to provide caching support and we'd like to leverage front-end HTTP > caches that people usually use in front of Sling. > The suggested* interaction scenario* is: > * 1) GraphQL queries executed via POST are not cached by Sling > * 2) Queries can be prepared in advance by POSTing the query text to > Sling, which returns a "201 created" status with a URL that contains > the query's digest, like cf81d4 > * 3) Clients run such prepared queries by making GET requests to URLs > like /graphqlservlet/prepared/cf81d4.json > * 4) The responses to such prepared queries requests contain HTTP > Cache headers which might (maybe in later phase) be set from hints supplied > by data fetchers with configurable defaults. This allows these responses to > be cached by the usual front-end HTTP caches, CDN etc. > * 5) There's no guarantee on how long the prepared queries are stored, a > client that gets a 404 on a prepared query request must be prepared to > use the default POST request method or store the prepared query again -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9626) "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9626.
---
> "Writer has already been closed" exception in GraphQLServlet
>
>
> Key: SLING-9626
> URL: https://issues.apache.org/jira/browse/SLING-9626
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: GraphQL Core 0.0.6
>
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9720) Present the persisted queries endpoints using the same extension the GraphQL servlet uses
[ https://issues.apache.org/jira/browse/SLING-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9720. --- > Present the persisted queries endpoints using the same extension the GraphQL > servlet uses > - > > Key: SLING-9720 > URL: https://issues.apache.org/jira/browse/SLING-9720 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > Starting with SLING-9655, the GraphQL servlet supports persisted queries. In > order to better provide support for caching these queries at HTTP layers > above the Sling instance, it would be better to provide these resources using > the same extension that the GraphQL servlet uses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9724) Validate queries before persisting
[ https://issues.apache.org/jira/browse/SLING-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9724. --- > Validate queries before persisting > -- > > Key: SLING-9724 > URL: https://issues.apache.org/jira/browse/SLING-9724 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Gilles Knobloch >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > GraphQL queries sent for being persisted should be validated. > There should be an error message if someone tries to persist a wrong GraphQL > query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9744) Add metrics for the persisted queries
[ https://issues.apache.org/jira/browse/SLING-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9744. --- > Add metrics for the persisted queries > - > > Key: SLING-9744 > URL: https://issues.apache.org/jira/browse/SLING-9744 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > While SLING-9655 added support for GraphQL persisted queries, it would be > great to add some metrics to the feature to see how many queries are actually > cached, how the default cache is used and what's the relationship between > cache hits and cache misses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9763) Use the "application/graphql" mime type for the org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
[
https://issues.apache.org/jira/browse/SLING-9763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9763.
---
> Use the "application/graphql" mime type for the
> org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
> --
>
> Key: SLING-9763
> URL: https://issues.apache.org/jira/browse/SLING-9763
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.6
>
>
> The https://graphql.org/learn/serving-over-http/ resource describes a
> scenario where a request using the {{application/graphql}} {{Content-Type}}
> header should be treated as a raw GraphQL query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9753) Return a 500 status code if the persisted query cannot be stored in the cache
[
https://issues.apache.org/jira/browse/SLING-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9753.
---
> Return a 500 status code if the persisted query cannot be stored in the cache
> -
>
> Key: SLING-9753
> URL: https://issues.apache.org/jira/browse/SLING-9753
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.6
>
>
> SLING-9655 added support for GraphQL persisted queries. However, the current
> implementation still returns a query's cache and allows a client to perform
> cache retrievals even if the query was not actually stored in the cache.
> This happens due to the LRU cache implemented by
> {{org.apache.sling.graphql.core.cache.SimpleGraphQLCacheProvider}}, which
> evicts the oldest entry without checking if the new entry can actually be
> stored when using a cache memory limit configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9806) Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
[
https://issues.apache.org/jira/browse/SLING-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9806.
-
Resolution: Fixed
Fixed in [commit
51f153b|https://github.com/apache/sling-org-apache-sling-commons-johnzon/commit/51f153bffca880081b4a011850e5c3854d37fdd7].
> Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
>
>
> Key: SLING-9806
> URL: https://issues.apache.org/jira/browse/SLING-9806
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Commons Johnzon 1.2.6
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{org.apache.sling.commons.johnzon}} is a wrapper over
> {{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
> correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
> that it can still not be deployed as is in Sling, without also deploying
> SPI-Fly - see JOHNZON-108 for context.
> Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in
> a Sling deployment, the OSGi packages that
> {{org.apache.johnzon:johnzon-core}} exports should be re-exported by
> {{org.apache.sling.commons.johnzon}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9806) Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
[
https://issues.apache.org/jira/browse/SLING-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9806:
Description:
{{org.apache.sling.commons.johnzon}} is a wrapper over
{{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
that it can still not be deployed as is in Sling, without also deploying
SPI-Fly - see JOHNZON-108 for context.
Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in a
Sling deployment, the OSGi packages that {{org.apache.johnzon:johnzon-core}}
exports should be re-exported by {{org.apache.sling.commons.johnzon}}.
was:
{{org.apache.sling.commons.johnzon}} is a wrapper over
{{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
that it can still not be deployed as is in Sling, without also deploying
SPI-Fly - see for context.
Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in a
Sling deployment, the OSGi packages that {{org.apache.johnzon:johnzon-core}}
exports should be re-exported by {{org.apache.sling.commons.johnzon}}.
> Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
>
>
> Key: SLING-9806
> URL: https://issues.apache.org/jira/browse/SLING-9806
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Commons Johnzon 1.2.6
>
>
> {{org.apache.sling.commons.johnzon}} is a wrapper over
> {{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
> correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
> that it can still not be deployed as is in Sling, without also deploying
> SPI-Fly - see JOHNZON-108 for context.
> Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in
> a Sling deployment, the OSGi packages that
> {{org.apache.johnzon:johnzon-core}} exports should be re-exported by
> {{org.apache.sling.commons.johnzon}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9806) Export the johnzon.core packages provided by org.apache.johnzon:johnzon-core
Radu Cotescu created SLING-9806:
---
Summary: Export the johnzon.core packages provided by
org.apache.johnzon:johnzon-core
Key: SLING-9806
URL: https://issues.apache.org/jira/browse/SLING-9806
Project: Sling
Issue Type: Improvement
Components: Commons
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Commons Johnzon 1.2.6
{{org.apache.sling.commons.johnzon}} is a wrapper over
{{org.apache.johnzon:johnzon-core}}, to make sure that the latter works
correctly in Sling. Even though {{johnzon-core}} is an OSGi bundle, it seems
that it can still not be deployed as is in Sling, without also deploying
SPI-Fly - see for context.
Since other {{johnzon}} bundles (e.g. {{johnzon-mapper}}) could be useful in a
Sling deployment, the OSGi packages that {{org.apache.johnzon:johnzon-core}}
exports should be re-exported by {{org.apache.sling.commons.johnzon}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9796) Add support for using Unions
[
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9796:
Fix Version/s: GraphQL Core 0.0.8
> Add support for using Unions
>
>
> Key: SLING-9796
> URL: https://issues.apache.org/jira/browse/SLING-9796
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Adrian Kozma
>Priority: Major
> Fix For: GraphQL Core 0.0.8
>
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is
> not supporting the *Union* type, however there's a way to implement it.
> 1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3]
> adding the following lines
> - based on the graphql-java documentation [4] the TypeResolver returns the
> schema ObjectType based on the current result item instance
> {code:java}
> List unionTypes =
> typeRegistry.getTypes(UnionTypeDefinition.class);
> for (UnionTypeDefinition type : unionTypes) {
> TypeResolver typeResolver = env -> {
> Object javaObject = env.getObject();
> // schema contains only one union definition:
> // "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
> // hardcoding to force return the object type Type1
> return env.getSchema().getObjectType("Type1");
> };
> builder.type(type.getName(), typeWriting ->
> typeWriting.typeResolver(typeResolver));
> }
> {code}
> 2. General solution
> The suggested solution would be to extend
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external
> callable, following the pattern how it was implemented in case of data
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a
> TypeProvider can decide which Object Type needs to be returned. The condition
> is based on the result item (javaObject) which is constructed by the data
> fetcher (external callable). Therefore, to match the logic, the TypeResolver
> should be callable (OSGI component) which could be detected by directives
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
> name: String,
> options: String = "",
> source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") =
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3]
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
> [4]
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9796) Add support for using Unions
[
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9796:
Affects Version/s: (was: GraphQL Core 0.0.8)
> Add support for using Unions
>
>
> Key: SLING-9796
> URL: https://issues.apache.org/jira/browse/SLING-9796
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Adrian Kozma
>Priority: Major
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is
> not supporting the *Union* type, however there's a way to implement it.
> 1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3]
> adding the following lines
> - based on the graphql-java documentation [4] the TypeResolver returns the
> schema ObjectType based on the current result item instance
> {code:java}
> List unionTypes =
> typeRegistry.getTypes(UnionTypeDefinition.class);
> for (UnionTypeDefinition type : unionTypes) {
> TypeResolver typeResolver = env -> {
> Object javaObject = env.getObject();
> // schema contains only one union definition:
> // "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
> // hardcoding to force return the object type Type1
> return env.getSchema().getObjectType("Type1");
> };
> builder.type(type.getName(), typeWriting ->
> typeWriting.typeResolver(typeResolver));
> }
> {code}
> 2. General solution
> The suggested solution would be to extend
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external
> callable, following the pattern how it was implemented in case of data
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a
> TypeProvider can decide which Object Type needs to be returned. The condition
> is based on the result item (javaObject) which is constructed by the data
> fetcher (external callable). Therefore, to match the logic, the TypeResolver
> should be callable (OSGI component) which could be detected by directives
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
> name: String,
> options: String = "",
> source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") =
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3]
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
> [4]
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9796) Add support for using Unions
[
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9796:
Summary: Add support for using Unions (was: GraphQL add support for using
Unions)
> Add support for using Unions
>
>
> Key: SLING-9796
> URL: https://issues.apache.org/jira/browse/SLING-9796
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.8
>Reporter: Adrian Kozma
>Priority: Major
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is
> not supporting the *Union* type, however there's a way to implement it.
> 1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3]
> adding the following lines
> - based on the graphql-java documentation [4] the TypeResolver returns the
> schema ObjectType based on the current result item instance
> {code:java}
> List unionTypes =
> typeRegistry.getTypes(UnionTypeDefinition.class);
> for (UnionTypeDefinition type : unionTypes) {
> TypeResolver typeResolver = env -> {
> Object javaObject = env.getObject();
> // schema contains only one union definition:
> // "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
> // hardcoding to force return the object type Type1
> return env.getSchema().getObjectType("Type1");
> };
> builder.type(type.getName(), typeWriting ->
> typeWriting.typeResolver(typeResolver));
> }
> {code}
> 2. General solution
> The suggested solution would be to extend
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external
> callable, following the pattern how it was implemented in case of data
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a
> TypeProvider can decide which Object Type needs to be returned. The condition
> is based on the result item (javaObject) which is constructed by the data
> fetcher (external callable). Therefore, to match the logic, the TypeResolver
> should be callable (OSGI component) which could be detected by directives
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
> name: String,
> options: String = "",
> source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") =
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3]
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
> [4]
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9800) Extract a service to be able to execute GraphQL queries directly
Radu Cotescu created SLING-9800: --- Summary: Extract a service to be able to execute GraphQL queries directly Key: SLING-9800 URL: https://issues.apache.org/jira/browse/SLING-9800 Project: Sling Issue Type: Improvement Components: GraphQL Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: GraphQL Core 0.0.8 In the current implementation of the GraphQL Core bundle queries can only be executed via a GraphQL Servlet that needs to be configured or via server-side scripts. It would be good if the queries could also be executed directly, without the need for a request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9787) Switch to the latest parent pom to simplify JaCoCo configuration
[ https://issues.apache.org/jira/browse/SLING-9787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9787. - Resolution: Fixed Implemented in [commit 6a789a6|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/6a789a6]. > Switch to the latest parent pom to simplify JaCoCo configuration > > > Key: SLING-9787 > URL: https://issues.apache.org/jira/browse/SLING-9787 > Project: Sling > Issue Type: Bug > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.8 > > > SLING-9775 improved the JaCoCo configuration and made it more reusable for > child projects. The GraphQL Core Bundle should be updated to use the latest > version of the parent POM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9787) Switch to the latest parent pom to simplify JaCoCo configuration
[ https://issues.apache.org/jira/browse/SLING-9787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9787: Description: SLING-9775 improved the JaCoCo configuration and made it more reusable for child projects. The GraphQL Core Bundle should be updated to use the latest version of the parent POM. (was: SLING-9755 improved the JaCoCo configuration and made it more reusable for child projects. The GraphQL Core Bundle should be updated to use the latest version of the parent POM.) > Switch to the latest parent pom to simplify JaCoCo configuration > > > Key: SLING-9787 > URL: https://issues.apache.org/jira/browse/SLING-9787 > Project: Sling > Issue Type: Bug > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.8 > > > SLING-9775 improved the JaCoCo configuration and made it more reusable for > child projects. The GraphQL Core Bundle should be updated to use the latest > version of the parent POM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9787) Switch to the latest parent pom to simplify JaCoCo configuration
Radu Cotescu created SLING-9787: --- Summary: Switch to the latest parent pom to simplify JaCoCo configuration Key: SLING-9787 URL: https://issues.apache.org/jira/browse/SLING-9787 Project: Sling Issue Type: Bug Components: GraphQL Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: GraphQL Core 0.0.8 SLING-9755 improved the JaCoCo configuration and made it more reusable for child projects. The GraphQL Core Bundle should be updated to use the latest version of the parent POM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9783) The HTL compiler will trigger a NPE if a null value should be written into an HTML attribute
[
https://issues.apache.org/jira/browse/SLING-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9783.
-
Fix Version/s: Scripting HTL Testing 1.0.26-1.4.0
Scripting HTL Testing Content 1.0.24-1.4.0
Resolution: Fixed
> The HTL compiler will trigger a NPE if a null value should be written into an
> HTML attribute
>
>
> Key: SLING-9783
> URL: https://issues.apache.org/jira/browse/SLING-9783
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.8-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing Content 1.0.24-1.4.0, Scripting
> HTL Testing 1.0.26-1.4.0, Scripting HTL Compiler 1.2.10-1.4.0
>
>
> SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
> correctly check if an attribute should be displayed or not when the evaluated
> expression returns a {{null}} value.
> The following code example will generate a NPE:
> {code:html}
>
[jira] [Commented] (SLING-9783) The HTL compiler will trigger a NPE if a null value should be written into an HTML attribute
[
https://issues.apache.org/jira/browse/SLING-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205786#comment-17205786
]
Radu Cotescu commented on SLING-9783:
-
Fixed in:
* [commit
dba0f3d|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/dba0f3d]
* [commit
685f9b3|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/685f9b3]
* [commit
b4ccab9|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/b4ccab9]
> The HTL compiler will trigger a NPE if a null value should be written into an
> HTML attribute
>
>
> Key: SLING-9783
> URL: https://issues.apache.org/jira/browse/SLING-9783
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.8-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Compiler 1.2.10-1.4.0
>
>
> SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
> correctly check if an attribute should be displayed or not when the evaluated
> expression returns a {{null}} value.
> The following code example will generate a NPE:
> {code:html}
>
[jira] [Updated] (SLING-9783) The HTL compiler will trigger a NPE if a null value should be written into an HTML attribute
[
https://issues.apache.org/jira/browse/SLING-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9783:
Description:
SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
correctly check if an attribute should be displayed or not when the evaluated
expression returns a {{null}} value.
The following code example will generate a NPE:
{code:html}
https://issues.apache.org/jira/browse/SLING-9783
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.2.8-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Compiler 1.2.10-1.4.0
>
>
> SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
> correctly check if an attribute should be displayed or not when the evaluated
> expression returns a {{null}} value.
> The following code example will generate a NPE:
> {code:html}
>
[jira] [Created] (SLING-9783) The HTL compiler will trigger a NPE if a null value should be written into an HTML attribute
Radu Cotescu created SLING-9783:
---
Summary: The HTL compiler will trigger a NPE if a null value
should be written into an HTML attribute
Key: SLING-9783
URL: https://issues.apache.org/jira/browse/SLING-9783
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Compiler 1.2.8-1.4.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Compiler 1.2.10-1.4.0
SLING-9696 introduced a side-effect into the HTL compiler, which doesn't
correctly check if an attribute should be displayed or not when the evaluated
expression returns a {{null}} value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9781) [Sling Models] Caching doesn't work with Wrapped requests
[
https://issues.apache.org/jira/browse/SLING-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205411#comment-17205411
]
Radu Cotescu commented on SLING-9781:
-
[~jelger], I already commented in the PR. I think the actual issue has a larger
scope than wrapped requests. I'll let [~justinedelson] have a deeper look,
since it's his code and he knows better the way the caching should work.
> [Sling Models] Caching doesn't work with Wrapped requests
> -
>
> Key: SLING-9781
> URL: https://issues.apache.org/jira/browse/SLING-9781
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Christophe Jelger
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The caching of Sling models doesn't work when the original
> {{SlingHttpServletRequest}} is wrapped in a request wrapper, like this is
> typically done in HTL scripts with the {{OnDemandReaderRequest}} wrapper.
> The solution is to use the original request when caching models so that any
> wrapping does not interfere with the caching. When someone enables caching
> for a model adapted from request, I think the expectation is that caching
> does happen whenever the original request is wrapped.
> I'll provide a PR with a fix.
> cc: [~justinedelson] [~radu] as discussed in Slack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9781) [Sling Models] Caching doesn't work with Wrapped requests
[
https://issues.apache.org/jira/browse/SLING-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9781:
---
Assignee: Justin Edelson
> [Sling Models] Caching doesn't work with Wrapped requests
> -
>
> Key: SLING-9781
> URL: https://issues.apache.org/jira/browse/SLING-9781
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Christophe Jelger
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The caching of Sling models doesn't work when the original
> {{SlingHttpServletRequest}} is wrapped in a request wrapper, like this is
> typically done in HTL scripts with the {{OnDemandReaderRequest}} wrapper.
> The solution is to use the original request when caching models so that any
> wrapping does not interfere with the caching. When someone enables caching
> for a model adapted from request, I think the expectation is that caching
> does happen whenever the original request is wrapped.
> I'll provide a PR with a fix.
> cc: [~justinedelson] [~radu] as discussed in Slack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9775) Improve JaCoCo code coverage setup
[
https://issues.apache.org/jira/browse/SLING-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9775.
-
Resolution: Fixed
Applied changes in [commit
149cc41|https://github.com/apache/sling-parent/commit/149cc4109602464098bed0e622f26aceab027f64].
> Improve JaCoCo code coverage setup
> --
>
> Key: SLING-9775
> URL: https://issues.apache.org/jira/browse/SLING-9775
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control, General
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Parent 40
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> While the parent pom defines a good setup for the JaCoCo Maven Plugin, the
> integration with JaCoCo - configurations for the {{surefire}} and
> {{failsafe}} plugins - has to be performed in each project using the parent
> pom. This leads to inconsistent configurations and sometimes not all coverage
> is correctly reported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9775) Improve JaCoCo code coverage setup
[
https://issues.apache.org/jira/browse/SLING-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204231#comment-17204231
]
Radu Cotescu commented on SLING-9775:
-
This issue, together with the improvements from SLING-8995, should help report
the correct coverage measurements once the Sling modules update to a parent pom
>= 40.
> Improve JaCoCo code coverage setup
> --
>
> Key: SLING-9775
> URL: https://issues.apache.org/jira/browse/SLING-9775
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Parent 40, Bundle Parent 40
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While the parent pom defines a good setup for the JaCoCo Maven Plugin, the
> integration with JaCoCo - configurations for the {{surefire}} and
> {{failsafe}} plugins - has to be performed in each project using the parent
> pom. This leads to inconsistent configurations and sometimes not all coverage
> is correctly reported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9775) Improve JaCoCo code coverage setup
[
https://issues.apache.org/jira/browse/SLING-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9775:
---
Assignee: Radu Cotescu
> Improve JaCoCo code coverage setup
> --
>
> Key: SLING-9775
> URL: https://issues.apache.org/jira/browse/SLING-9775
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Parent 40, Bundle Parent 40
>
>
> While the parent pom defines a good setup for the JaCoCo Maven Plugin, the
> integration with JaCoCo - configurations for the {{surefire}} and
> {{failsafe}} plugins - has to be performed in each project using the parent
> pom. This leads to inconsistent configurations and sometimes not all coverage
> is correctly reported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9775) Improve JaCoCo code coverage setup
Radu Cotescu created SLING-9775:
---
Summary: Improve JaCoCo code coverage setup
Key: SLING-9775
URL: https://issues.apache.org/jira/browse/SLING-9775
Project: Sling
Issue Type: Improvement
Components: Build and Source Control
Reporter: Radu Cotescu
Fix For: Parent 40, Bundle Parent 40
While the parent pom defines a good setup for the JaCoCo Maven Plugin, the
integration with JaCoCo - configurations for the {{surefire}} and {{failsafe}}
plugins - has to be performed in each project using the parent pom. This leads
to inconsistent configurations and sometimes not all coverage is correctly
reported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9706) The HTL Java Compiler does not correctly negate equals
[
https://issues.apache.org/jira/browse/SLING-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9706.
---
> The HTL Java Compiler does not correctly negate equals
> --
>
> Key: SLING-9706
> URL: https://issues.apache.org/jira/browse/SLING-9706
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Java Compiler 1.0.4, Scripting HTL Java
> Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.2.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Java
> Compiler 1.2.2-1.4.0
>
>
> Although the {{equals}} operation is only generated for internal HTL Compiler
> commands, the operation is not correctly negated when using the
> {{Binary.NEQ}} operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9314) NPE in ObjectModel.toBoolean(Object) when object.toString() returns null
[ https://issues.apache.org/jira/browse/SLING-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9314. --- > NPE in ObjectModel.toBoolean(Object) when object.toString() returns null > > > Key: SLING-9314 > URL: https://issues.apache.org/jira/browse/SLING-9314 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0, Scripting HTL Runtime > 1.1.0-1.4.0, Scripting HTL Runtime 1.1.2-1.4.0 >Reporter: Paul Bjorkstrand >Assignee: Radu Cotescu >Priority: Major > Fix For: Scripting HTL Runtime 1.2.4-1.4.0 > > > Though it is bad practice, it is possible that an object can return null from > its toString() method. ObjectModel.toBoolean(Object) \[[Line > 161|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/blob/master/src/main/java/org/apache/sling/scripting/sightly/render/ObjectModel.java#L161]\] > calls .trim() on a potentially null object. > This causes a difficult to troubleshoot, deeply nested, and cryptic exception > to be raised. If object.toString() returns null, then it should be treated > the same as nearly the rest of HTL, where null is considered "falsey". Doing > so will save hours of difficult troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9718) Relative paths for bundled HTL template files are not correctly handled
[
https://issues.apache.org/jira/browse/SLING-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9718.
---
> Relative paths for bundled HTL template files are not correctly handled
> ---
>
> Key: SLING-9718
> URL: https://issues.apache.org/jira/browse/SLING-9718
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0
>
>
> If a template library (a file providing one or more HTL templates) is bundled
> (precompiled or not) and is loaded by a caller using a relative path, the
> loading might fail if the lookup is done via the
> {{org.apache.sling.scripting.sightly.impl.engine.bundled.BundledUnitManagerImpl#getRenderUnit(javax.script.Bindings,
> java.lang.String)}} service method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
[
https://issues.apache.org/jira/browse/SLING-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9696.
---
> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0,
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Runtime
> 1.2.4-1.4.0, Scripting HTL Engine 1.4.4-1.4.0, Scripting HTL Java Compiler
> 1.2.2-1.4.0, Scripting HTL Compiler 1.2.8-1.4.0, Scripting HTL Testing
> 1.0.24-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly
> casted the "false" string to boolean. The HTL specification [0] mentions the
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any
> casing of the string "false".
> A change like this has the potential to break the functionality of existing
> HTL code, relying on the fact that the string "false" (irrespective of its
> casing) returns the Boolean {{false}}, however the implementation should obey
> the specification. Therefore I think the fix should be behind a configuration
> flag, which by default allows the engine to continue working with the wrong
> behaviour. Deployers can then decide via configuration if they would like to
> switch the engine to the correct behaviour.
>
> [0] -
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9715) The JavaUseProvider does not properly handle the adaptable argument for Sling Model classes
[
https://issues.apache.org/jira/browse/SLING-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9715.
---
> The JavaUseProvider does not properly handle the adaptable argument for Sling
> Model classes
> ---
>
> Key: SLING-9715
> URL: https://issues.apache.org/jira/browse/SLING-9715
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Paul Bjorkstrand
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0, Scripting HTL Testing
> 1.0.24-1.4.0, Scripting HTL Testing Content 1.0.22-1.4.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When Sling Models instantiation was added in SLING-9320
> ([commit|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bcd46027e09182911c55bb244d42debb1bd367c7]),
> it did not treat the {{adaptable}} argument the same for all types of
> instantiations (Sling Models vs basic Sling Adaptable). This fixes that by
> rearranging the instantiation attempt order, which puts the argument provided
> adaptable through {{ModelFactory#createModel}} just like the request and
> resource would be.
> This is a subtle semantic change, and likely warrants a minor version update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9705) Enable code coverage with JaCoCo
[ https://issues.apache.org/jira/browse/SLING-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-9705. --- > Enable code coverage with JaCoCo > > > Key: SLING-9705 > URL: https://issues.apache.org/jira/browse/SLING-9705 > Project: Sling > Issue Type: Task > Components: Scripting >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Scripting Core 2.3.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9768) The org.apache.sling.api.scripting.SlingScript#getScriptResource implementations should not leak the scripting resolver
[
https://issues.apache.org/jira/browse/SLING-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9768.
---
> The org.apache.sling.api.scripting.SlingScript#getScriptResource
> implementations should not leak the scripting resolver
> ---
>
> Key: SLING-9768
> URL: https://issues.apache.org/jira/browse/SLING-9768
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Core 2.3.0, Scripting HTL Engine 1.4.2-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.4, Scripting HTL Engine 1.4.4-1.4.0,
> Scripting HTL Testing 1.0.24-1.4.0, Scripting HTL Testing Content 1.0.22-1.4.0
>
>
> Since the {{SlingScript}} is usually made available via the {{bindings}} to
> the current executing script, the resolver that can be accessed via
> {{org.apache.sling.api.scripting.SlingScript#getScriptResource}} should not
> give elevated access to the caller. This means that either the caller is
> responsible for the mapped resolver (by getting a mapped resolver to the
> bundle the caller comes from via script precompilation), or the resolver
> should be the request resolver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9693) Make org.apache.sling.servlets.resolver.bundle.tracker an optional import for scripting.core
[
https://issues.apache.org/jira/browse/SLING-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-9693.
---
> Make org.apache.sling.servlets.resolver.bundle.tracker an optional import for
> scripting.core
>
>
> Key: SLING-9693
> URL: https://issues.apache.org/jira/browse/SLING-9693
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting Core 2.3.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.4
>
>
> Since rendering content using bundled scripts (precompiled or not) is an
> optional feature, we should make the
> {{org.apache.sling.servlets.resolver.bundle.tracker}} API an optional import
> for Scripting Core. This way the Scripting Core bundle is not tightly coupled
> to the Servlets Resolver bundle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9653) HTL Maven Plugin: Include GitHub ribbon and edit button
[ https://issues.apache.org/jira/browse/SLING-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9653: Fix Version/s: (was: HTL Maven Plugin 2.0.2-1.4.0) HTL Maven Plugin 2.0.4-1.4.0 > HTL Maven Plugin: Include GitHub ribbon and edit button > --- > > Key: SLING-9653 > URL: https://issues.apache.org/jira/browse/SLING-9653 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Konrad Windszus >Priority: Minor > Fix For: HTL Maven Plugin 2.0.4-1.4.0 > > > We should include a GitHub ribbon in the header (like outlined > https://maven.apache.org/skins/maven-fluido-skin/#GitHub_ribbons) to ease > contributing PRs. Also an edit button should be enabled on all Doxia > generated documentation pages via > https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html > (edit element in the site.xml) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
[
https://issues.apache.org/jira/browse/SLING-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9696:
Fix Version/s: HTL Maven Plugin 2.0.2-1.4.0
> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0,
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Runtime
> 1.2.4-1.4.0, Scripting HTL Engine 1.4.4-1.4.0, Scripting HTL Java Compiler
> 1.2.2-1.4.0, Scripting HTL Compiler 1.2.8-1.4.0, Scripting HTL Testing
> 1.0.24-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly
> casted the "false" string to boolean. The HTL specification [0] mentions the
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any
> casing of the string "false".
> A change like this has the potential to break the functionality of existing
> HTL code, relying on the fact that the string "false" (irrespective of its
> casing) returns the Boolean {{false}}, however the implementation should obey
> the specification. Therefore I think the fix should be behind a configuration
> flag, which by default allows the engine to continue working with the wrong
> behaviour. Deployers can then decide via configuration if they would like to
> switch the engine to the correct behaviour.
>
> [0] -
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9706) The HTL Java Compiler does not correctly negate equals
[
https://issues.apache.org/jira/browse/SLING-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9706:
Fix Version/s: HTL Maven Plugin 2.0.2-1.4.0
> The HTL Java Compiler does not correctly negate equals
> --
>
> Key: SLING-9706
> URL: https://issues.apache.org/jira/browse/SLING-9706
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Java Compiler 1.0.4, Scripting HTL Java
> Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.2.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Java
> Compiler 1.2.2-1.4.0
>
>
> Although the {{equals}} operation is only generated for internal HTL Compiler
> commands, the operation is not correctly negated when using the
> {{Binary.NEQ}} operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9768) The org.apache.sling.api.scripting.SlingScript#getScriptResource implementations should not leak the scripting resolver
[
https://issues.apache.org/jira/browse/SLING-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9768.
-
Fix Version/s: Scripting HTL Testing Content 1.0.22-1.4.0
Scripting HTL Testing 1.0.24-1.4.0
Resolution: Fixed
Implemented changes in:
* [commit
714cc2d|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/714cc2d]
* [commit
f34a9b3|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/f34a9b3]
* [commit
33c3f8f|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/33c3f8f]
* [commit
804f280|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/804f280]
> The org.apache.sling.api.scripting.SlingScript#getScriptResource
> implementations should not leak the scripting resolver
> ---
>
> Key: SLING-9768
> URL: https://issues.apache.org/jira/browse/SLING-9768
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Core 2.3.0, Scripting HTL Engine 1.4.2-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.4, Scripting HTL Engine 1.4.4-1.4.0,
> Scripting HTL Testing 1.0.24-1.4.0, Scripting HTL Testing Content 1.0.22-1.4.0
>
>
> Since the {{SlingScript}} is usually made available via the {{bindings}} to
> the current executing script, the resolver that can be accessed via
> {{org.apache.sling.api.scripting.SlingScript#getScriptResource}} should not
> give elevated access to the caller. This means that either the caller is
> responsible for the mapped resolver (by getting a mapped resolver to the
> bundle the caller comes from via script precompilation), or the resolver
> should be the request resolver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9768) The org.apache.sling.api.scripting.SlingScript#getScriptResource implementations should not leak the scripting resolver
Radu Cotescu created SLING-9768:
---
Summary: The
org.apache.sling.api.scripting.SlingScript#getScriptResource implementations
should not leak the scripting resolver
Key: SLING-9768
URL: https://issues.apache.org/jira/browse/SLING-9768
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.2-1.4.0, Scripting Core 2.3.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.3.4, Scripting HTL Engine 1.4.4-1.4.0
Since the {{SlingScript}} is usually made available via the {{bindings}} to the
current executing script, the resolver that can be accessed via
{{org.apache.sling.api.scripting.SlingScript#getScriptResource}} should not
give elevated access to the caller. This means that either the caller is
responsible for the mapped resolver (by getting a mapped resolver to the bundle
the caller comes from via script precompilation), or the resolver should be the
request resolver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9763) Use the "application/graphql" mime type for the org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
[
https://issues.apache.org/jira/browse/SLING-9763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9763.
-
Resolution: Fixed
Fixed in [commit
c3a176f|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/c3a176f].
> Use the "application/graphql" mime type for the
> org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
> --
>
> Key: SLING-9763
> URL: https://issues.apache.org/jira/browse/SLING-9763
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.6
>
>
> The https://graphql.org/learn/serving-over-http/ resource describes a
> scenario where a request using the {{application/graphql}} {{Content-Type}}
> header should be treated as a raw GraphQL query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9763) Use the "application/graphql" mime type for the org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
Radu Cotescu created SLING-9763:
---
Summary: Use the "application/graphql" mime type for the
org.apache.sling.graphql.core.scripting.GraphQLScriptEngineFactory
Key: SLING-9763
URL: https://issues.apache.org/jira/browse/SLING-9763
Project: Sling
Issue Type: Bug
Components: GraphQL
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: GraphQL Core 0.0.6
The https://graphql.org/learn/serving-over-http/ resource describes a scenario
where a request using the {{application/graphql}} {{Content-Type}} header
should be treated as a raw GraphQL query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9762) Automatic Mapping of URIs in HTL
[
https://issues.apache.org/jira/browse/SLING-9762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9762:
---
Assignee: Radu Cotescu
> Automatic Mapping of URIs in HTL
>
>
> Key: SLING-9762
> URL: https://issues.apache.org/jira/browse/SLING-9762
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
>Reporter: Georg Henzler
>Assignee: Radu Cotescu
>Priority: Major
>
> There should be the possibility to automatically map non-absolute URIs in HTL
> (that is
> [URI.isAbsolute()|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
> = false). If all URIs are mapped automatically or not should be globally
> configurable and then be overridden if necessary in HTL as follows:
> {code}
>
> {code}
> If auto-mapping is globally deactivated, the following should allow to
> activate it:
> {code}
>
> {code}
> See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for
> initial discussion
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9753) Return a 500 status code if the persisted query cannot be stored in the cache
[
https://issues.apache.org/jira/browse/SLING-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9753.
-
Resolution: Fixed
Implemented in [commit
8301d5c|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/8301d5c]
> Return a 500 status code if the persisted query cannot be stored in the cache
> -
>
> Key: SLING-9753
> URL: https://issues.apache.org/jira/browse/SLING-9753
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.6
>
>
> SLING-9655 added support for GraphQL persisted queries. However, the current
> implementation still returns a query's cache and allows a client to perform
> cache retrievals even if the query was not actually stored in the cache.
> This happens due to the LRU cache implemented by
> {{org.apache.sling.graphql.core.cache.SimpleGraphQLCacheProvider}}, which
> evicts the oldest entry without checking if the new entry can actually be
> stored when using a cache memory limit configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9753) Return a 500 status code if the persisted query cannot be stored in the cache
Radu Cotescu created SLING-9753:
---
Summary: Return a 500 status code if the persisted query cannot be
stored in the cache
Key: SLING-9753
URL: https://issues.apache.org/jira/browse/SLING-9753
Project: Sling
Issue Type: Bug
Components: GraphQL
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: GraphQL Core 0.0.6
SLING-9655 added support for GraphQL persisted queries. However, the current
implementation still returns a query's cache and allows a client to perform
cache retrievals even if the query was not actually stored in the cache.
This happens due to the LRU cache implemented by
{{org.apache.sling.graphql.core.cache.SimpleGraphQLCacheProvider}}, which
evicts the oldest entry without checking if the new entry can actually be
stored when using a cache memory limit configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9744) Add metrics for the persisted queries
[ https://issues.apache.org/jira/browse/SLING-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9744. - Resolution: Fixed Implemented in [commit d9eb854|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/d9eb854]. > Add metrics for the persisted queries > - > > Key: SLING-9744 > URL: https://issues.apache.org/jira/browse/SLING-9744 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > While SLING-9655 added support for GraphQL persisted queries, it would be > great to add some metrics to the feature to see how many queries are actually > cached, how the default cache is used and what's the relationship between > cache hits and cache misses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9744) Add metrics for the persisted queries
Radu Cotescu created SLING-9744: --- Summary: Add metrics for the persisted queries Key: SLING-9744 URL: https://issues.apache.org/jira/browse/SLING-9744 Project: Sling Issue Type: Improvement Components: GraphQL Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: GraphQL Core 0.0.6 While SLING-9655 added support for GraphQL persisted queries, it would be great to add some metrics to the feature to see how many queries are actually cached, how the default cache is used and what's the relationship between cache hits and cache misses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9724) Validate queries before persisting
[ https://issues.apache.org/jira/browse/SLING-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9724. - Resolution: Fixed Implemented in [commit e675ad7|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/e675ad7]. > Validate queries before persisting > -- > > Key: SLING-9724 > URL: https://issues.apache.org/jira/browse/SLING-9724 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Gilles Knobloch >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > GraphQL queries sent for being persisted should be validated. > There should be an error message if someone tries to persist a wrong GraphQL > query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9720) Present the persisted queries endpoints using the same extension the GraphQL servlet uses
[ https://issues.apache.org/jira/browse/SLING-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9720. - Resolution: Fixed Implemented in [commit df6e19c|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/df6e19c]. > Present the persisted queries endpoints using the same extension the GraphQL > servlet uses > - > > Key: SLING-9720 > URL: https://issues.apache.org/jira/browse/SLING-9720 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > Starting with SLING-9655, the GraphQL servlet supports persisted queries. In > order to better provide support for caching these queries at HTTP layers > above the Sling instance, it would be better to provide these resources using > the same extension that the GraphQL servlet uses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9724) Validate queries before persisting
[ https://issues.apache.org/jira/browse/SLING-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-9724: --- Assignee: Radu Cotescu > Validate queries before persisting > -- > > Key: SLING-9724 > URL: https://issues.apache.org/jira/browse/SLING-9724 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Gilles Knobloch >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > GraphQL queries sent for being persisted should be validated. > There should be an error message if someone tries to persist a wrong GraphQL > query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9693) Make org.apache.sling.servlets.resolver.bundle.tracker an optional import for scripting.core
[
https://issues.apache.org/jira/browse/SLING-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9693.
-
Resolution: Fixed
Implemented in [commit
7a88e41|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/7a88e41].
> Make org.apache.sling.servlets.resolver.bundle.tracker an optional import for
> scripting.core
>
>
> Key: SLING-9693
> URL: https://issues.apache.org/jira/browse/SLING-9693
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting Core 2.3.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.4
>
>
> Since rendering content using bundled scripts (precompiled or not) is an
> optional feature, we should make the
> {{org.apache.sling.servlets.resolver.bundle.tracker}} API an optional import
> for Scripting Core. This way the Scripting Core bundle is not tightly coupled
> to the Servlets Resolver bundle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9720) Present the persisted queries endpoints using the same extension the GraphQL servlet uses
[ https://issues.apache.org/jira/browse/SLING-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-9720: Description: Starting with SLING-9655, the GraphQL servlet supports persisted queries. In order to better provide support for caching these queries at HTTP layers above the Sling instance, it would be better to provide these resources using the same extension that the GraphQL servlet uses. (was: Starting with SLING-9665, the GraphQL servlet supports persisted queries. In order to better provide support for caching these queries at HTTP layers above the Sling instance, it would be better to provide these resources using the same extension that the GraphQL servlet uses.) > Present the persisted queries endpoints using the same extension the GraphQL > servlet uses > - > > Key: SLING-9720 > URL: https://issues.apache.org/jira/browse/SLING-9720 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > Starting with SLING-9655, the GraphQL servlet supports persisted queries. In > order to better provide support for caching these queries at HTTP layers > above the Sling instance, it would be better to provide these resources using > the same extension that the GraphQL servlet uses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9720) Present the persisted queries endpoints using the same extension the GraphQL servlet uses
Radu Cotescu created SLING-9720: --- Summary: Present the persisted queries endpoints using the same extension the GraphQL servlet uses Key: SLING-9720 URL: https://issues.apache.org/jira/browse/SLING-9720 Project: Sling Issue Type: Improvement Components: GraphQL Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: GraphQL Core 0.0.6 Starting with SLING-9665, the GraphQL servlet supports persisted queries. In order to better provide support for caching these queries at HTTP layers above the Sling instance, it would be better to provide these resources using the same extension that the GraphQL servlet uses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-9718) Relative paths for bundled HTL template files are not correctly handled
[
https://issues.apache.org/jira/browse/SLING-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190303#comment-17190303
]
Radu Cotescu edited comment on SLING-9718 at 9/3/20, 5:03 PM:
--
Fixed in [commit
65c4814|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/65c4814],
added tests in [commit
cef5f6a|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker-it/commit/cef5f6a].
was (Author: radu.cotescu):
Fixed in [commit
65c4814|[https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/65c4814],]
added tests in [commit
cef5f6a|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker-it/commit/cef5f6a].
> Relative paths for bundled HTL template files are not correctly handled
> ---
>
> Key: SLING-9718
> URL: https://issues.apache.org/jira/browse/SLING-9718
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0
>
>
> If a template library (a file providing one or more HTL templates) is bundled
> (precompiled or not) and is loaded by a caller using a relative path, the
> loading might fail if the lookup is done via the
> {{org.apache.sling.scripting.sightly.impl.engine.bundled.BundledUnitManagerImpl#getRenderUnit(javax.script.Bindings,
> java.lang.String)}} service method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9718) Relative paths for bundled HTL template files are not correctly handled
[
https://issues.apache.org/jira/browse/SLING-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9718.
-
Resolution: Fixed
Fixed in [commit
65c4814|[https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/65c4814],]
added tests in [commit
cef5f6a|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker-it/commit/cef5f6a].
> Relative paths for bundled HTL template files are not correctly handled
> ---
>
> Key: SLING-9718
> URL: https://issues.apache.org/jira/browse/SLING-9718
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0
>
>
> If a template library (a file providing one or more HTL templates) is bundled
> (precompiled or not) and is loaded by a caller using a relative path, the
> loading might fail if the lookup is done via the
> {{org.apache.sling.scripting.sightly.impl.engine.bundled.BundledUnitManagerImpl#getRenderUnit(javax.script.Bindings,
> java.lang.String)}} service method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9718) Relative paths for bundled HTL template files are not correctly handled
Radu Cotescu created SLING-9718:
---
Summary: Relative paths for bundled HTL template files are not
correctly handled
Key: SLING-9718
URL: https://issues.apache.org/jira/browse/SLING-9718
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Engine 1.4.4-1.4.0
If a template library (a file providing one or more HTL templates) is bundled
(precompiled or not) and is loaded by a caller using a relative path, the
loading might fail if the lookup is done via the
{{org.apache.sling.scripting.sightly.impl.engine.bundled.BundledUnitManagerImpl#getRenderUnit(javax.script.Bindings,
java.lang.String)}} service method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9655) Caching support for the GraphQL core
[ https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9655. - Fix Version/s: GraphQL Core 0.0.6 Resolution: Fixed > Caching support for the GraphQL core > > > Key: SLING-9655 > URL: https://issues.apache.org/jira/browse/SLING-9655 > Project: Sling > Issue Type: Task > Components: GraphQL >Affects Versions: GraphQL Core 0.0.4 >Reporter: Bertrand Delacretaz >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.6 > > > We've discussed [on our dev > list|https://lists.apache.org/thread.html/r00652fa5bc54f96bb3ec01264905d9a1f36677a71070fa1b724570f9%40%3Cdev.sling.apache.org%3E] > how to provide caching support and we'd like to leverage front-end HTTP > caches that people usually use in front of Sling. > The suggested* interaction scenario* is: > * 1) GraphQL queries executed via POST are not cached by Sling > * 2) Queries can be prepared in advance by POSTing the query text to > Sling, which returns a "201 created" status with a URL that contains > the query's digest, like cf81d4 > * 3) Clients run such prepared queries by making GET requests to URLs > like /graphqlservlet/prepared/cf81d4.json > * 4) The responses to such prepared queries requests contain HTTP > Cache headers which might (maybe in later phase) be set from hints supplied > by data fetchers with configurable defaults. This allows these responses to > be cached by the usual front-end HTTP caches, CDN etc. > * 5) There's no guarantee on how long the prepared queries are stored, a > client that gets a 404 on a prepared query request must be prepared to > use the default POST request method or store the prepared query again -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9714) ServletResourceProviderFactory should check for default resourceSuperType to determine if explicit resourceSuperType is provided in a servlet
[
https://issues.apache.org/jira/browse/SLING-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9714:
---
Assignee: Karl Pauls
> ServletResourceProviderFactory should check for default resourceSuperType to
> determine if explicit resourceSuperType is provided in a servlet
> -
>
> Key: SLING-9714
> URL: https://issues.apache.org/jira/browse/SLING-9714
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Resolver 2.7.8
>Reporter: Mohit Arora
>Assignee: Karl Pauls
>Priority: Major
>
> After SLING-8170, ServletResourceProviderFactory checks only for [non empty
> resourceSuperType
> property|https://github.com/apache/sling-org-apache-sling-servlets-resolver/blob/master/src/main/java/org/apache/sling/servlets/resolver/internal/resource/ServletResourceProviderFactory.java#L152]
> to determine whether an explicit resourceSuperType is provided for a
> servlet. However, if no resourceSuperType is provided, sling servlet
> annotations put default resourceSuperType of {{sling/bundle/resource}} on the
> servlet. So in order to determine an explicit resourceSuperType property, the
> factory should also check if the resourceSuperType is not the default one
> applied by the servlet annotations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9715) The JavaUseProvider does not properly handle the adaptable argument for Sling Model classes
[
https://issues.apache.org/jira/browse/SLING-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9715.
-
Resolution: Fixed
Fixed in:
* [commit
960d9cd|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/960d9cd]
* [commit
f266d23|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/f266d23]
* [commit
20f1108|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/20f1108]
> The JavaUseProvider does not properly handle the adaptable argument for Sling
> Model classes
> ---
>
> Key: SLING-9715
> URL: https://issues.apache.org/jira/browse/SLING-9715
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Paul Bjorkstrand
>Assignee: Radu Cotescu
>Priority: Major
>
> When Sling Models instantiation was added in SLING-9320
> ([commit|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bcd46027e09182911c55bb244d42debb1bd367c7]),
> it did not treat the {{adaptable}} argument the same for all types of
> instantiations (Sling Models vs basic Sling Adaptable). This fixes that by
> rearranging the instantiation attempt order, which puts the argument provided
> adaptable through {{ModelFactory#createModel}} just like the request and
> resource would be.
> This is a subtle semantic change, and likely warrants a minor version update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9715) The JavaUseProvider does not properly handle the adaptable argument for Sling Model classes
[
https://issues.apache.org/jira/browse/SLING-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9715:
Fix Version/s: Scripting HTL Testing 1.0.24-1.4.0
Scripting HTL Engine 1.4.4-1.4.0
Scripting HTL Testing Content 1.0.22-1.4.0
> The JavaUseProvider does not properly handle the adaptable argument for Sling
> Model classes
> ---
>
> Key: SLING-9715
> URL: https://issues.apache.org/jira/browse/SLING-9715
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Paul Bjorkstrand
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0, Scripting HTL Testing
> 1.0.24-1.4.0, Scripting HTL Testing Content 1.0.22-1.4.0
>
>
> When Sling Models instantiation was added in SLING-9320
> ([commit|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bcd46027e09182911c55bb244d42debb1bd367c7]),
> it did not treat the {{adaptable}} argument the same for all types of
> instantiations (Sling Models vs basic Sling Adaptable). This fixes that by
> rearranging the instantiation attempt order, which puts the argument provided
> adaptable through {{ModelFactory#createModel}} just like the request and
> resource would be.
> This is a subtle semantic change, and likely warrants a minor version update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-9715) The JavaUseProvider does not properly handle the adaptable argument for Sling Model classes
[
https://issues.apache.org/jira/browse/SLING-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-9715:
---
Assignee: Radu Cotescu
> The JavaUseProvider does not properly handle the adaptable argument for Sling
> Model classes
> ---
>
> Key: SLING-9715
> URL: https://issues.apache.org/jira/browse/SLING-9715
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Paul Bjorkstrand
>Assignee: Radu Cotescu
>Priority: Major
>
> When Sling Models instantiation was added in SLING-9320
> ([commit|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bcd46027e09182911c55bb244d42debb1bd367c7]),
> it did not treat the {{adaptable}} argument the same for all types of
> instantiations (Sling Models vs basic Sling Adaptable). This fixes that by
> rearranging the instantiation attempt order, which puts the argument provided
> adaptable through {{ModelFactory#createModel}} just like the request and
> resource would be.
> This is a subtle semantic change, and likely warrants a minor version update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9715) The JavaUseProvider does not properly handle the adaptable argument for Sling Model classes
[
https://issues.apache.org/jira/browse/SLING-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9715:
Summary: The JavaUseProvider does not properly handle the adaptable
argument for Sling Model classes (was: Sling models JavaUseProvider does not
properly handle the adaptable argument for Sling Model classes)
> The JavaUseProvider does not properly handle the adaptable argument for Sling
> Model classes
> ---
>
> Key: SLING-9715
> URL: https://issues.apache.org/jira/browse/SLING-9715
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Paul Bjorkstrand
>Priority: Major
>
> When Sling Models instantiation was added in SLING-9320
> ([commit|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bcd46027e09182911c55bb244d42debb1bd367c7]),
> it did not treat the {{adaptable}} argument the same for all types of
> instantiations (Sling Models vs basic Sling Adaptable). This fixes that by
> rearranging the instantiation attempt order, which puts the argument provided
> adaptable through {{ModelFactory#createModel}} just like the request and
> resource would be.
> This is a subtle semantic change, and likely warrants a minor version update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
[
https://issues.apache.org/jira/browse/SLING-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9696.
-
Fix Version/s: Scripting HTL Java Compiler 1.2.2-1.4.0
Scripting HTL Testing 1.0.24-1.4.0
Scripting HTL Compiler 1.2.8-1.4.0
Resolution: Fixed
Fixed in:
* [commit
4307b1e|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/commit/4307b1e]
* [commit
76bf4c8|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/76bf4c8]
* [commit
bfb098b|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/bfb098b]
* [commit
2cdbfef|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/2cdbfef]
Requires SLING-9706.
> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0,
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Compiler 1.2.8-1.4.0, Scripting HTL
> Testing 1.0.24-1.4.0, Scripting HTL Runtime 1.2.4-1.4.0, Scripting HTL Engine
> 1.4.4-1.4.0, Scripting HTL Java Compiler 1.2.2-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly
> casted the "false" string to boolean. The HTL specification [0] mentions the
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any
> casing of the string "false".
> A change like this has the potential to break the functionality of existing
> HTL code, relying on the fact that the string "false" (irrespective of its
> casing) returns the Boolean {{false}}, however the implementation should obey
> the specification. Therefore I think the fix should be behind a configuration
> flag, which by default allows the engine to continue working with the wrong
> behaviour. Deployers can then decide via configuration if they would like to
> switch the engine to the correct behaviour.
>
> [0] -
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9706) The HTL Java Compiler does not correctly negate equals
[
https://issues.apache.org/jira/browse/SLING-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-9706.
-
Resolution: Fixed
> The HTL Java Compiler does not correctly negate equals
> --
>
> Key: SLING-9706
> URL: https://issues.apache.org/jira/browse/SLING-9706
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Java Compiler 1.0.4, Scripting HTL Java
> Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.2.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Java Compiler 1.2.2-1.4.0
>
>
> Although the {{equals}} operation is only generated for internal HTL Compiler
> commands, the operation is not correctly negated when using the
> {{Binary.NEQ}} operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9706) The HTL Java Compiler does not correctly negate equals
[
https://issues.apache.org/jira/browse/SLING-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185761#comment-17185761
]
Radu Cotescu commented on SLING-9706:
-
Fixed in [commit
c092fb4|https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler-java/commit/c092fb4]
> The HTL Java Compiler does not correctly negate equals
> --
>
> Key: SLING-9706
> URL: https://issues.apache.org/jira/browse/SLING-9706
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting HTL Java Compiler 1.0.4, Scripting HTL Java
> Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.2.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Java Compiler 1.2.2-1.4.0
>
>
> Although the {{equals}} operation is only generated for internal HTL Compiler
> commands, the operation is not correctly negated when using the
> {{Binary.NEQ}} operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9706) The HTL Java Compiler does not correctly negate equals
Radu Cotescu created SLING-9706:
---
Summary: The HTL Java Compiler does not correctly negate equals
Key: SLING-9706
URL: https://issues.apache.org/jira/browse/SLING-9706
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Java Compiler 1.2.0-1.4.0, Scripting HTL
Java Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.0.4
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Java Compiler 1.2.2-1.4.0
Although the {{equals}} operation is only generated for internal HTL Compiler
commands, the operation is not correctly negated when using the {{Binary.NEQ}}
operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
[
https://issues.apache.org/jira/browse/SLING-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9696:
Fix Version/s: Scripting HTL Runtime 1.2.4-1.4.0
> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0,
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Runtime 1.2.4-1.4.0, Scripting HTL Engine
> 1.4.4-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly
> casted the "false" string to boolean. The HTL specification [0] mentions the
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any
> casing of the string "false".
> A change like this has the potential to break the functionality of existing
> HTL code, relying on the fact that the string "false" (irrespective of its
> casing) returns the Boolean {{false}}, however the implementation should obey
> the specification. Therefore I think the fix should be behind a configuration
> flag, which by default allows the engine to continue working with the wrong
> behaviour. Deployers can then decide via configuration if they would like to
> switch the engine to the correct behaviour.
>
> [0] -
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-9314) NPE in ObjectModel.toBoolean(Object) when object.toString() returns null
[ https://issues.apache.org/jira/browse/SLING-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185308#comment-17185308 ] Radu Cotescu edited comment on SLING-9314 at 8/26/20, 4:22 PM: --- Fixed in [commit 9669c6b|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/commit/9669c6b]. was (Author: radu.cotescu): Fixed in [commit 44d28b0|g...@github.com:apache/sling-org-apache-sling-scripting-sightly-runtime/commit/44d28b0]. > NPE in ObjectModel.toBoolean(Object) when object.toString() returns null > > > Key: SLING-9314 > URL: https://issues.apache.org/jira/browse/SLING-9314 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0, Scripting HTL Runtime > 1.1.0-1.4.0, Scripting HTL Runtime 1.1.2-1.4.0 >Reporter: Paul Bjorkstrand >Assignee: Radu Cotescu >Priority: Major > Fix For: Scripting HTL Runtime 1.2.4-1.4.0 > > > Though it is bad practice, it is possible that an object can return null from > its toString() method. ObjectModel.toBoolean(Object) \[[Line > 161|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/blob/master/src/main/java/org/apache/sling/scripting/sightly/render/ObjectModel.java#L161]\] > calls .trim() on a potentially null object. > This causes a difficult to troubleshoot, deeply nested, and cryptic exception > to be raised. If object.toString() returns null, then it should be treated > the same as nearly the rest of HTL, where null is considered "falsey". Doing > so will save hours of difficult troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
[
https://issues.apache.org/jira/browse/SLING-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9696:
Description:
The HTL engine implementation from Apache Sling seems to have never correctly
casted the "false" string to boolean. The HTL specification [0] mentions the
following:
{noformat}
These expressions evaluate to false:
* false
* 0 (zero)
* '' or "" (empty string)
* [] (empty iterable)
These evaluate to true:
* "false" (non-empty string)
* [0] (non-empty iterable)
{noformat}
However, all implementations have returned the Boolean {{false}} for any casing
of the string "false".
A change like this has the potential to break the functionality of existing HTL
code, relying on the fact that the string "false" (irrespective of its casing)
returns the Boolean {{false}}, however the implementation should obey the
specification. Therefore I think the fix should be behind a configuration flag,
which by default allows the engine to continue working with the wrong
behaviour. Deployers can then decide via configuration if they would like to
switch the engine to the correct behaviour.
[0] - [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
was:
The HTL engine implementation from Apache Sling seems to have never correctly
casted the "false" string to boolean. The HTL specification [0] mentions the
following:
{noformat}
These expressions evaluate to false:
* false
* 0 (zero)
* '' or "" (empty string)
* [] (empty iterable)
These evaluate to true:
* "false" (non-empty string)
* [0] (non-empty iterable)
{noformat}
[0] - https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting
> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0,
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.4.4-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly
> casted the "false" string to boolean. The HTL specification [0] mentions the
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any
> casing of the string "false".
> A change like this has the potential to break the functionality of existing
> HTL code, relying on the fact that the string "false" (irrespective of its
> casing) returns the Boolean {{false}}, however the implementation should obey
> the specification. Therefore I think the fix should be behind a configuration
> flag, which by default allows the engine to continue working with the wrong
> behaviour. Deployers can then decide via configuration if they would like to
> switch the engine to the correct behaviour.
>
> [0] -
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9314) NPE in ObjectModel.toBoolean(Object) when object.toString() returns null
[ https://issues.apache.org/jira/browse/SLING-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-9314. - Resolution: Fixed Fixed in [commit 44d28b0|g...@github.com:apache/sling-org-apache-sling-scripting-sightly-runtime/commit/44d28b0]. > NPE in ObjectModel.toBoolean(Object) when object.toString() returns null > > > Key: SLING-9314 > URL: https://issues.apache.org/jira/browse/SLING-9314 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL Runtime 1.0.0-1.4.0, Scripting HTL Runtime > 1.1.0-1.4.0, Scripting HTL Runtime 1.1.2-1.4.0 >Reporter: Paul Bjorkstrand >Assignee: Radu Cotescu >Priority: Major > Fix For: Scripting HTL Runtime 1.2.4-1.4.0 > > > Though it is bad practice, it is possible that an object can return null from > its toString() method. ObjectModel.toBoolean(Object) \[[Line > 161|https://github.com/apache/sling-org-apache-sling-scripting-sightly-runtime/blob/master/src/main/java/org/apache/sling/scripting/sightly/render/ObjectModel.java#L161]\] > calls .trim() on a potentially null object. > This causes a difficult to troubleshoot, deeply nested, and cryptic exception > to be raised. If object.toString() returns null, then it should be treated > the same as nearly the rest of HTL, where null is considered "falsey". Doing > so will save hours of difficult troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9696) HTL does not correctly cast the "false" string to Boolean
Radu Cotescu created SLING-9696:
---
Summary: HTL does not correctly cast the "false" string to Boolean
Key: SLING-9696
URL: https://issues.apache.org/jira/browse/SLING-9696
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.0-1.4.0, Scripting HTL Engine
1.3.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0, Scripting HTL Engine
1.1.0-1.4.0, Scripting HTL Engine 1.0.20, Scripting Sightly Engine 1.0.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Engine 1.4.4-1.4.0
The HTL engine implementation from Apache Sling seems to have never correctly
casted the "false" string to boolean. The HTL specification [0] mentions the
following:
{noformat}
These expressions evaluate to false:
* false
* 0 (zero)
* '' or "" (empty string)
* [] (empty iterable)
These evaluate to true:
* "false" (non-empty string)
* [0] (non-empty iterable)
{noformat}
[0] - https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9694) XSSAPIImpl#getValidHref does not escape the ampersand character
[
https://issues.apache.org/jira/browse/SLING-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185258#comment-17185258
]
Radu Cotescu commented on SLING-9694:
-
Copying the answer from SLING-9011:
I'm tempted to not pursue the fix here. The reason is that the newest version
of the HTML standard does not enforce this rule any more and it was most
probably based on the fact that most of the browsers are lenient and
automatically correct the URLs they use when accessing the resources.
Section 12.1.2.3 [0] of the HTML standard mentions which characters are not
allowed in an attribute value and the ampersand is not in this class. The
standard does mention that ambiguous ampersands are not allowed, but these are
defined as structures that look like a name character reference but are not
one. Given the potential of introducing an incompatible change, I'm not sure if
it would be really worth fixing this issue.
[0] - https://html.spec.whatwg.org/multipage/syntax.html#attributes-2
> XSSAPIImpl#getValidHref does not escape the ampersand character
> ---
>
> Key: SLING-9694
> URL: https://issues.apache.org/jira/browse/SLING-9694
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0, XSS Protection API 2.0.0, XSS
> Protection API 2.1.0, XSS Protection API 2.2.0, XSS Protection API Compat
> 1.1.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.2.8
>
>
> {{XSSAPIImpl#getValidHref}} does not escape the ampersand character, although
> the API's JavaDoc states that the method should "Sanitize a URL for writing
> as an HTML href or src attribute value".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
