[jira] [Created] (SLING-9079) [HTL] HTL/Sightly REPL not building with Java > 8
Vlad Bailescu created SLING-9079: Summary: [HTL] HTL/Sightly REPL not building with Java > 8 Key: SLING-9079 URL: https://issues.apache.org/jira/browse/SLING-9079 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting HTL REPL 1.0.6 Reporter: Vlad Bailescu The REPL is not building with Java 11: {code} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (set-bundle-required-execution-environment) on project org.apache.sling.scripting.sightly.repl: An Ant BuildException has occured: Unable to create javax script engine for javascript [ERROR] around Ant part ...
[jira] [Commented] (SLING-9079) [HTL] HTL/Sightly REPL not building with Java > 8
[ https://issues.apache.org/jira/browse/SLING-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038520#comment-17038520 ] Vlad Bailescu commented on SLING-9079: -- https://github.com/apache/sling-org-apache-sling-scripting-sightly-repl/pull/1 > [HTL] HTL/Sightly REPL not building with Java > 8 > - > > Key: SLING-9079 > URL: https://issues.apache.org/jira/browse/SLING-9079 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting HTL REPL 1.0.6 >Reporter: Vlad Bailescu >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The REPL is not building with Java 11: > {code} > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-antrun-plugin:1.8:run > (set-bundle-required-execution-environment) on project > org.apache.sling.scripting.sightly.repl: An Ant BuildException has occured: > Unable to create javax script engine for javascript > [ERROR] around Ant part ...
[jira] [Commented] (SLING-7538) Request attributes not correctly reset after using data-sly-resource or data-sly-include with requestAttributes
[ https://issues.apache.org/jira/browse/SLING-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404892#comment-16404892 ] Vlad Bailescu commented on SLING-7538: -- [~kwin], all attributes included in the {{requestAttributes}} option are being reset, even if they were present/overwritten or new. They are being collected at https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L78 and null values are kept for the new attributes (see https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ExtensionUtils.java#L60) so they get reset at https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/master/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L111 However, we are intentionally not taking a full snapshot of existing request attributes and resetting to that, so that we allow people to set their own attributes in their code after the include (which they should also take care to cleanup when needed). > Request attributes not correctly reset after using data-sly-resource or > data-sly-include with requestAttributes > --- > > Key: SLING-7538 > URL: https://issues.apache.org/jira/browse/SLING-7538 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL Engine 1.0.20 >Reporter: Konrad Windszus >Assignee: Radu Cotescu >Priority: Major > > The option {{requestAttributes}} introduced with SLING-5812 does not > correctly reset the request attributes after the request dispatcher returned. > The reason for that is that > https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L115 > does only reset those reset attributes which have been previously attached > to the request. In fact also all attributes which have been added initially > through the {{requestAttributes}} option need to be removed as well. If you > add a new request attribute to the request this new request attribute will > not be removed and would still be leveraged in a subsequent call to > `data-sly-resource` based on the same request (even if that one doesn't even > set an option {{requestAttributes}}). > The same applies to > https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/IncludeRuntimeExtension.java#L73. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7538) Request attributes not correctly reset after using data-sly-resource or data-sly-include with requestAttributes
[ https://issues.apache.org/jira/browse/SLING-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404975#comment-16404975 ] Vlad Bailescu commented on SLING-7538: -- [~kwin], there was a regression that was fixed in https://helpx.adobe.com/experience-manager/release-notes--aem-6-3-cumulative-fix-pack.html, can you check if that helps? > Request attributes not correctly reset after using data-sly-resource or > data-sly-include with requestAttributes > --- > > Key: SLING-7538 > URL: https://issues.apache.org/jira/browse/SLING-7538 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting HTL Engine 1.0.20 >Reporter: Konrad Windszus >Assignee: Radu Cotescu >Priority: Major > > The option {{requestAttributes}} introduced with SLING-5812 does not > correctly reset the request attributes after the request dispatcher returned. > The reason for that is that > https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L115 > does only reset those reset attributes which have been previously attached > to the request. In fact also all attributes which have been added initially > through the {{requestAttributes}} option need to be removed as well. If you > add a new request attribute to the request this new request attribute will > not be removed and would still be leveraged in a subsequent call to > `data-sly-resource` based on the same request (even if that one doesn't even > set an option {{requestAttributes}}). > The same applies to > https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/IncludeRuntimeExtension.java#L73. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7845) Add support for MockNode.orderBefore
Vlad Bailescu created SLING-7845: Summary: Add support for MockNode.orderBefore Key: SLING-7845 URL: https://issues.apache.org/jira/browse/SLING-7845 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing JCR Mock 1.3.6 Reporter: Vlad Bailescu Fix For: Testing JCR Mock 1.3.8 Currently {{MockNode}} does not offer implementation for {{orderBefore}}. We would like to use that in https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7845) Add support for MockNode.orderBefore
[ https://issues.apache.org/jira/browse/SLING-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588718#comment-16588718 ] Vlad Bailescu commented on SLING-7845: -- PR at https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/2 > Add support for MockNode.orderBefore > > > Key: SLING-7845 > URL: https://issues.apache.org/jira/browse/SLING-7845 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing JCR Mock 1.3.6 >Reporter: Vlad Bailescu >Priority: Blocker > Labels: pull-request-available > Fix For: Testing JCR Mock 1.3.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently {{MockNode}} does not offer implementation for {{orderBefore}}. We > would like to use that in > https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7845) Add support for MockNode.orderBefore
[ https://issues.apache.org/jira/browse/SLING-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590181#comment-16590181 ] Vlad Bailescu commented on SLING-7845: -- Thanks Stefan. Is there a plan to release JCR Mock (and possibly also update and release wcm.io AEM Mock)? Anything I can do to help with these? > Add support for MockNode.orderBefore > > > Key: SLING-7845 > URL: https://issues.apache.org/jira/browse/SLING-7845 > Project: Sling > Issue Type: New Feature > Components: Testing >Affects Versions: Testing JCR Mock 1.3.6 >Reporter: Vlad Bailescu >Assignee: Stefan Seifert >Priority: Blocker > Labels: pull-request-available > Fix For: Testing JCR Mock 1.4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently {{MockNode}} does not offer implementation for {{orderBefore}}. We > would like to use that in > https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-5554) Sightly: allow calling data-sly-use with a resource path
Vlad Bailescu created SLING-5554: Summary: Sightly: allow calling data-sly-use with a resource path Key: SLING-5554 URL: https://issues.apache.org/jira/browse/SLING-5554 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.0 Reporter: Vlad Bailescu Priority: Minor Following the [discussion on dev@sling.apache.org|http://mail-archives.apache.org/mod_mbox/sling-dev/201601.mbox/%3CCANG90TY3xo+kHC=rb30enap7dqgzeymrr4kg1tvzu+s8zw5...@mail.gmail.com%3E] I believe it would be nice if we can bind a resource (by path) to a variable using {{data-sly-use}}: {code} data-sly-use.myResource="${ '/content/myResource' }" {code} This will eliminate the need to create an use object for simple cases when we are reading properties from other resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5753) Use.init() not invoked for Java Use object which is also a Sling Model
[ https://issues.apache.org/jira/browse/SLING-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307916#comment-15307916 ] Vlad Bailescu commented on SLING-5753: -- [~lsantha], I also believe any hybrid classes (that want to use both Sling Models and Use POJOs APIs) should handle the two alternate initialization paths themselves. > Use.init() not invoked for Java Use object which is also a Sling Model > -- > > Key: SLING-5753 > URL: https://issues.apache.org/jira/browse/SLING-5753 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Models Use Provider 1.0.0 >Reporter: Levente Santha >Priority: Minor > Attachments: SLING_5753.patch > > > [~kwin], > In the situation where I start with a Java Use object and later decide to use > some convenient features of Sling Models, I have the surprise to experience > that as soon as my Java Use object gets the @Model annotation its init() > method is not invoked any more. > I can see no good reason for this, so I created a patch to fix it. > Please let me know what you think. > Thank you, Levente -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5811) Properly handle actual Resource's in Sightly data-sly-resource
Vlad Bailescu created SLING-5811: Summary: Properly handle actual Resource's in Sightly data-sly-resource Key: SLING-5811 URL: https://issues.apache.org/jira/browse/SLING-5811 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.18 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.20 At the moment Sightly {{data-sly-resource}} expects a resource path. The are moments where we already have a {{Resource}} that we need to include (such as including current resource or iterating and including children) and this leads to conversions such as {{Resource -> path -> Resource}} which are not desirable performance-wise. We should properly handle a resource passed as a parameter, such as: {code}{code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5812) Add option to include attributes in request scope for Sightly data-sly-request and data-sly-include
Vlad Bailescu created SLING-5812: Summary: Add option to include attributes in request scope for Sightly data-sly-request and data-sly-include Key: SLING-5812 URL: https://issues.apache.org/jira/browse/SLING-5812 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.18 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.20 A common pattern for sending information between scripts/components is setting specific attributes in request scope before including another resource or script. At the moment this cannot be done nicely in Sightly. It would be very helpful to set request attributes as in following examples: {code}{code} or: {code}{code} where {{attributesMap}} is a {{Map}} The attributes would be set before the actual script/resource inclusion and reset/unset back afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5813) Allow a Resource to be used as a Sightly Use-Object with data-sly-use
Vlad Bailescu created SLING-5813: Summary: Allow a Resource to be used as a Sightly Use-Object with data-sly-use Key: SLING-5813 URL: https://issues.apache.org/jira/browse/SLING-5813 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.18 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.20 At the moment, if we want to use a {{Resource}} (to invoke it's properties for example) we need a helper Use-Object to provide it. It would be more straightforward if we could just load it by path and bind it to a variable via {{data-sly-use}}: {code} ${myRes.title} {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5812) Add option to include attributes in request scope for Sightly data-sly-request and data-sly-include
[ https://issues.apache.org/jira/browse/SLING-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15351048#comment-15351048 ] Vlad Bailescu commented on SLING-5812: -- Created a pull request at https://github.com/apache/sling/pull/149 Patch available at https://patch-diff.githubusercontent.com/raw/apache/sling/pull/149.patch > Add option to include attributes in request scope for Sightly > data-sly-request and data-sly-include > --- > > Key: SLING-5812 > URL: https://issues.apache.org/jira/browse/SLING-5812 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.20 > > > A common pattern for sending information between scripts/components is > setting specific attributes in request scope before including another > resource or script. At the moment this cannot be done nicely in Sightly. > It would be very helpful to set request attributes as in following examples: > {code}{code} > or: > {code}{code} > where {{attributesMap}} is a {{Map}} > The attributes would be set before the actual script/resource inclusion and > reset/unset back afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5812) Add option to include attributes in request scope for Sightly data-sly-resource and data-sly-include
[ https://issues.apache.org/jira/browse/SLING-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-5812: - Summary: Add option to include attributes in request scope for Sightly data-sly-resource and data-sly-include (was: Add option to include attributes in request scope for Sightly data-sly-request and data-sly-include) > Add option to include attributes in request scope for Sightly > data-sly-resource and data-sly-include > > > Key: SLING-5812 > URL: https://issues.apache.org/jira/browse/SLING-5812 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.20 > > > A common pattern for sending information between scripts/components is > setting specific attributes in request scope before including another > resource or script. At the moment this cannot be done nicely in Sightly. > It would be very helpful to set request attributes as in following examples: > {code}{code} > or: > {code}{code} > where {{attributesMap}} is a {{Map}} > The attributes would be set before the actual script/resource inclusion and > reset/unset back afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5812) Add option to include attributes in request scope for Sightly data-sly-resource and data-sly-include
[ https://issues.apache.org/jira/browse/SLING-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352583#comment-15352583 ] Vlad Bailescu commented on SLING-5812: -- Hi [~jshurmer]! When including a resource or a script we cannot be sure who is rendering it (could be a servlet, JSP or Sightly script, or any other scripting engine), so I don't think we have a local scope that is common among these. The include goes through the {{SlingRequestDispatcher}} and uses the same pattern of setting request attributes (https://github.com/apache/sling/blob/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L84). This ensures the rendering code can access the variables, regardless of where the code comes from. To cut back on side-effects the request attributes are being reset/unset after the include. > Add option to include attributes in request scope for Sightly > data-sly-resource and data-sly-include > > > Key: SLING-5812 > URL: https://issues.apache.org/jira/browse/SLING-5812 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.20 > > > A common pattern for sending information between scripts/components is > setting specific attributes in request scope before including another > resource or script. At the moment this cannot be done nicely in Sightly. > It would be very helpful to set request attributes as in following examples: > {code}{code} > or: > {code}{code} > where {{attributesMap}} is a {{Map}} > The attributes would be set before the actual script/resource inclusion and > reset/unset back afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
Vlad Bailescu created SLING-5946: Summary: XSSAPI#encodeForJSString is not restrictive enough Key: SLING-5946 URL: https://issues.apache.org/jira/browse/SLING-5946 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: XSS Protection API 1.0.8 Reporter: Vlad Bailescu Fix For: XSS Protection API 1.0.10 Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding {{}} and {{
[jira] [Updated] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[ https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-5946: - Attachment: SLING_5946.patch Added proposed patch > XSSAPI#encodeForJSString is not restrictive enough > -- > > Key: SLING-5946 > URL: https://issues.apache.org/jira/browse/SLING-5946 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: XSS Protection API 1.0.8 >Reporter: Vlad Bailescu > Fix For: XSS Protection API 1.0.10 > > Attachments: SLING_5946.patch > > > Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding > {{}} and {{
[jira] [Updated] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough
[ https://issues.apache.org/jira/browse/SLING-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-5946: - Description: Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding {{}} and {{ > Key: SLING-5946 > URL: https://issues.apache.org/jira/browse/SLING-5946 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: XSS Protection API 1.0.8 >Reporter: Vlad Bailescu > Fix For: XSS Protection API 1.0.10 > > Attachments: SLING_5946.patch > > > Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding > {{}} and {{
[jira] [Commented] (SLING-6140) Adding number formatting to Sightly/HTL
[ https://issues.apache.org/jira/browse/SLING-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625323#comment-15625323 ] Vlad Bailescu commented on SLING-6140: -- I stand by my idea from https://github.com/apache/sling/pull/182#issuecomment-253245042 : we should have a generic formatter which would handle anything we might throw at it based on type of data and options. > Adding number formatting to Sightly/HTL > --- > > Key: SLING-6140 > URL: https://issues.apache.org/jira/browse/SLING-6140 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Feike Visser > > Ability to properly format numbers in Sightly/HTL > Proposed usages: > {code} > ${ 100 @ numberFormat = '.00' , locale = 'en_US'} > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-6445) HTL scripts do not compile on Windows if the compiler needs to generate any warnings
Vlad Bailescu created SLING-6445: Summary: HTL scripts do not compile on Windows if the compiler needs to generate any warnings Key: SLING-6445 URL: https://issues.apache.org/jira/browse/SLING-6445 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.18 Reporter: Vlad Bailescu Priority: Critical If an HTL script with potential warnings is compiled on Windows, the compiler will fail with a NPE like: {code} java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Unknown Source) at org.apache.sling.scripting.sightly.compiler.SightlyCompiler.getScriptError(SightlyCompiler.java:170) at org.apache.sling.scripting.sightly.compiler.SightlyCompiler.compile(SightlyCompiler.java:149) at org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.internalCompile(SightlyScriptEngine.java:135) at org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.compile(SightlyScriptEngine.java:80) at org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider.provide(RenderUnitProvider.java:126) at org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:72) at org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:75) {code} The compiler assumes that system line separators are being used in the files, which most of the times is not happening as the scripts might have been edited on another system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6445) HTL scripts do not compile on Windows if the compiler needs to generate any warnings
[ https://issues.apache.org/jira/browse/SLING-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15805117#comment-15805117 ] Vlad Bailescu commented on SLING-6445: -- Added PR. [~radu.cotescu], can you please have a look? > HTL scripts do not compile on Windows if the compiler needs to generate any > warnings > > > Key: SLING-6445 > URL: https://issues.apache.org/jira/browse/SLING-6445 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Vlad Bailescu >Priority: Critical > > If an HTL script with potential warnings is compiled on Windows, the compiler > will fail with a NPE like: > {code} > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(Unknown Source) > at > org.apache.sling.scripting.sightly.compiler.SightlyCompiler.getScriptError(SightlyCompiler.java:170) > at > org.apache.sling.scripting.sightly.compiler.SightlyCompiler.compile(SightlyCompiler.java:149) > at > org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.internalCompile(SightlyScriptEngine.java:135) > at > org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.compile(SightlyScriptEngine.java:80) > at > org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider.provide(RenderUnitProvider.java:126) > at > org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:72) > at > org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:75) > {code} > The compiler assumes that system line separators are being used in the files, > which most of the times is not happening as the scripts might have been > edited on another system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6490) Sightly doesn't render valid style attribute-value
[ https://issues.apache.org/jira/browse/SLING-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842758#comment-15842758 ] Vlad Bailescu commented on SLING-6490: -- [~fvisser]: The {{styleToken}} context is to be used for tokens, not CSS declarations (See https://github.com/Adobe-Marketing-Cloud/htl-spec/blob/master/SPECIFICATION.md#121-display-context). In your case you might want to use something like: {code:html} style="background-image: ${fv.backgroundImage}" {code} > Sightly doesn't render valid style attribute-value > -- > > Key: SLING-6490 > URL: https://issues.apache.org/jira/browse/SLING-6490 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Feike Visser > Labels: Sightly > > I have the following piece of Java: > {code} > public class Style { > public String style = "background-image: url('/path/to/image.jpg');"; > } > {code} > I can't get this value printed unless I use @ context = 'unsafe' > {code} > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6490) Sightly doesn't render valid style attribute-value
[ https://issues.apache.org/jira/browse/SLING-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842788#comment-15842788 ] Vlad Bailescu commented on SLING-6490: -- There's probably some name confusion because of the fact that CSS declarations can be part of the {{style}} attribute (string) value. The {{styleString}} context is supposed to be used for strings within the CSS declarations, ie: {code:html} style="background-image: url('${fv.url}')" {code} > Sightly doesn't render valid style attribute-value > -- > > Key: SLING-6490 > URL: https://issues.apache.org/jira/browse/SLING-6490 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Feike Visser > Labels: Sightly > > I have the following piece of Java: > {code} > public class Style { > public String style = "background-image: url('/path/to/image.jpg');"; > } > {code} > I can't get this value printed unless I use @ context = 'unsafe' > {code} > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6490) Sightly doesn't render valid style attribute-value
[ https://issues.apache.org/jira/browse/SLING-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842805#comment-15842805 ] Vlad Bailescu commented on SLING-6490: -- For more clarity: there is no HTL context at the moment that can handle entire CSS declarations. Same goes for JavaScript code and this is by design of the language/contexts so that HTL expression are only used in pin-point locations, instead of injecting large CSS/JS blocks of code. This keeps CSS and JS close to the HTML template. > Sightly doesn't render valid style attribute-value > -- > > Key: SLING-6490 > URL: https://issues.apache.org/jira/browse/SLING-6490 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Feike Visser > Labels: Sightly > > I have the following piece of Java: > {code} > public class Style { > public String style = "background-image: url('/path/to/image.jpg');"; > } > {code} > I can't get this value printed unless I use @ context = 'unsafe' > {code} > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6490) Sightly doesn't render valid style attribute-value
[ https://issues.apache.org/jira/browse/SLING-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842870#comment-15842870 ] Vlad Bailescu commented on SLING-6490: -- [~fvisser]: the escaping looks good to me, but {{backgroundimage}} should be {{background-image}} > Sightly doesn't render valid style attribute-value > -- > > Key: SLING-6490 > URL: https://issues.apache.org/jira/browse/SLING-6490 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Feike Visser >Assignee: Radu Cotescu > Labels: Sightly > > I have the following piece of Java: > {code} > public class Style { > public String style = "background-image: url('/path/to/image.jpg');"; > } > {code} > I can't get this value printed unless I use @ context = 'unsafe' > {code} > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-6584) Race condition in ModelAdapterFactory
Vlad Bailescu created SLING-6584: Summary: Race condition in ModelAdapterFactory Key: SLING-6584 URL: https://issues.apache.org/jira/browse/SLING-6584 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Impl 1.3.8 Reporter: Vlad Bailescu Priority: Critical Fix For: Sling Models Impl 1.3.10 There is a possible race condition in https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L807-L815 when two threads are trying to inject the same field, resulting in model not being constructed. {code} try { if (!accessible) { field.setAccessible(true); } field.set(createdObject, result.getValue()); } catch (Exception e) { return new ModelClassException("Could not inject field due to reflection issues", e); } finally { if (!accessible) { field.setAccessible(false); } } {code} This is exposed by the unit test attached: {code} org.apache.sling.models.impl.ModelAdapterFactory - Could not adapt to model org.apache.sling.models.factory.MissingElementsException: Could not inject all required fields into class org.apache.sling.models.testmodels.classes.WithOneConstructorModel at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:593) at org.apache.sling.models.impl.ModelAdapterFactory.internalCreateModel(ModelAdapterFactory.java:335) at org.apache.sling.models.impl.ModelAdapterFactory.getAdapter(ModelAdapterFactory.java:211) at org.apache.sling.models.impl.ConstructorTest$1ModelCreator.call(ConstructorTest.java:153) at org.apache.sling.models.impl.ConstructorTest$1ModelCreator.call(ConstructorTest.java:149) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Suppressed: org.apache.sling.models.factory.MissingElementException: Could not inject private int org.apache.sling.models.testmodels.classes.WithOneConstructorModel.attribute at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:598) ... 8 more Caused by: org.apache.sling.models.factory.ModelClassException: Could not inject field due to reflection issues at org.apache.sling.models.impl.ModelAdapterFactory.setField(ModelAdapterFactory.java:812) at org.apache.sling.models.impl.ModelAdapterFactory.access$100(ModelAdapterFactory.java:112) at org.apache.sling.models.impl.ModelAdapterFactory$SetFieldCallback.inject(ModelAdapterFactory.java:378) at org.apache.sling.models.impl.ModelAdapterFactory.injectElement(ModelAdapterFactory.java:473) at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:596) ... 8 more Caused by: java.lang.IllegalAccessException: Class org.apache.sling.models.impl.ModelAdapterFactory can not access a member of class org.apache.sling.models.testmodels.classes.WithOneConstructorModel with modifiers "private" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) at java.lang.reflect.Field.set(Field.java:755) at org.apache.sling.models.impl.ModelAdapterFactory.setField(ModelAdapterFactory.java:810) ... 12 more {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6584) Race condition in ModelAdapterFactory
[ https://issues.apache.org/jira/browse/SLING-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-6584: - Attachment: SLING-6584.test.patch > Race condition in ModelAdapterFactory > - > > Key: SLING-6584 > URL: https://issues.apache.org/jira/browse/SLING-6584 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Sling Models Impl 1.3.8 >Reporter: Vlad Bailescu >Priority: Critical > Fix For: Sling Models Impl 1.3.10 > > Attachments: SLING-6584.test.patch > > > There is a possible race condition in > https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L807-L815 > when two threads are trying to inject the same field, resulting in model not > being constructed. > {code} > try { > if (!accessible) { > field.setAccessible(true); > } > field.set(createdObject, result.getValue()); > } catch (Exception e) { > return new ModelClassException("Could not inject field due to reflection > issues", e); > } finally { > if (!accessible) { > field.setAccessible(false); > } > } > {code} > This is exposed by the unit test attached: > {code} > org.apache.sling.models.impl.ModelAdapterFactory - Could not adapt to model > org.apache.sling.models.factory.MissingElementsException: Could not inject > all required fields into class > org.apache.sling.models.testmodels.classes.WithOneConstructorModel > at > org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:593) > at > org.apache.sling.models.impl.ModelAdapterFactory.internalCreateModel(ModelAdapterFactory.java:335) > at > org.apache.sling.models.impl.ModelAdapterFactory.getAdapter(ModelAdapterFactory.java:211) > at > org.apache.sling.models.impl.ConstructorTest$1ModelCreator.call(ConstructorTest.java:153) > at > org.apache.sling.models.impl.ConstructorTest$1ModelCreator.call(ConstructorTest.java:149) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Suppressed: org.apache.sling.models.factory.MissingElementException: > Could not inject private int > org.apache.sling.models.testmodels.classes.WithOneConstructorModel.attribute > at > org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:598) > ... 8 more > Caused by: org.apache.sling.models.factory.ModelClassException: Could > not inject field due to reflection issues > at > org.apache.sling.models.impl.ModelAdapterFactory.setField(ModelAdapterFactory.java:812) > at > org.apache.sling.models.impl.ModelAdapterFactory.access$100(ModelAdapterFactory.java:112) > at > org.apache.sling.models.impl.ModelAdapterFactory$SetFieldCallback.inject(ModelAdapterFactory.java:378) > at > org.apache.sling.models.impl.ModelAdapterFactory.injectElement(ModelAdapterFactory.java:473) > at > org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:596) > ... 8 more > Caused by: java.lang.IllegalAccessException: Class > org.apache.sling.models.impl.ModelAdapterFactory can not access a member of > class org.apache.sling.models.testmodels.classes.WithOneConstructorModel with > modifiers "private" > at > sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at > java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at > java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Field.set(Field.java:755) > at > org.apache.sling.models.impl.ModelAdapterFactory.setField(ModelAdapterFactory.java:810) > ... 12 more > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6612) HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository
Vlad Bailescu created SLING-6612: Summary: HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository Key: SLING-6612 URL: https://issues.apache.org/jira/browse/SLING-6612 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.18 Reporter: Vlad Bailescu Priority: Critical HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository because the current implementation of the {{JavaUseProvider}} does not take into account the timestamps of the {{.java}} and {{.class}} files (and relies on {{ResourceChangeListener}} to track updates to the Java classes in the repo). I have attached a patch with a test that reproduces the issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6612) HTL/Sightly sometimes fails to recompile an updated Java POJO located in the repository
[ https://issues.apache.org/jira/browse/SLING-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-6612: - Attachment: SLING-6612-test.patch > HTL/Sightly sometimes fails to recompile an updated Java POJO located in the > repository > --- > > Key: SLING-6612 > URL: https://issues.apache.org/jira/browse/SLING-6612 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.18 >Reporter: Vlad Bailescu >Priority: Critical > Attachments: SLING-6612-test.patch > > > HTL/Sightly sometimes fails to recompile an updated Java POJO located in the > repository because the current implementation of the {{JavaUseProvider}} does > not take into account the timestamps of the {{.java}} and {{.class}} files > (and relies on {{ResourceChangeListener}} to track updates to the Java > classes in the repo). > I have attached a patch with a test that reproduces the issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare an version range for org.mozilla.javascript import
Vlad Bailescu created SLING-6780: Summary: org.apache.sling.scripting.sightly.js.provider does not declare an version range for org.mozilla.javascript import Key: SLING-6780 URL: https://issues.apache.org/jira/browse/SLING-6780 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Sightly JS Use Provider 1.0.10 Reporter: Vlad Bailescu The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not declaring a version range for the {{org.mozilla.javascript}} import in its manifest. This can become a problem when someone installs an incompatible version. The solution is simple: declare an explicit dependency on {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick up the correct version range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import
[ https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-6780: - Description: The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not declaring a version range for the {{org.mozilla.javascript}} import in its manifest. This can become a problem when someone installs an incompatible version. The solution is simple: make sure we declare a correct version range for {{org.mozilla.javascript}} import. (was: The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not declaring a version range for the {{org.mozilla.javascript}} import in its manifest. This can become a problem when someone installs an incompatible version. The solution is simple: declare an explicit dependency on {{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick up the correct version range.) > org.apache.sling.scripting.sightly.js.provider does not declare a version > range for the org.mozilla.javascript import > - > > Key: SLING-6780 > URL: https://issues.apache.org/jira/browse/SLING-6780 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly JS Use Provider 1.0.10 >Reporter: Vlad Bailescu >Assignee: Radu Cotescu > Fix For: Scripting HTL JS Use Provider 1.0.22 > > > The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not > declaring a version range for the {{org.mozilla.javascript}} import in its > manifest. This can become a problem when someone installs an incompatible > version. The solution is simple: make sure we declare a correct version range > for {{org.mozilla.javascript}} import. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import
[ https://issues.apache.org/jira/browse/SLING-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967266#comment-15967266 ] Vlad Bailescu commented on SLING-6780: -- [~olli], thanks for your input. Already discussed with [~radu.cotescu] and agreed we should add the version range manually and not rely on the dependency, please see the updated PR: https://github.com/apache/sling/pull/213 > org.apache.sling.scripting.sightly.js.provider does not declare a version > range for the org.mozilla.javascript import > - > > Key: SLING-6780 > URL: https://issues.apache.org/jira/browse/SLING-6780 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly JS Use Provider 1.0.10 >Reporter: Vlad Bailescu >Assignee: Radu Cotescu > Fix For: Scripting HTL JS Use Provider 1.0.22 > > > The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not > declaring a version range for the {{org.mozilla.javascript}} import in its > manifest. This can become a problem when someone installs an incompatible > version. The solution is simple: make sure we declare a correct version range > for {{org.mozilla.javascript}} import. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SLING-7207) Get rid of runtime reflection in HTL expression evaluation
Vlad Bailescu created SLING-7207: Summary: Get rid of runtime reflection in HTL expression evaluation Key: SLING-7207 URL: https://issues.apache.org/jira/browse/SLING-7207 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting HTL Engine 1.0.42, Scripting HTL Java Compiler 1.0.14, Scripting HTL Compiler 1.0.14 Reporter: Vlad Bailescu Fix For: Scripting HTL Java Compiler 1.0.16, Scripting HTL Engine 1.0.44 At the moment the following expression {code} ${obj.message} {code} generates this Java code: {code} Object _global_obj = null; _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", renderContext.getObjectModel().resolveProperty(_global_obj, "message"), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} Resolving the property is done via reflection at runtime. Given the fact that for most use providers (JS is an exception) we know the type of {{_global_obj}} we could determine the right method to call at compile time. Resulting code might look something like: {code} com.my.Obj _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", _global_obj.getMessage()), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7207) Get rid of runtime reflection in HTL expression evaluation
[ https://issues.apache.org/jira/browse/SLING-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-7207: - Description: At the moment the following expression {code} ${obj.message} {code} generates this Java code: {code} Object _global_obj = null; _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", renderContext.getObjectModel().resolveProperty(_global_obj, "message"), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} Resolving the property is done via reflection at runtime. Given the fact that for most use providers (JS is an exception) we know the type of {{_global_obj}} we could determine the right method to call at compile time. Resulting code might look something like: {code} com.my.Obj _global_obj = (com.my.Obj) renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", _global_obj.getMessage()), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} was: At the moment the following expression {code} ${obj.message} {code} generates this Java code: {code} Object _global_obj = null; _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", renderContext.getObjectModel().resolveProperty(_global_obj, "message"), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} Resolving the property is done via reflection at runtime. Given the fact that for most use providers (JS is an exception) we know the type of {{_global_obj}} we could determine the right method to call at compile time. Resulting code might look something like: {code} com.my.Obj _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", _global_obj.getMessage()), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} > Get rid of runtime reflection in HTL expression evaluation > -- > > Key: SLING-7207 > URL: https://issues.apache.org/jira/browse/SLING-7207 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting HTL Compiler 1.0.14, Scripting HTL Java > Compiler 1.0.14, Scripting HTL Engine 1.0.42 >Reporter: Vlad Bailescu > Fix For: Scripting HTL Java Compiler 1.0.16, Scripting HTL Engine > 1.0.44 > > > At the moment the following expression > {code} > ${obj.message} > {code} > generates this Java code: > {code} > Object _global_obj = null; > _global_obj = renderContext.call("use", "com.my.Obj", obj()); > { > Object var_0 = renderContext.call("xss", > renderContext.getObjectModel().resolveProperty(_global_obj, "message"), > "text"); > out.write(renderContext.getObjectModel().toString(var_0)); > } > {code} > Resolving the property is done via reflection at runtime. Given the fact that > for most use providers (JS is an exception) we know the type of > {{_global_obj}} we could determine the right method to call at compile time. > Resulting code might look something like: > {code} > com.my.Obj _global_obj = (com.my.Obj) renderContext.call("use", "com.my.Obj", > obj()); > { > Object var_0 = renderContext.call("xss", _global_obj.getMessage()), > "text"); > out.write(renderContext.getObjectModel().toString(var_0)); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7207) Get rid of runtime reflection in HTL expression evaluation
[ https://issues.apache.org/jira/browse/SLING-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-7207: - Description: At the moment the following expression {code} ${obj.message} {code} generates this Java code: {code} Object _global_obj = null; _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", renderContext.getObjectModel().resolveProperty(_global_obj, "message"), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} Resolving the property is done via reflection at runtime. Given the fact that for most use providers (JS is an exception) we know the type of {{_global_obj}} we could determine the right method to call at compile time. Resulting code might look something like: {code} com.my.Obj _global_obj = renderContext.call("use", com.my.Obj.class, obj()); { Object var_0 = renderContext.call("xss", _global_obj.getMessage()), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} was: At the moment the following expression {code} ${obj.message} {code} generates this Java code: {code} Object _global_obj = null; _global_obj = renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", renderContext.getObjectModel().resolveProperty(_global_obj, "message"), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} Resolving the property is done via reflection at runtime. Given the fact that for most use providers (JS is an exception) we know the type of {{_global_obj}} we could determine the right method to call at compile time. Resulting code might look something like: {code} com.my.Obj _global_obj = (com.my.Obj) renderContext.call("use", "com.my.Obj", obj()); { Object var_0 = renderContext.call("xss", _global_obj.getMessage()), "text"); out.write(renderContext.getObjectModel().toString(var_0)); } {code} > Get rid of runtime reflection in HTL expression evaluation > -- > > Key: SLING-7207 > URL: https://issues.apache.org/jira/browse/SLING-7207 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting HTL Compiler 1.0.14, Scripting HTL Java > Compiler 1.0.14, Scripting HTL Engine 1.0.42 >Reporter: Vlad Bailescu > Fix For: Scripting HTL Java Compiler 1.0.16, Scripting HTL Engine > 1.0.44 > > > At the moment the following expression > {code} > ${obj.message} > {code} > generates this Java code: > {code} > Object _global_obj = null; > _global_obj = renderContext.call("use", "com.my.Obj", obj()); > { > Object var_0 = renderContext.call("xss", > renderContext.getObjectModel().resolveProperty(_global_obj, "message"), > "text"); > out.write(renderContext.getObjectModel().toString(var_0)); > } > {code} > Resolving the property is done via reflection at runtime. Given the fact that > for most use providers (JS is an exception) we know the type of > {{_global_obj}} we could determine the right method to call at compile time. > Resulting code might look something like: > {code} > com.my.Obj _global_obj = renderContext.call("use", com.my.Obj.class, obj()); > { > Object var_0 = renderContext.call("xss", _global_obj.getMessage()), > "text"); > out.write(renderContext.getObjectModel().toString(var_0)); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized
[ https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916506#comment-16916506 ] Vlad Bailescu commented on SLING-8655: -- Since externalization is mostly related to the view part (of the MVC), I would rather we don't introduce this injector. The raw path can then be used, as usual, to get a hold of the resource it points to, while externalization is done when rendering the model: * for HTML, using HTL: something like {code}${model.pagePath @ externalized} {code} * for JSON, using a dedicated serializer: {code}@JsonSerialize(using = ExternalizedSerializer.class){code} > Add an Annotation to Sling Model to mark a property to be Externalized > -- > > Key: SLING-8655 > URL: https://issues.apache.org/jira/browse/SLING-8655 > Project: Sling > Issue Type: New Feature > Components: Sling Models >Affects Versions: Sling Models API 1.3.8 >Reporter: Andreas Schaefer >Assignee: Andreas Schaefer >Priority: Major > Fix For: Sling Models API 1.3.10 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > For Peregrine CMS we use Sling Models to obtain data in JSon format to be > rendered on the client side. This means that the returned content is not > externalized aka paths are not mapped to the external view. > Sling Model should have an Annotation (@ExternalizedPath) that marks a > property to be externalized when loaded. > In order to be flexible the Externalized Path Injector should be pluggable so > that customers can add their custom Externalized Path Providers if they > choose to do so. By default there is a provider that uses the Resource > Resolver's map() function. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (SLING-4546) Sightly: Improper handling of extension and selectors by data-sly-resource
Vlad Bailescu created SLING-4546: Summary: Sightly: Improper handling of extension and selectors by data-sly-resource Key: SLING-4546 URL: https://issues.apache.org/jira/browse/SLING-4546 Project: Sling Issue Type: Bug Components: Scripting Reporter: Vlad Bailescu Fix For: Scripting Sightly Engine 1.0.2 Sightly is not handling extensions and selectors properly in {{data-sly-resource}}: 1. Selectors included in path or parent resource are ignored if no selector-related option is specified 2. Extensions are ignored completely, Sightly assumes anything preceded by a dot is a selector This leads to: * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of {{'resource.html' @ selectors=\['selector'\]}} * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of {{'resource.html' @ selectors=\['selector', 'other'\]}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4546) Sightly: Improper handling of extension and selectors by data-sly-resource
[ https://issues.apache.org/jira/browse/SLING-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4546: - Description: Sightly is not handling extensions and selectors properly in {{data-sly-resource}}: # Selectors included in path or parent resource are ignored if no selector-related option is specified # Extensions are ignored completely, Sightly assumes anything preceded by a dot is a selector This leads to: * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of {{'resource.html' @ selectors=\['selector'\]}} * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of {{'resource.html' @ selectors=\['selector', 'other'\]}} was: Sightly is not handling extensions and selectors properly in {{data-sly-resource}}: 1. Selectors included in path or parent resource are ignored if no selector-related option is specified 2. Extensions are ignored completely, Sightly assumes anything preceded by a dot is a selector This leads to: * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of {{'resource.html' @ selectors=\['selector'\]}} * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of {{'resource.html' @ selectors=\['selector', 'other'\]}} > Sightly: Improper handling of extension and selectors by data-sly-resource > -- > > Key: SLING-4546 > URL: https://issues.apache.org/jira/browse/SLING-4546 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Vlad Bailescu > Fix For: Scripting Sightly Engine 1.0.2 > > > Sightly is not handling extensions and selectors properly in > {{data-sly-resource}}: > # Selectors included in path or parent resource are ignored if no > selector-related option is specified > # Extensions are ignored completely, Sightly assumes anything preceded by a > dot is a selector > This leads to: > * {{'resource.selector.html'}} being equivalent to {{'resource'}} instead of > {{'resource.html' @ selectors=\['selector'\]}} > * {{'resource.selector.html' @ addSelectors=\['other'\]}} being equivalent to > {{'resource' @ selectors=\['selector', 'html', 'other'\]}} instead of > {{'resource.html' @ selectors=\['selector', 'other'\]}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4525) XSS protection path mangling issue
[ https://issues.apache.org/jira/browse/SLING-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386431#comment-14386431 ] Vlad Bailescu commented on SLING-4525: -- [~radu.cotescu] Can you please check the fix in the PR? Thank you! > XSS protection path mangling issue > -- > > Key: SLING-4525 > URL: https://issues.apache.org/jira/browse/SLING-4525 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: XSS Protection API 1.0.0 >Reporter: Georg Koester >Priority: Minor > Attachments: > 0001-Add-testcases-for-getValidHref-showing-problem-in-co.patch > > > Last part in path gets prepended with an underscore if there is a colon in > the query string. Test appended, to be applied on > https://github.com/apache/sling/tree/196dea678c6010 > Test output: > Failed tests: > XSSAPIImplTest.testGetValidHref:267 Requested > '/content/items/searchpages.html?0_tag:id=geo' > expected: but > was: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4557) Add JSON and XML validation to the XSS Protection API
Vlad Bailescu created SLING-4557: Summary: Add JSON and XML validation to the XSS Protection API Key: SLING-4557 URL: https://issues.apache.org/jira/browse/SLING-4557 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Vlad Bailescu Priority: Minor Fix For: XSS Protection API 1.0.4 Add methods for JSON and XML validation in the XSS API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4557) Add JSON and XML validation to the XSS Protection API
[ https://issues.apache.org/jira/browse/SLING-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14388579#comment-14388579 ] Vlad Bailescu commented on SLING-4557: -- [~radu.cotescu] can you please check the submitted PR? Thank you! > Add JSON and XML validation to the XSS Protection API > - > > Key: SLING-4557 > URL: https://issues.apache.org/jira/browse/SLING-4557 > Project: Sling > Issue Type: New Feature > Components: Extensions >Affects Versions: XSS Protection API 1.0.2 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: XSS Protection API 1.0.4 > > > Add methods for JSON and XML validation in the XSS API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4562) Sightly: Allow passing of custom options to the I18n extension
Vlad Bailescu created SLING-4562: Summary: Sightly: Allow passing of custom options to the I18n extension Key: SLING-4562 URL: https://issues.apache.org/jira/browse/SLING-4562 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.0 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly JS Use Provider 1.0.2 The current [Sightly specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] only lists {{locale}} and {{hint}} as possible options for the I18n extensions and these are passed as parameters to the {{call(..)}} method. However, the [initial Sightly docs|http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#Internationalization] are referencing another option ({{source}}) that Adobe is using in AEM. We should pass a map containing option names and values to the extension {{call(..)}}, like we do in the resource inclusion extension, so that vendors such as Adobe can use custom options when extending this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4562) Sightly: Allow passing of custom options to the I18n extension
[ https://issues.apache.org/jira/browse/SLING-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14391177#comment-14391177 ] Vlad Bailescu commented on SLING-4562: -- [~radu.cotescu] can you please check the attached pull request? Thank you! > Sightly: Allow passing of custom options to the I18n extension > -- > > Key: SLING-4562 > URL: https://issues.apache.org/jira/browse/SLING-4562 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly JS Use Provider 1.0.2 > > > The current [Sightly > specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] > only lists {{locale}} and {{hint}} as possible options for the I18n > extensions and these are passed as parameters to the {{call(..)}} method. > However, the [initial Sightly > docs|http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#Internationalization] > are referencing another option ({{source}}) that Adobe is using in AEM. > We should pass a map containing option names and values to the extension > {{call(..)}}, like we do in the resource inclusion extension, so that vendors > such as Adobe can use custom options when extending this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4562) Sightly: Allow passing of custom options to the I18n extension
[ https://issues.apache.org/jira/browse/SLING-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4562: - Fix Version/s: (was: Scripting Sightly JS Use Provider 1.0.2) Scripting Sightly Engine 1.0.2 > Sightly: Allow passing of custom options to the I18n extension > -- > > Key: SLING-4562 > URL: https://issues.apache.org/jira/browse/SLING-4562 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.2 > > > The current [Sightly > specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] > only lists {{locale}} and {{hint}} as possible options for the I18n > extensions and these are passed as parameters to the {{call(..)}} method. > However, the [initial Sightly > docs|http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#Internationalization] > are referencing another option ({{source}}) that Adobe is using in AEM. > We should pass a map containing option names and values to the extension > {{call(..)}}, like we do in the resource inclusion extension, so that vendors > such as Adobe can use custom options when extending this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4562) Sightly: Allow passing of custom options to the I18n extension
[ https://issues.apache.org/jira/browse/SLING-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4562: - Description: The current [Sightly specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] only lists {{locale}} and {{hint}} as possible options for the I18n extensions and these are passed as parameters to the {{call(..)}} method. We should pass a map containing option names and values to the extension {{call(..)}}, like we do in the resource inclusion extension, so that this functionality can be extended. (was: The current [Sightly specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] only lists {{locale}} and {{hint}} as possible options for the I18n extensions and these are passed as parameters to the {{call(..)}} method. However, the [initial Sightly docs|http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#Internationalization] are referencing another option ({{source}}) that Adobe is using in AEM. We should pass a map containing option names and values to the extension {{call(..)}}, like we do in the resource inclusion extension, so that vendors such as Adobe can use custom options when extending this functionality.) > Sightly: Allow passing of custom options to the I18n extension > -- > > Key: SLING-4562 > URL: https://issues.apache.org/jira/browse/SLING-4562 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.2 > > > The current [Sightly > specification|https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n] > only lists {{locale}} and {{hint}} as possible options for the I18n > extensions and these are passed as parameters to the {{call(..)}} method. We > should pass a map containing option names and values to the extension > {{call(..)}}, like we do in the resource inclusion extension, so that this > functionality can be extended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype
Vlad Bailescu created SLING-4878: Summary: Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype Key: SLING-4878 URL: https://issues.apache.org/jira/browse/SLING-4878 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Resource Merger 1.2.8 Reporter: Vlad Bailescu Fix For: Resource Merger 1.2.10 Assuming a hierarchy as: {code} /x (supertype = x/y) /x/y {code} Then the OverridingResourcePicker#pickResources() method will enter an infinite loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype
[ https://issues.apache.org/jira/browse/SLING-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4878: - Attachment: sling-4878-infinite-loop-in-resourcemerger.patch > Resource Merger: Infinite loop in case a parent resource has one of its > children as a supertype > --- > > Key: SLING-4878 > URL: https://issues.apache.org/jira/browse/SLING-4878 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.2.8 >Reporter: Vlad Bailescu > Fix For: Resource Merger 1.2.10 > > Attachments: sling-4878-infinite-loop-in-resourcemerger.patch > > > Assuming a hierarchy as: > {code} > /x (supertype = x/y) > /x/y > {code} > Then the OverridingResourcePicker#pickResources() method will enter an > infinite loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype
[ https://issues.apache.org/jira/browse/SLING-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4878: - Attachment: (was: sling-4878-infinite-loop-in-resourcemerger.patch) > Resource Merger: Infinite loop in case a parent resource has one of its > children as a supertype > --- > > Key: SLING-4878 > URL: https://issues.apache.org/jira/browse/SLING-4878 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.2.8 >Reporter: Vlad Bailescu > Fix For: Resource Merger 1.2.10 > > Attachments: sling-4878-infinite-loop-in-resourcemerger.patch > > > Assuming a hierarchy as: > {code} > /x (supertype = x/y) > /x/y > {code} > Then the OverridingResourcePicker#pickResources() method will enter an > infinite loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4878) Resource Merger: Infinite loop in case a parent resource has one of its children as a supertype
[ https://issues.apache.org/jira/browse/SLING-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4878: - Attachment: sling-4878-infinite-loop-in-resourcemerger.patch > Resource Merger: Infinite loop in case a parent resource has one of its > children as a supertype > --- > > Key: SLING-4878 > URL: https://issues.apache.org/jira/browse/SLING-4878 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.2.8 >Reporter: Vlad Bailescu > Fix For: Resource Merger 1.2.10 > > Attachments: sling-4878-infinite-loop-in-resourcemerger.patch > > > Assuming a hierarchy as: > {code} > /x (supertype = x/y) > /x/y > {code} > Then the OverridingResourcePicker#pickResources() method will enter an > infinite loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4957) Sightly RenderContextImpl contains utility methods that don't belong there
Vlad Bailescu created SLING-4957: Summary: Sightly RenderContextImpl contains utility methods that don't belong there Key: SLING-4957 URL: https://issues.apache.org/jira/browse/SLING-4957 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.2 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.4 The current implementation of Sightly's {{RenderContext}} contains a lot of of utility methods ([example|https://github.com/apache/sling/blob/90d2ed9e42deb144a7f6e1610871e72726cd810a/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.java#L142]). These are not related to the actual context and belong to an utility class. They are also unrelated to a specific instance/state and should be made static. Refactoring these out of {{RenderContextImpl}} will allow us to avoid unnecessarily passing an object of this class to other parts of the code just to use these utility methods ([example|https://github.com/apache/sling/blob/90d2ed9e42deb144a7f6e1610871e72726cd810a/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/compiler/expression/node/BinaryOperator.java#L31]). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4957) Sightly RenderContextImpl contains utility methods that don't belong there
[ https://issues.apache.org/jira/browse/SLING-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4957: - Attachment: sling-4957.patch > Sightly RenderContextImpl contains utility methods that don't belong there > -- > > Key: SLING-4957 > URL: https://issues.apache.org/jira/browse/SLING-4957 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.2 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.6 > > Attachments: sling-4957.patch > > > The current implementation of Sightly's {{RenderContext}} contains a lot of > of utility methods > ([example|https://github.com/apache/sling/blob/90d2ed9e42deb144a7f6e1610871e72726cd810a/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.java#L142]). > These are not related to the actual context and belong to an utility class. > They are also unrelated to a specific instance/state and should be made > static. > Refactoring these out of {{RenderContextImpl}} will allow us to avoid > unnecessarily passing an object of this class to other parts of the code just > to use these utility methods > ([example|https://github.com/apache/sling/blob/90d2ed9e42deb144a7f6e1610871e72726cd810a/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/compiler/expression/node/BinaryOperator.java#L31]). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5411) Sightly formatting filter only replaces first 10 placeholders
[ https://issues.apache.org/jira/browse/SLING-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-5411: - Attachment: SLING-5411.patch Patch with included fix and TCK update. > Sightly formatting filter only replaces first 10 placeholders > - > > Key: SLING-5411 > URL: https://issues.apache.org/jira/browse/SLING-5411 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.6 >Reporter: Vlad Bailescu >Assignee: Radu Cotescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.10 > > Attachments: SLING-5411.patch > > > The Sightly formatting filter only replaces first 10 placeholders. > For an input of: > {code} > ${"1-{0}, 2-{1}, 3-{2}, 4-{3}, 5-{4}, 6-{5}, 7-{6}, 8-{7}, 9-{8}, 10-{9}, > 11-{10}, 12-{11}" @ format=[1,2,3,4,5,6,7,8,9,10,11,12]} > {code} > the current output is: > {code} > 1-1, 2-2, 3-3, 4-4, 5-5, 6-6, 7-7, 8-8, 9-9, 10-10, 11-{10}, 12-{11} > {code} > This is due to a bad regex pattern at > https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/filter/FormatFilter.java#L51, > where {{\d}} is used instead of {{\d+}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4176) Sightly: ScriptToken context is doing nothing
Vlad Bailescu created SLING-4176: Summary: Sightly: ScriptToken context is doing nothing Key: SLING-4176 URL: https://issues.apache.org/jira/browse/SLING-4176 Project: Sling Issue Type: Bug Components: Scripting Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.0 The context='styleToken' expression option doesn't seem to be doing anything (it seems to work as context='unsafe'). Similarly to scriptToken, this should actually be a validator that only allows following CSS tokens: - Identifiers, e.g.: red, or -moz-box-sizing - Numbers and dimensions, e.g.: 42, 42deg, .42s or 42% - Strings, e.g.: "it's there" - Hex colors, e.g.: #fff - Functions (making sure to have matching parenthesis!), e.g.: rgba(20%, 20%, 100%, 0.02), or url('data:image/png;base64,iVB...') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4177) Sightly: StyleString context doesn't properly escape
Vlad Bailescu created SLING-4177: Summary: Sightly: StyleString context doesn't properly escape Key: SLING-4177 URL: https://issues.apache.org/jira/browse/SLING-4177 Project: Sling Issue Type: Bug Components: Scripting Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.0 The {{context='styleString'}} expression option seems to escape strings the same way as {{context='scriptString'}}, but this breaks the string, making that context unusable. CSS strings are to be escaped {{\HH}} and not {{\xHH}} like in JS: https://developer.mozilla.org/en-US/docs/Web/CSS/string Consider following example: {code:html} .ft:after { content: "${'\'' @ context='styleString'}"; } .in:after { content: "${'\"' @ context='styleString'}"; } {code} Which currently gets incorrectly rendered as follows: {code:html} .ft:after { content: "\x27"; } .in:after { content: "\x22"; } {code} Following output would have been expected: {code:html} .ft:after { content: "\27"; } .in:after { content: "\22"; } {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4176) Sightly: StyleToken context is doing nothing
[ https://issues.apache.org/jira/browse/SLING-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4176: - Summary: Sightly: StyleToken context is doing nothing (was: Sightly: ScriptToken context is doing nothing) > Sightly: StyleToken context is doing nothing > > > Key: SLING-4176 > URL: https://issues.apache.org/jira/browse/SLING-4176 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Vlad Bailescu >Priority: Minor > Labels: Sightly > Fix For: Scripting Sightly Engine 1.0.0 > > > The context='styleToken' expression option doesn't seem to be doing anything > (it seems to work as context='unsafe'). Similarly to scriptToken, this should > actually be a validator that only allows following CSS tokens: > - Identifiers, e.g.: red, or -moz-box-sizing > - Numbers and dimensions, e.g.: 42, 42deg, .42s or 42% > - Strings, e.g.: "it's there" > - Hex colors, e.g.: #fff > - Functions (making sure to have matching parenthesis!), e.g.: rgba(20%, 20%, > 100%, 0.02), or url('data:image/png;base64,iVB...') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4177) Sightly: StyleString context doesn't properly escape
[ https://issues.apache.org/jira/browse/SLING-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228388#comment-14228388 ] Vlad Bailescu commented on SLING-4177: -- Yes, I'll send in a new pull request, I messed up my branch while trying to pull/merge the latest from trunk. Sorry about that, Vlad Sent from my mobile. > Sightly: StyleString context doesn't properly escape > > > Key: SLING-4177 > URL: https://issues.apache.org/jira/browse/SLING-4177 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Vlad Bailescu >Priority: Minor > Labels: Sightly > Fix For: Scripting Sightly Engine 1.0.0 > > > The {{context='styleString'}} expression option seems to escape strings the > same way as {{context='scriptString'}}, but this breaks the string, making > that context unusable. CSS strings are to be escaped {{\HH}} and not {{\xHH}} > like in JS: > https://developer.mozilla.org/en-US/docs/Web/CSS/string > Consider following example: > {code:html} > > .ft:after { content: "${'\'' @ context='styleString'}"; } > .in:after { content: "${'\"' @ context='styleString'}"; } > > {code} > Which currently gets incorrectly rendered as follows: > {code:html} > > .ft:after { content: "\x27"; } > .in:after { content: "\x22"; } > > {code} > Following output would have been expected: > {code:html} > > .ft:after { content: "\27"; } > .in:after { content: "\22"; } > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4313) Merge RuntimeExtension and ExtensionInstance to remove unneeded abstraction level
[ https://issues.apache.org/jira/browse/SLING-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4313: - Attachment: SLING-4313_-_Merge_RuntimeExtension_and_ExtensionInstance_to_remove_unneeded_abstraction.patch - Removed ExtensionInstance wrapper - Updated the RuntimeExtension interface to expose a call(..) method instead of provide(..) - Updated implementations of RuntimeExtension > Merge RuntimeExtension and ExtensionInstance to remove unneeded abstraction > level > - > > Key: SLING-4313 > URL: https://issues.apache.org/jira/browse/SLING-4313 > Project: Sling > Issue Type: Sub-task > Components: Scripting >Reporter: Radu Cotescu > Fix For: Scripting Sightly Engine 1.0.0 > > Attachments: > SLING-4313_-_Merge_RuntimeExtension_and_ExtensionInstance_to_remove_unneeded_abstraction.patch > > > The {{ExtensionInstance}} is an unneeded level of abstraction that has no > real value. Its behaviour should be provided by the {{RuntimeExtension}} > implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4314) The implementation of RenderContext#resolveProperty can be slow for certain cases
[ https://issues.apache.org/jira/browse/SLING-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4314: - Attachment: SLING-4314_-_The_implementation_of_RenderContext_resolveProperty_can_be_slow_for_certain.patch Added NoSuchMethodException throw in RenderContextImpl#getObjectNoArgMethod to differentiate the case when a method is not found from the one where the actual return is null. > The implementation of RenderContext#resolveProperty can be slow for certain > cases > - > > Key: SLING-4314 > URL: https://issues.apache.org/jira/browse/SLING-4314 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Radu Cotescu > Fix For: Scripting Sightly Engine 1.0.0 > > Attachments: > SLING-4314_-_The_implementation_of_RenderContext_resolveProperty_can_be_slow_for_certain.patch > > > The current implementation of > {{org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl#resolveProperty}} > is slow when the resolved methods of an object return {{null}} due to the > fact that {{getField}} is called without a real reason. > Instead, {{getField}} should be called only when a method is not found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
Vlad Bailescu created SLING-4346: Summary: Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size Key: SLING-4346 URL: https://issues.apache.org/jira/browse/SLING-4346 Project: Sling Issue Type: Bug Components: Scripting Reporter: Vlad Bailescu Fix For: Scripting Sightly Engine 1.0.2 The HTML parser used by Sightly to process templates is parsing incorrectly comments that span across it's internal char buffer size. Right now the buffer is set to 2048 characters, making the problem hard to see. The problem can be exposed by lowering the buffer size to 10 and feeding a string such as {code:java}"test test "{code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
[ https://issues.apache.org/jira/browse/SLING-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4346: - Attachment: SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch - Added helper method to handle comments - Fixed data handling for comments inside the parser state machine - Made internal char buffer size configurable - Added unit tests > Sightly: HtmlParser does not parse documents correctly when comments span > across internal char buffer size > -- > > Key: SLING-4346 > URL: https://issues.apache.org/jira/browse/SLING-4346 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Vlad Bailescu > Fix For: Scripting Sightly Engine 1.0.2 > > Attachments: > SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch > > > The HTML parser used by Sightly to process templates is parsing incorrectly > comments that span across it's internal char buffer size. Right now the > buffer is set to 2048 characters, making the problem hard to see. > The problem can be exposed by lowering the buffer size to 10 and feeding a > string such as {code:java}"test test "{code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4093) run performance tests to compare with JSP and Sightly
[ https://issues.apache.org/jira/browse/SLING-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4093: - Attachment: SLING-4093_-_Performance_tests_to_compare_JSP_and_Sightly.patch Added comparative test content for JSP (with scriptlets and EL) and Sightly (Java and Javascript Use API). > run performance tests to compare with JSP and Sightly > - > > Key: SLING-4093 > URL: https://issues.apache.org/jira/browse/SLING-4093 > Project: Sling > Issue Type: Test > Components: Scripting >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Minor > Fix For: Scripting Thymeleaf 0.0.6 > > Attachments: > SLING-4093_-_Performance_tests_to_compare_JSP_and_Sightly.patch > > > find out how Thymeleaf performs > [~klcodanr]: > {quote} > 1. Performance: > I found JSP to be roughly 10x faster in contrived tests than Sightly. I've > uploaded a package which can be run on an AEM6 instance showing the > performance difference between the JSP and Sightly text components here: > https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > {quote} > http://mail-archives.apache.org/mod_mbox/sling-dev/201410.mbox/%3cCAHbpyFZ0_f6V7jMTzj=zv0f3wvyjs2oyv6cowx3uucwn2n7...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4093) run performance tests to compare with JSP and Sightly
[ https://issues.apache.org/jira/browse/SLING-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303493#comment-14303493 ] Vlad Bailescu commented on SLING-4093: -- Added improvements to performance module and integration tests. Changes submitted in PR: https://github.com/apache/sling/pull/61. [~fmeschbe] and [~radu.cotescu], can you please check the changes? > run performance tests to compare with JSP and Sightly > - > > Key: SLING-4093 > URL: https://issues.apache.org/jira/browse/SLING-4093 > Project: Sling > Issue Type: Test > Components: Scripting >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Minor > Fix For: Scripting Thymeleaf 0.0.6 > > Attachments: > SLING-4093_-_Performance_tests_to_compare_JSP_and_Sightly.patch > > > find out how Thymeleaf performs > [~klcodanr]: > {quote} > 1. Performance: > I found JSP to be roughly 10x faster in contrived tests than Sightly. I've > uploaded a package which can be run on an AEM6 instance showing the > performance difference between the JSP and Sightly text components here: > https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > {quote} > http://mail-archives.apache.org/mod_mbox/sling-dev/201410.mbox/%3cCAHbpyFZ0_f6V7jMTzj=zv0f3wvyjs2oyv6cowx3uucwn2n7...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4093) run performance tests to compare with JSP and Sightly
[ https://issues.apache.org/jira/browse/SLING-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304842#comment-14304842 ] Vlad Bailescu commented on SLING-4093: -- I added base tests for JSP and Sightly and improvements to the performance testing framework. I believe the same structure/scaffolding can also be used for Thymeleaf so I saw no benefit in opening a new issue for Sightly vs JSP. > run performance tests to compare with JSP and Sightly > - > > Key: SLING-4093 > URL: https://issues.apache.org/jira/browse/SLING-4093 > Project: Sling > Issue Type: Test > Components: Scripting >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Minor > Fix For: Scripting Thymeleaf 0.0.6 > > Attachments: > SLING-4093_-_Performance_tests_to_compare_JSP_and_Sightly.patch > > > find out how Thymeleaf performs > [~klcodanr]: > {quote} > 1. Performance: > I found JSP to be roughly 10x faster in contrived tests than Sightly. I've > uploaded a package which can be run on an AEM6 instance showing the > performance difference between the JSP and Sightly text components here: > https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > {quote} > http://mail-archives.apache.org/mod_mbox/sling-dev/201410.mbox/%3cCAHbpyFZ0_f6V7jMTzj=zv0f3wvyjs2oyv6cowx3uucwn2n7...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SLING-4176) Sightly: StyleToken context is doing nothing
[ https://issues.apache.org/jira/browse/SLING-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu reopened SLING-4176: -- I just realized there's one case where we fail to offer XSS protection: {{url("javascript:alert(1)")}} I've prepared a patch for this case too. > Sightly: StyleToken context is doing nothing > > > Key: SLING-4176 > URL: https://issues.apache.org/jira/browse/SLING-4176 > Project: Sling > Issue Type: Bug > Components: Extensions, Scripting >Reporter: Vlad Bailescu >Assignee: Felix Meschberger >Priority: Minor > Labels: Sightly > Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 > > > The context='styleToken' expression option doesn't seem to be doing anything > (it seems to work as context='unsafe'). Similarly to scriptToken, this should > actually be a validator that only allows following CSS tokens: > - Identifiers, e.g.: red, or -moz-box-sizing > - Numbers and dimensions, e.g.: 42, 42deg, .42s or 42% > - Strings, e.g.: "it's there" > - Hex colors, e.g.: #fff > - Functions (making sure to have matching parenthesis!), e.g.: rgba(20%, 20%, > 100%, 0.02), or url('data:image/png;base64,iVB...') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4176) Sightly: StyleToken context is doing nothing
[ https://issues.apache.org/jira/browse/SLING-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4176: - Attachment: SLING-4176_Sightly_StyleToken_context_is_doing_nothing.patch > Sightly: StyleToken context is doing nothing > > > Key: SLING-4176 > URL: https://issues.apache.org/jira/browse/SLING-4176 > Project: Sling > Issue Type: Bug > Components: Extensions, Scripting >Reporter: Vlad Bailescu >Assignee: Felix Meschberger >Priority: Minor > Labels: Sightly > Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 > > Attachments: > SLING-4176_Sightly_StyleToken_context_is_doing_nothing.patch > > > The context='styleToken' expression option doesn't seem to be doing anything > (it seems to work as context='unsafe'). Similarly to scriptToken, this should > actually be a validator that only allows following CSS tokens: > - Identifiers, e.g.: red, or -moz-box-sizing > - Numbers and dimensions, e.g.: 42, 42deg, .42s or 42% > - Strings, e.g.: "it's there" > - Hex colors, e.g.: #fff > - Functions (making sure to have matching parenthesis!), e.g.: rgba(20%, 20%, > 100%, 0.02), or url('data:image/png;base64,iVB...') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4428) Sightly: scriptComment and styleComment contexts are not doing anything
Vlad Bailescu created SLING-4428: Summary: Sightly: scriptComment and styleComment contexts are not doing anything Key: SLING-4428 URL: https://issues.apache.org/jira/browse/SLING-4428 Project: Sling Issue Type: Bug Reporter: Vlad Bailescu Priority: Minor Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 The Sightly spec defines scriptComment context but in the current implementation it is not working as expected, as it's treated internally like a JS token. This needs to be fixed so that the comment context will work as expected. The spec will clarify usage of the scriptComment context (it will only be used for block comments, ie: /*...*/) and will also add styleComment (which will behave similarly): https://github.com/Adobe-Marketing-Cloud/sightly-spec/pull/12 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4483) Sightly: data-sly-resource does not properly resolve relative paths
Vlad Bailescu created SLING-4483: Summary: Sightly: data-sly-resource does not properly resolve relative paths Key: SLING-4483 URL: https://issues.apache.org/jira/browse/SLING-4483 Project: Sling Issue Type: Bug Reporter: Vlad Bailescu Priority: Minor The following resource inclusion is not working: {code:html} {code} The returned error is: {{org.apache.sling.scripting.sightly.impl.engine.extension.ResourceRuntimeExtension Script path cannot be empty}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4483) Sightly: data-sly-resource does not properly resolve relative paths
[ https://issues.apache.org/jira/browse/SLING-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4483: - Component/s: Scripting Affects Version/s: Scripting Sightly Engine 1.0.0 Fix Version/s: Scripting Sightly Engine 1.0.0 > Sightly: data-sly-resource does not properly resolve relative paths > --- > > Key: SLING-4483 > URL: https://issues.apache.org/jira/browse/SLING-4483 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.0 > > > The following resource inclusion is not working: > {code:html} > > {code} > The returned error is: > {{org.apache.sling.scripting.sightly.impl.engine.extension.ResourceRuntimeExtension > Script path cannot be empty}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4484) XSS POM references wrong scm URLs
Vlad Bailescu created SLING-4484: Summary: XSS POM references wrong scm URLs Key: SLING-4484 URL: https://issues.apache.org/jira/browse/SLING-4484 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: XSS Protection API 1.0.0 Reporter: Vlad Bailescu Priority: Trivial Fix For: XSS Protection API 1.0.0 The XSS API {{pom.xml}} references wrong locations of the project: {code:xml} scm:svn:http://svn.apache.org/repos/asf/sling/trunk/bundles/xss scm:svn:https://svn.apache.org/repos/asf/sling/trunk/bundles/xss http://svn.apache.org/viewvc/sling/trunk/bundles/xss {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4489) Sightly: Hyphenated identifiers cause a compilation exception in Sightly generated Java classes
Vlad Bailescu created SLING-4489: Summary: Sightly: Hyphenated identifiers cause a compilation exception in Sightly generated Java classes Key: SLING-4489 URL: https://issues.apache.org/jira/browse/SLING-4489 Project: Sling Issue Type: Bug Reporter: Vlad Bailescu Priority: Minor Using hyphenated identifiers leads to a compilation exception at runtime: {code:html} Test {code} The Sightly grammar does not allow hyphenated identifier so a proper parsing exception should be thrown instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4489) Sightly: Hyphenated identifiers cause a compilation exception in Sightly generated Java classes
[ https://issues.apache.org/jira/browse/SLING-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4489: - Component/s: Scripting Affects Version/s: Scripting Sightly Engine 1.0.0 Fix Version/s: Scripting Sightly Engine 1.0.0 > Sightly: Hyphenated identifiers cause a compilation exception in Sightly > generated Java classes > --- > > Key: SLING-4489 > URL: https://issues.apache.org/jira/browse/SLING-4489 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.0 > > > Using hyphenated identifiers leads to a compilation exception at runtime: > {code:html} > Test > {code} > The Sightly grammar does not allow hyphenated identifier so a proper parsing > exception should be thrown instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4428) Sightly: scriptComment and styleComment contexts are not doing anything
[ https://issues.apache.org/jira/browse/SLING-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4428. > Sightly: scriptComment and styleComment contexts are not doing anything > --- > > Key: SLING-4428 > URL: https://issues.apache.org/jira/browse/SLING-4428 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Vlad Bailescu >Assignee: Robert Munteanu >Priority: Minor > Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 > > > The Sightly spec defines scriptComment context but in the current > implementation it is not working as expected, as it's treated internally like > a JS token. This needs to be fixed so that the comment context will work as > expected. > The spec will clarify usage of the scriptComment context (it will only be > used for block comments, ie: /*...*/) and will also add styleComment (which > will behave similarly): > https://github.com/Adobe-Marketing-Cloud/sightly-spec/pull/12 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4484) XSS POM references wrong scm URLs
[ https://issues.apache.org/jira/browse/SLING-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4484. > XSS POM references wrong scm URLs > - > > Key: SLING-4484 > URL: https://issues.apache.org/jira/browse/SLING-4484 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: XSS Protection API 1.0.0 >Reporter: Vlad Bailescu >Assignee: Radu Cotescu >Priority: Trivial > Fix For: XSS Protection API 1.0.0 > > > The XSS API {{pom.xml}} references wrong locations of the project: > {code:xml} > > > scm:svn:http://svn.apache.org/repos/asf/sling/trunk/bundles/xss > > scm:svn:https://svn.apache.org/repos/asf/sling/trunk/bundles/xss > http://svn.apache.org/viewvc/sling/trunk/bundles/xss > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4483) Sightly: data-sly-resource does not properly resolve relative paths
[ https://issues.apache.org/jira/browse/SLING-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4483. > Sightly: data-sly-resource does not properly resolve relative paths > --- > > Key: SLING-4483 > URL: https://issues.apache.org/jira/browse/SLING-4483 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Assignee: Radu Cotescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.0 > > > The following resource inclusion is not working: > {code:html} > > {code} > The returned error is: > {{org.apache.sling.scripting.sightly.impl.engine.extension.ResourceRuntimeExtension > Script path cannot be empty}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4177) Sightly: StyleString context doesn't properly escape
[ https://issues.apache.org/jira/browse/SLING-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4177. > Sightly: StyleString context doesn't properly escape > > > Key: SLING-4177 > URL: https://issues.apache.org/jira/browse/SLING-4177 > Project: Sling > Issue Type: Bug > Components: Extensions, Scripting >Reporter: Vlad Bailescu >Assignee: Felix Meschberger >Priority: Minor > Labels: Sightly > Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 > > > The {{context='styleString'}} expression option seems to escape strings the > same way as {{context='scriptString'}}, but this breaks the string, making > that context unusable. CSS strings are to be escaped {{\HH}} and not {{\xHH}} > like in JS: > https://developer.mozilla.org/en-US/docs/Web/CSS/string > Consider following example: > {code:html} > > .ft:after { content: "${'\'' @ context='styleString'}"; } > .in:after { content: "${'\"' @ context='styleString'}"; } > > {code} > Which currently gets incorrectly rendered as follows: > {code:html} > > .ft:after { content: "\x27"; } > .in:after { content: "\x22"; } > > {code} > Following output would have been expected: > {code:html} > > .ft:after { content: "\27"; } > .in:after { content: "\22"; } > > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4093) run performance tests to compare with JSP and Sightly
[ https://issues.apache.org/jira/browse/SLING-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356885#comment-14356885 ] Vlad Bailescu commented on SLING-4093: -- I created SLING-4493 to track changes related to Sightly performance tests, sorry for polluting this issue. > run performance tests to compare with JSP and Sightly > - > > Key: SLING-4093 > URL: https://issues.apache.org/jira/browse/SLING-4093 > Project: Sling > Issue Type: Test > Components: Scripting >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Minor > Fix For: Scripting Thymeleaf 0.0.6 > > Attachments: > SLING-4093_-_Performance_tests_to_compare_JSP_and_Sightly.patch > > > find out how Thymeleaf performs > [~klcodanr]: > {quote} > 1. Performance: > I found JSP to be roughly 10x faster in contrived tests than Sightly. I've > uploaded a package which can be run on an AEM6 instance showing the > performance difference between the JSP and Sightly text components here: > https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > {quote} > http://mail-archives.apache.org/mod_mbox/sling-dev/201410.mbox/%3cCAHbpyFZ0_f6V7jMTzj=zv0f3wvyjs2oyv6cowx3uucwn2n7...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4493) Create performance tests for Sightly
Vlad Bailescu created SLING-4493: Summary: Create performance tests for Sightly Key: SLING-4493 URL: https://issues.apache.org/jira/browse/SLING-4493 Project: Sling Issue Type: Test Components: Scripting, Testing Affects Versions: Scripting Sightly Engine 1.0.0 Reporter: Vlad Bailescu Priority: Minor Fix For: Scripting Sightly Engine 1.0.0 Create performance tests for Sightly to evaluate current status and performance impact of changes: - Create test content covering major Sightly features - Test both Java and JS Use API against equivalent JSP scripts - Create tests and set relative thresholds for performance ratio between Sightly and JSP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4494) Performance: update performance test framework to allow comparison of results
Vlad Bailescu created SLING-4494: Summary: Performance: update performance test framework to allow comparison of results Key: SLING-4494 URL: https://issues.apache.org/jira/browse/SLING-4494 Project: Sling Issue Type: Test Reporter: Vlad Bailescu Priority: Minor Update the Sling performance test framework to allow comparison of test results. Specifically, add: - possibility to define a "reference test" and have the results of other tests compared to it - possibility to log results as a ratio compared to the "reference test" - possibility to define a maximum threshold and have the framework fail a test if it's ratio against the "reference test" exceeds this threshold -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4346) Sightly: HtmlParser does not parse documents correctly when comments span across internal char buffer size
[ https://issues.apache.org/jira/browse/SLING-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4346. > Sightly: HtmlParser does not parse documents correctly when comments span > across internal char buffer size > -- > > Key: SLING-4346 > URL: https://issues.apache.org/jira/browse/SLING-4346 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Vlad Bailescu >Assignee: Felix Meschberger > Fix For: Scripting Sightly Engine 1.0.0 > > Attachments: > SLING-4346_Sightly__HtmlParser_does_not_parse_documents_correctly_when_comments_span_acros.patch > > > The HTML parser used by Sightly to process templates is parsing incorrectly > comments that span across it's internal char buffer size. Right now the > buffer is set to 2048 characters, making the problem hard to see. > The problem can be exposed by lowering the buffer size to 10 and feeding a > string such as {code:java}"test test "{code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4176) Sightly: StyleToken context is doing nothing
[ https://issues.apache.org/jira/browse/SLING-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu closed SLING-4176. > Sightly: StyleToken context is doing nothing > > > Key: SLING-4176 > URL: https://issues.apache.org/jira/browse/SLING-4176 > Project: Sling > Issue Type: Bug > Components: Extensions, Scripting >Reporter: Vlad Bailescu >Assignee: Radu Cotescu >Priority: Minor > Labels: Sightly > Fix For: XSS Protection API 1.0.0, Scripting Sightly Engine 1.0.0 > > Attachments: > SLING-4176_Sightly_StyleToken_context_is_doing_nothing.patch > > > The context='styleToken' expression option doesn't seem to be doing anything > (it seems to work as context='unsafe'). Similarly to scriptToken, this should > actually be a validator that only allows following CSS tokens: > - Identifiers, e.g.: red, or -moz-box-sizing > - Numbers and dimensions, e.g.: 42, 42deg, .42s or 42% > - Strings, e.g.: "it's there" > - Hex colors, e.g.: #fff > - Functions (making sure to have matching parenthesis!), e.g.: rgba(20%, 20%, > 100%, 0.02), or url('data:image/png;base64,iVB...') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4493) Sightly: Create performance tests
[ https://issues.apache.org/jira/browse/SLING-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Bailescu updated SLING-4493: - Summary: Sightly: Create performance tests (was: Create performance tests for Sightly) > Sightly: Create performance tests > - > > Key: SLING-4493 > URL: https://issues.apache.org/jira/browse/SLING-4493 > Project: Sling > Issue Type: Test > Components: Scripting, Testing >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Minor > Fix For: Scripting Sightly Engine 1.0.0 > > > Create performance tests for Sightly to evaluate current status and > performance impact of changes: > - Create test content covering major Sightly features > - Test both Java and JS Use API against equivalent JSP scripts > - Create tests and set relative thresholds for performance ratio between > Sightly and JSP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4499) Sightly: Parsing errors should not show up in console/stdout
Vlad Bailescu created SLING-4499: Summary: Sightly: Parsing errors should not show up in console/stdout Key: SLING-4499 URL: https://issues.apache.org/jira/browse/SLING-4499 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Sightly Engine 1.0.0 Reporter: Vlad Bailescu Priority: Trivial Fix For: Scripting Sightly Engine 1.0.0 At the moment if Sightly encounters a parsing error (for input like {{$\{a-b\}}}) it will output a line in the console/{{stdout}}: {{line 1:4 token recognition error at: '-'}} This should not happen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4499) Sightly: Parsing errors should not show up in console/stdout
[ https://issues.apache.org/jira/browse/SLING-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14360421#comment-14360421 ] Vlad Bailescu commented on SLING-4499: -- Submitted patch, [~radu.cotescu] can you please help integrate it? Thank you! > Sightly: Parsing errors should not show up in console/stdout > > > Key: SLING-4499 > URL: https://issues.apache.org/jira/browse/SLING-4499 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting Sightly Engine 1.0.0 >Reporter: Vlad Bailescu >Priority: Trivial > Fix For: Scripting Sightly Engine 1.0.0 > > > At the moment if Sightly encounters a parsing error (for input like > {{$\{a-b\}}}) it will output a line in the console/{{stdout}}: {{line 1:4 > token recognition error at: '-'}} > This should not happen -- This message was sent by Atlassian JIRA (v6.3.4#6332)