[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=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] [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-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=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] [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=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] [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=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] [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-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=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] [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=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] [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] [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] [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] [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=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] [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] [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-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-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-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-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] [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=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] [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=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=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=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-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=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] [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-6140) Adding number formatting to Sightly/HTL
[
https://issues.apache.org/jira/browse/SLING-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [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] [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] [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=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] [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-request and data-sly-include
[
https://issues.apache.org/jira/browse/SLING-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [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] [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-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] [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=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-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] [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] [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] [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-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] [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-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-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] [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-tabpanelfocusedCommentId=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] [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] [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-tabpanelfocusedCommentId=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] [Commented] (SLING-4525) XSS protection path mangling issue
[ https://issues.apache.org/jira/browse/SLING-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:/content/items/[searchpages.html?0_tag%3a]id=geo but was:/content/items/[_searchpages.html?0_tag_]id=geo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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-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-tabpanelfocusedCommentId=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)
[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] [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] [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 !--/*comment*/--{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] [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-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}
div data-sly-resource=${@ path='.', resourceType='foo/bar'}/div
{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}
style
.ft:after { content: ${'\'' @ context='styleString'}; }
.in:after { content: ${'\' @ context='styleString'}; }
/style
{code}
Which currently gets incorrectly rendered as follows:
{code:html}
style
.ft:after { content: \x27; }
.in:after { content: \x22; }
/style
{code}
Following output would have been expected:
{code:html}
style
.ft:after { content: \27; }
.in:after { content: \22; }
/style
{code}
--
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] [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] [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}
template data-sly-template.bad-template=${ @ }Test/template
{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}
template data-sly-template.bad-template=${ @ }Test/template
{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] [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
connectionscm:svn:http://svn.apache.org/repos/asf/sling/trunk/bundles/xss/connection
developerConnectionscm:svn:https://svn.apache.org/repos/asf/sling/trunk/bundles/xss/developerConnection
urlhttp://svn.apache.org/viewvc/sling/trunk/bundles/xss/url
/scm
{code}
--
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}
div data-sly-resource=${@ path='.', resourceType='foo/bar'}/div
{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-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}
div data-sly-resource=${@ path='.', resourceType='foo/bar'}/div
{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-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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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] [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 !--/*comment*/--{code}
--
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 !--/*comment*/--{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] [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-tabpanelfocusedCommentId=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}
style
.ft:after { content: ${'\'' @ context='styleString'}; }
.in:after { content: ${'\' @ context='styleString'}; }
/style
{code}
Which currently gets incorrectly rendered as follows:
{code:html}
style
.ft:after { content: \x27; }
.in:after { content: \x22; }
/style
{code}
Following output would have been expected:
{code:html}
style
.ft:after { content: \27; }
.in:after { content: \22; }
/style
{code}
--
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}
style
.ft:after { content: ${'\'' @ context='styleString'}; }
.in:after { content: ${'\' @ context='styleString'}; }
/style
{code}
Which currently gets incorrectly rendered as follows:
{code:html}
style
.ft:after { content: \x27; }
.in:after { content: \x22; }
/style
{code}
Following output would have been expected:
{code:html}
style
.ft:after { content: \27; }
.in:after { content: \22; }
/style
{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)
