[jira] [Resolved] (SLING-6047) SlingResourceTemplateResolver allows template resolution with decoupled logic enabled for non-markup template modes

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz resolved SLING-6047.
-
Resolution: Fixed

[r1759921|https://svn.apache.org/r1759921]

> SlingResourceTemplateResolver allows template resolution with decoupled logic 
> enabled for non-markup template modes
> ---
>
> Key: SLING-6047
> URL: https://issues.apache.org/jira/browse/SLING-6047
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Thymeleaf 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Thymeleaf 1.0.2
>
>
> decoupled logic can be used only with markup-based template modes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6047) SlingResourceTemplateResolver allows template resolution with decoupled logic enabled for non-markup template modes

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6047:
---

 Summary: SlingResourceTemplateResolver allows template resolution 
with decoupled logic enabled for non-markup template modes
 Key: SLING-6047
 URL: https://issues.apache.org/jira/browse/SLING-6047
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Thymeleaf 1.0.0
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Scripting Thymeleaf 1.0.2


decoupled logic can be used only with markup-based template modes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: What's wrong with Sightly?

[Oliver Lietz]

On Tuesday 06 September 2016 08:14:13 Roy T. Fielding wrote:
> It was a response to a third party's legal demand, not a marketing fail. A
> change to the name used by the software is suggested, not just a change of
> the language name. In fact, the language name would not normally be an
> issue.

If it may be a legal issue* to the project I would have expected at least a 
notice to the PMC's mailing list. And I wonder if removing Sightly from all 
package and class names *now* is not the safest route to go.

Regards,
O.

* which doesn't rule out a marketing fail, as it's marketing's job to do brand 
research and find out about possible naming conflicts

> Roy
> 
> > On Sep 6, 2016, at 6:39 AM, Oliver Lietz  wrote:
> >> On Tuesday 06 September 2016 00:03:22 Justin Edelson wrote:
> >> Simply put - because Adobe changed the language name. Since Adobe defines
> >> the specification and Sling just contains the implementation, it makes
> >> sense for the implementation to have the same name as the specification.
> >> Otherwise, we are implementing something which no longer exists.
> > 
> > Sorry, I have to disagree. The language or spec is one thing, the
> > implementation(s) a different. Most prominent example is HTML itself and
> > the various rendering engines, e.g. Gecko, KHTML, WebKit, Presto,
> > Tasman...
> > 
> > We now have a break between names and modules/packages and a bunch of dead
> > links. That mess is totally unnecessary. Marketing fail.
> > 
> > Adjusting the language name in Sling from Sighlty back to HTL (*sigh*)
> > would have been sufficient: Sling Sightly implementing (Adobe's) HTL.
> > 
> > @Radu, can you please revert the changes in Sling Launchpad 8 and Sling
> > IDE
> > Tooling 1.1 release news? The name of the language was Sightly at that
> > time.
> > 
> > Regards,
> > O.
> > 
> >>> On Mon, Sep 5, 2016 at 2:16 PM Oliver Lietz 
> >>> wrote:
> >>> hi all,
> >>> 
> >>> why do we rename Sightly in Sling back to HTL?
> >>> 
> >>> Thanks,
> >>> O.

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Oliver Lietz]

On Thursday 08 September 2016 17:48:24 Georg Henzler wrote:
> Hi Oliver,

Hi Georg,

> if we call it "oak", we probably would have to also create a sub folder
> contrib/oak (as all modules in contrib/jcr have the group id
> org.apache.sling.jcr)... that's probably more confusing than just
> leaving it in contrib/jcr (having jcr and oak side by side when oak also
> provides the jcr). Robert, what do you think?

I'm fine with it in contrib/extensions and moving it around in SVN is not a 
problem in contrast to changing packages later.

Regards,
O.

> Regards
> Georg
[...]

[jira] [Closed] (SLING-5788) Implement a Sightly Maven Plugin

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5788.
---

> Implement a Sightly Maven Plugin
> 
>
> Key: SLING-5788
> URL: https://issues.apache.org/jira/browse/SLING-5788
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: HTL Maven Plugin 1.0.0
>
>
> A Sightly Maven Plugin would be useful for static script validation. The 
> plugin can easily be developed based on the Sightly frontend compiler 
> extracted from SLING-5787.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5863) Make the sightly-maven-plugin m2e compatible

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5863.
---

> Make the sightly-maven-plugin m2e compatible
> 
>
> Key: SLING-5863
> URL: https://issues.apache.org/jira/browse/SLING-5863
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: HTL Maven Plugin 1.0.0
>
> Attachments: 
> 0001-SLING-5863-Make-the-sightly-maven-plugin-m2e-compati.patch
>
>
> Maven plug-ins can easily be made compatible with m2e for transparent 
> integration with Eclipse.
> We should add this to the sightly-maven-plugin and make the compilation 
> results available in Eclipse.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6009) Log compilation warnings

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-6009.
---

> Log compilation warnings
> 
>
> Key: SLING-6009
> URL: https://issues.apache.org/jira/browse/SLING-6009
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20
>
>
> Compilation warnings should be logged, like in version 1.0.18.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5632) [Sightly] URI manipulation options that process a path should not alter URIs that don't provide path information

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5632.
---

> [Sightly] URI manipulation options that process a path should not alter URIs 
> that don't provide path information
> 
>
> Key: SLING-5632
> URL: https://issues.apache.org/jira/browse/SLING-5632
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
>  Labels: Sightly
> Fix For: Scripting HTL Engine 1.0.20
>
>
> Code example
> {noformat}
> Our link
> {noformat}
> This normally works ok, but in case {{path}} points to a URL that doesn't 
> contain any path information "http://www.google.com;, then we don't want to 
> add the extension.
> Now this check has to be done every time we use the {{extension}} option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5825) Add support for implicit conversion of Enum to String

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5825.
---

> Add support for implicit conversion of Enum to String
> -
>
> Key: SLING-5825
> URL: https://issues.apache.org/jira/browse/SLING-5825
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL Engine 1.0.20
>
>
> Currently Sightly does not support implicit conversion from Enum to String 
> like in 
> {code}
> ...
> {code}
> The class attribute will always be empty in case when {{member.inviteStatus}} 
> is an Enum.
> Instead you have to write
> {code}
> ...
> {code}
> Sightly should implicitly convert enums to Strings if they are just given out.
> This is similar to SLING-5053.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5812) Add option to include attributes in request scope for Sightly data-sly-resource and data-sly-include

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5812.
---

> 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
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL 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] [Closed] (SLING-5811) Properly handle actual Resources in Sightly data-sly-resource

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5811.
---

> Properly handle actual Resources 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
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL 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] [Closed] (SLING-5554) Sightly: allow calling data-sly-use with a resource path

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5554.
---

> 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
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL Engine 1.0.20
>
>
> 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] [Closed] (SLING-5873) Update commons compiler to 2.3.0

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5873.
---

> Update commons compiler to 2.3.0
> 
>
> Key: SLING-5873
> URL: https://issues.apache.org/jira/browse/SLING-5873
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Scripting HTL Engine 1.0.20
>
>
> We should update the outdated compiler version from 2.0 to 2.3 as 2.3 is the 
> first version which is able to handle java 8 compilation correctly



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5253.
---

> Remove getAdministrativeResourceResolver() from the Sightly engine
> --
>
> Key: SLING-5253
> URL: https://issues.apache.org/jira/browse/SLING-5253
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20
>
>
> 3 occurrences in 
> {{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6028) Replace Sightly references with HTL in both code and documentation

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-6028.
---

> Replace Sightly references with HTL in both code and documentation
> --
>
> Key: SLING-6028
> URL: https://issues.apache.org/jira/browse/SLING-6028
> Project: Sling
>  Issue Type: Task
>  Components: Documentation, Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10, Scripting 
> Sightly Engine 1.0.18, Scripting Sightly REPL 1.0.2, Scripting Sightly Models 
> Use Provider 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.12, Scripting HTL 
> Engine 1.0.20, Scripting HTL REPL 1.0.4, Scripting HTL Models Use Provider 
> 1.0.2
>
>
> Sightly references should be replaced with HTL in both code and documentation 
> in order to follow the renaming of the language. API and bundle names 
> providing it should not be changed.
> 1. https://docs.adobe.com/content/docs/en/htl/update.html
> 2. https://github.com/Adobe-Marketing-Cloud/htl-spec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5945) Using opening angle brackets twice in expression language leads to token recognition error

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5945.
---

> Using opening angle brackets twice in expression language leads to token 
> recognition error
> --
>
> Key: SLING-5945
> URL: https://issues.apache.org/jira/browse/SLING-5945
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20
>
>
> The following Sightly expression leads to an exception when used inside a 
> block element's content
> {code}
>  ${'<{0}> ' @ format=['myelement'], context='unsafe'}
> {code}.
> The error is 
> {code}
> token recognition error at: ''<{0}>' for expression ${'<{0}>
>   at 
> org.apache.sling.scripting.sightly.impl.engine.UnitLoader.getSourceCodeForScript(UnitLoader.java:135)
> {code}
> On the other hand
> {code}
>  ${'<{0} /> ' @ format=['myelement'], context='unsafe'}
> {code}
> works without any issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5813) Allow a Resource to be used as a Sightly Use-Object with data-sly-use

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5813.
---

> 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
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL 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] [Closed] (SLING-5314) Support setting the basename for the resource bundle backing the Sightly i18n Extension

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5314.
---

> Support setting the basename for the resource bundle backing the Sightly i18n 
> Extension
> ---
>
> Key: SLING-5314
> URL: https://issues.apache.org/jira/browse/SLING-5314
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20
>
>
> Currently it is not possible to set the basename for the Sightly i18n 
> extension.
> In addition to options {{hint}} and {{locale}} the option {{basename}} should 
> be supported.
> This is not part of the spec 
> (https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md#123-i18n)
>  but in the Sling context the additional option would be very handy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5787) Modularise the Sightly script engine

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5787.
---

> Modularise the Sightly script engine
> 
>
> Key: SLING-5787
> URL: https://issues.apache.org/jira/browse/SLING-5787
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 
> 1.0.0, Scripting HTL Java Compiler 1.0.0
>
>
> The Sightly script engine should be broken into three modules:
> # a Sightly frontend compiler that interprets Sightly scripts and produces an 
> Abstract Syntax Tree (AST)
> # a Sightly Java backend compiler that interprets the AST and produces Java 
> class files
> # a Compilable Script Engine that reuses the previous two modules



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6008) The display context cannot be overwritten for HTML attribute expressions

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-6008.
---

> The display context cannot be overwritten for HTML attribute expressions
> 
>
> Key: SLING-6008
> URL: https://issues.apache.org/jira/browse/SLING-6008
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 1.0.0
>
>
> The XSS display context cannot be overwritten any more for expressions that 
> should generate the value of HTML attributes:
> Markup:
> {code:html}
> Click
> {code}
> Logic:
> {code:javascript}
> use(function () {
> return {
> hrefValue: "$link.category('default','men','')"
> };
> });
> {code}
> Current output:
> {code:html}
> Click
> {code}
> However, with {{context='unsafe'}}, the output should actually be:
> {code:html}
> Click
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5944) Sightly doesn't allow to overwrite the context for `data-sly-element`

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5944.
---

> Sightly doesn't allow to overwrite the context for `data-sly-element`
> -
>
> Key: SLING-5944
> URL: https://issues.apache.org/jira/browse/SLING-5944
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 1.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> For the following Sightly script
> {code}
> 
> {code}
> the generated Servlet looks like this
> {code}
> Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", 
> "invalidelement", "unsafe"), "elementName");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write("<");
> out.write(RenderUtils.toString(var_tagvar0));
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" }
> out.write(">");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" out.write(RenderUtils.toString(var_tagvar0));
> out.write(">");
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write("");
> }
> {code}
> So the element name is XSS protected twice. First with 'unsafe' (which 
> doesn't modify the given literal) and then with 'elementname', which removes 
> the literal.
> Therefore the generated HTML from the servlet is {{}} instead of 
> {{}}
> This contradicts the documentation at 
> https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which 
> says
> {quote}
> For security reasons, data-sly-element accepts only the following element 
> names:
> a abbr address article aside b bdi bdo blockquote br caption cite code col 
> colgroup
> data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 
> header i ins
> kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong 
> sub 
> sup table tbody td tfoot th thead time tr u var wbr
> To set other elements, XSS security must be turned off (@context='unsafe').
> {quote}
> The HTL spec only says
> {quote}
> The element name is automatically XSS-protected with the elementName context, 
> which by the way doesn't allow elements like 

[jira] [Closed] (SLING-5978) Make Sightly throw compilation errors when unknown data-sly-* plugins are used

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-5978.
---

> Make Sightly throw compilation errors when unknown data-sly-* plugins are used
> --
>
> Key: SLING-5978
> URL: https://issues.apache.org/jira/browse/SLING-5978
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 1.0.0
>
>
> The current version of the {{MarkupHandler#obtainPlugin}} \[0\] method throws 
> an {{UnsupportedOperationException}} whenever an unknown {{data-sly-*}} 
> plugin is used. Instead, the method should just generate an error in the AST 
> stream.
> \[0\] - 
> https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/impl/html/dom/MarkupHandler.java#L403



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-6033) Update Sightly bundles to parent pom 28

[Radu Cotescu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu closed SLING-6033.
---

> Update Sightly bundles to parent pom 28
> ---
>
> Key: SLING-6033
> URL: https://issues.apache.org/jira/browse/SLING-6033
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10, Scripting 
> Sightly Engine 1.0.18, Scripting Sightly REPL 1.0.2, Scripting Sightly Models 
> Use Provider 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.12, Scripting HTL 
> Engine 1.0.20, Scripting HTL REPL 1.0.4, Scripting HTL Models Use Provider 
> 1.0.2, Scripting HTL Compiler 1.0.0, Scripting HTL Java Compiler 1.0.0
>
>
> The Sightly bundles should be update to use version 28 of the Apache Sling 
> parent pom.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT][VOTE] Release Apache Sling Scripting HTL Compiler 1.0.0, Apache Sling Scripting HTL Java Compiler 1.0.0, Apache Sling Scripting HTL Engine 1.0.20, Apache Sling Scripting HTL JS Use Provider 1

[Radu Cotescu]

Hi,

The release vote passes with 3 binding +1 from Robert Munteanu, Bertrand
Delacretaz and myself. I'll start promoting the artifacts.

Thanks,
Radu

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474417#comment-15474417
 ] 

Carsten Ziegeler commented on SLING-6025:
-

Ok, sounds good to me

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474377#comment-15474377
 ] 

Stefan Seifert commented on SLING-6025:
---

then we keep the annotation retention at RUNTIME as we need to parse the 
metadata at runtime (lazily, when needed).
the bnd plugin is then really dead simple:
https://github.com/stefanseifert/sling/blob/feature/SLING-6025-config-metadata-bndplugin/contrib/extensions/contextaware-config/tooling/bnd-plugin/src/main/java/org/apache/sling/contextaware/config/bndplugin/ConfigurationClassScannerPlugin.java

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474364#comment-15474364
 ] 

Carsten Ziegeler commented on SLING-6025:
-

[~sseif...@pro-vision.de] Right, storing the class names in a header could be 
enough in this case. Which retention policy are you planning to use for the 
annotations? 

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474331#comment-15474331
 ] 

Stefan Seifert commented on SLING-6025:
---

do we really need to store the annotation class' metadata in an intermediate 
format (e.g. XML) in the bundles resources?
if we only want to avoid the classpath scanning and configuring package names 
in the bundle header, we just could generate the list of annotation classes 
with the matching annotation in a bundle header variable, and leave everything 
else.

bonus: the bnd plugin is optional, if the developer defines the configuration 
class names manually in the bundle instructions.

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Oak Restrictions - Release 1.0.0 now?

[Georg Henzler]

Hi Oliver,

if we call it "oak", we probably would have to also create a sub folder 
contrib/oak (as all modules in contrib/jcr have the group id 
org.apache.sling.jcr)... that's probably more confusing than just 
leaving it in contrib/jcr (having jcr and oak side by side when oak also 
provides the jcr). Robert, what do you think?


Regards
Georg

On 2016-09-07 22:33, Oliver Lietz wrote:

On Monday 01 August 2016 13:37:26 Robert Munteanu wrote:

Hi Georg,


Hi,


On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
> Hi all,
>
> with SLING-5768/SLING-5891 fixed and the documentation in
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions
> .html
> we have everything needed to cut a first release IMHO - could
> someone
> take care of it?

I think we need to clarify two issues:

1. Bundle name and location

Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . I would rather
see it named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr .


the bundle is not using JCR API but Oak API only
(org.apache.jackrabbit.oak.spi.security.authorization.restriction). 
Shouldn't
we go for a simple module and package name 
org.apache.sling.oak.restriction?


Regards,
O.


2. Naming of the restrictions

There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
that we have agreement that this is the best name what we could come 
up

with before releasing and committing to this name "forever".

Once these are agreed on, I can take care of an initial release.

Robert

[1]: https://issues.apache.org/jira/browse/SLING-5768

RE: junit teleporter - is mockito needed with scope compile?

[Stefan Seifert]

i'm quite sure this was an oversight - i've changed the scope to "test" in rev. 
1759850  

stefan

>-Original Message-
>From: Andrei Dulvac [mailto:dul...@apache.org]
>Sent: Thursday, September 8, 2016 4:41 PM
>To: dev; k...@apache.org
>Subject: junit teleporter - is mockito needed with scope compile?
>
>Hi Konrad, all,
>
>In my upstream project, I've had a real issue when I updated my dependency
>to the latest teleporter, as mockito is brought in in the latest
>teleporter, and that one shadows stuff like the hamcrest matchers so I get
>a weird failure inside junit Assume.
>
>As part of SLING-5677, in r1743902, you added mockito with the default
>maven scope. Can it be just "test"? Is it actually used outside the tests
>for the teleporter itself?
>
>Cheers,
>- Andrei

junit teleporter - is mockito needed with scope compile?

[Andrei Dulvac]

Hi Konrad, all,

In my upstream project, I've had a real issue when I updated my dependency
to the latest teleporter, as mockito is brought in in the latest
teleporter, and that one shadows stuff like the hamcrest matchers so I get
a weird failure inside junit Assume.

As part of SLING-5677, in r1743902, you added mockito with the default
maven scope. Can it be just "test"? Is it actually used outside the tests
for the teleporter itself?

Cheers,
- Andrei

[jira] [Resolved] (SLING-4868) Provide Karaf Archive of Launchpad features

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz resolved SLING-4868.
-
   Resolution: Won't Fix
Fix Version/s: (was: Karaf Features 0.2.0)

Installing all of Sling's features doesn't make sense.

bq. The Apache Karaf KAR service is looking for features XML files in the KAR 
file, registers the features XML and automatically installs all features 
described in the features repositories present in the KAR file.

> Provide Karaf Archive of Launchpad features
> ---
>
> Key: SLING-4868
> URL: https://issues.apache.org/jira/browse/SLING-4868
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> [Karaf Archive - KAR|https://karaf.apache.org/manual/latest/kar]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4868) Provide Karaf Archive of Launchpad features

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-4868:

Description: [Karaf Archive - 
KAR|https://karaf.apache.org/manual/latest/kar]  (was: [Karaf Archive - 
KAR|http://karaf.apache.org/manual/latest/users-guide/kar.html])

> Provide Karaf Archive of Launchpad features
> ---
>
> Key: SLING-4868
> URL: https://issues.apache.org/jira/browse/SLING-4868
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0
>
>
> [Karaf Archive - KAR|https://karaf.apache.org/manual/latest/kar]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4868) Provide Karaf Archive of Launchpad features

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-4868:

Summary: Provide Karaf Archive of Launchpad features  (was: provide Karaf 
Archive of Launchpad features)

> Provide Karaf Archive of Launchpad features
> ---
>
> Key: SLING-4868
> URL: https://issues.apache.org/jira/browse/SLING-4868
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0
>
>
> [Karaf Archive - 
> KAR|http://karaf.apache.org/manual/latest/users-guide/kar.html]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[SERVELETS][GET] - StreamRendererServlet do not use Partial Content Response [code 206] for IE requests

[Ashok Panghal]

Hi

Since IE 11 expects "Accept-Ranges" [0] response header to start making
requests with Range header, so sling lack in streaming of video content for
IE users. We can add Accept-Ranges = bytes header to response , either
selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )
 or set this header always.

Without support of partial content response (206) for IE users, all large
video files are being downloaded in single chunk and user need to wait for
long to see video content playing.

Created a Sling issue [1] for this and attached a patch which sends
appropriate response header only for video/mp4.

-Ashok Kumar


[0]
http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11
[1] https://issues.apache.org/jira/browse/SLING-6046

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473842#comment-15473842
 ] 

Stefan Seifert commented on SLING-6025:
---

i'll try an experiment with a bnd plugin. benefit is: it should work with both 
maven-bundle-plugin and bnd-maven-plugin.

where should we store the build-time generated metadata files to (default 
value, configurable)?
* OSGI-INF/xxx is not good, its sling-specific
* SLING-INF or SLING-INF/xxx ist not good because SLING-INF is often used as 
sling-initial-content, may conflict when the developers is not aware of it.
* SLING-CONTEXTAWARE-CONFIG-INF is quite long, but on the safe side...


> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473811#comment-15473811
 ] 

Stefan Seifert commented on SLING-6040:
---

Completed: At revision: 1759810  

i reverted the splitup of resourcebuilder into impl and integration-test 
project, and switched resourcebuilder to resourcesolver-mock dependency instead 
- this is an easier way to avoid the cyclic dependency.

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 1.8.0, Testing Sling Mock 2.1.0, 
> Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Streaming uploads.

[Ian Boston]

Hi,

Any objections if I cut a release of [1] and [2]. Sling Engine 2.6.4 and
Sling Post Servlets 2.3.14 with Streaming upload support. No other issues
fixed in ether release.
I have asked some other to verify the fixes and will wait for their
feedback.

If I do, you might need to import my GPG keys as it's been years
(literally) since I did an Apache release.

Best Regards
Ian

1
https://issues.apache.org/jira/browse/SLING/fixforversion/12338148/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
2
https://issues.apache.org/jira/browse/SLING/fixforversion/12335856/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel

[jira] [Resolved] (SLING-6027) Support existing Chunked upload functionality in streaming mode.

[Ian Boston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Boston resolved SLING-6027.
---
Resolution: Fixed

Fixed in r1759789
Test scripts can be found in 
bundles/servlets/post/developer-tests/testFileUploads.sh and uptodate 
documentation of the protocol with differences from the published protocol 
discovered in the code at bundles/servlets/post/Protocols.md

> Support existing Chunked upload functionality in streaming mode.
> 
>
> Key: SLING-6027
> URL: https://issues.apache.org/jira/browse/SLING-6027
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Servlets Post 2.3.14
>
>
> The non streaming uploads support a  partial upload protocol implemented in 
> request parameters that is known in Sling terms as "Chunked" upload and 
> documented at 
> https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 
>  (not to be confused with Chunked Transfer encoding or the use of Http Range 
> headers).
> Sling Chunked uploading sends a sequence of POSTs containing multiple parts 
> of a file upload. When all the parts are uploaded a final request is sent 
> that causes all the parts to be merged into a single file in the JCR. From a 
> streaming point of view, each part can be streamed with the streaming 
> implementation supported by SLING-5948. Some additional code will be required 
> to set the file name appropriately and the struture.
> However, when the upload is completed, Sling must merge all the parts. To 
> maintain the streaming nature of the upload, this must be achieved without 
> incurring any local IO, otherwise the benefits of a streamed upload are lost.
> I am not certain how to achieve the merge given the limitations of the JCR 
> API other than by transferring all the body parts via the local JVM. That 
> won't incur local Disk IO but will multiply the overall IO requirement by 3x.
> If JCR/Oak had the functionality to concatenate Binaries it could do this 
> more efficiently depending on the DS implementation. If JCR/Oak exposed an 
> Seekable OutputStream the Application could avoid needing to save uploads to 
> the JCR as individual files. If JCR/Oak allowed an update to a binary to 
> start at a known location, again this could be avoided.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Ashok Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashok Kumar updated SLING-6046:
---
Description: 
Since IE 11 expects "Accept-Ranges" [0] response header to start making 
requests with Range header, so sling lack in streaming of video content for IE 
end users. We can add Accept-Ranges = bytes header to response , either 
selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
always.

Without support of partial content response (206) for IE users, all large video 
files are being downloaded in single chunk and user need to wait for long to 
see video content playing. 

[0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 
 

  was:
Since IE 11 expects "Accept-Ranges" response header to start making requests 
with Range header, so sling lack in streaming of video content for IE end 
users. We can add Accept-Ranges = bytes header to response , either selectively 
only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or always.

Without support of partial content response (206) for IE users, all large video 
files are being downloaded in single chunk and user need to wait for long to 
see video content playing. 

 


> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
> Attachments: StreamRendererServlet.java.patch
>
>
> Since IE 11 expects "Accept-Ranges" [0] response header to start making 
> requests with Range header, so sling lack in streaming of video content for 
> IE end users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
> [0] http://stackoverflow.com/questions/25654422/http-pseudo-streaming-in-ie11 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Ashok Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashok Kumar updated SLING-6046:
---
Description: 
Since IE 11 expects "Accept-Ranges" response header to start making requests 
with Range header, so sling lack in streaming of video content for IE end 
users. We can add Accept-Ranges = bytes header to response , either selectively 
only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or always.

Without support of partial content response (206) for IE users, all large video 
files are being downloaded in single chunk and user need to wait for long to 
see video content playing. 

 

  was:
Since IE 11 expects "Accept-Ranges" response header to start making requests 
with Range header, so sling lack in streaming of video content for IE end 
users. We can add Accept-Ranges = bytes header to response , either selectively 
only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or always.

 


> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
> Attachments: StreamRendererServlet.java.patch
>
>
> Since IE 11 expects "Accept-Ranges" response header to start making requests 
> with Range header, so sling lack in streaming of video content for IE end 
> users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
> Without support of partial content response (206) for IE users, all large 
> video files are being downloaded in single chunk and user need to wait for 
> long to see video content playing. 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Ashok Kumar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashok Kumar updated SLING-6046:
---
Attachment: StreamRendererServlet.java.patch

Patch attached to ensure StreamRendererServlet sends "Accept-Ranges" header for 
video/mp4 contenttype to ensure smooth streaming on IE for large files. 

> While Streaming Video to IE 11, StreamRendererServlet do not use Partial 
> Content Response [code 206]
> 
>
> Key: SLING-6046
> URL: https://issues.apache.org/jira/browse/SLING-6046
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Ashok Kumar
> Attachments: StreamRendererServlet.java.patch
>
>
> Since IE 11 expects "Accept-Ranges" response header to start making requests 
> with Range header, so sling lack in streaming of video content for IE end 
> users. We can add Accept-Ranges = bytes header to response , either 
> selectively only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or 
> always.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6046) While Streaming Video to IE 11, StreamRendererServlet do not use Partial Content Response [code 206]

[Ashok Kumar (JIRA)]

Ashok Kumar created SLING-6046:
--

 Summary: While Streaming Video to IE 11, StreamRendererServlet do 
not use Partial Content Response [code 206]
 Key: SLING-6046
 URL: https://issues.apache.org/jira/browse/SLING-6046
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Get 2.1.18
Reporter: Ashok Kumar


Since IE 11 expects "Accept-Ranges" response header to start making requests 
with Range header, so sling lack in streaming of video content for IE end 
users. We can add Accept-Ranges = bytes header to response , either selectively 
only for video/mp4 mimetype ( video tag on IE looks for mp4 )  or always.

 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4327) ResourceResolver aware of any mappings

[Krystian Panek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473216#comment-15473216
 ] 

Krystian Panek commented on SLING-4327:
---

Maybe there are some volunteers that will move forward the issue? ;) It is 
quite often a heavy blocker while implementing business features and forces to 
have some hardcoded method which reflects mappings done by resolver.

> ResourceResolver aware of any mappings
> --
>
> Key: SLING-4327
> URL: https://issues.apache.org/jira/browse/SLING-4327
> Project: Sling
>  Issue Type: Wish
>  Components: API
>Reporter: Kamil Ciecierski
>
> Provide ability to create a ResourceResolver which is aware of any mappings, 
> for example by providing proper argument mappingPath. In case of AEM it would 
> be possible to use publish instance mapping present under etc/publish.map to 
> on author instance.
> To achieve that the CommonResourceResolverFactoryImpl could be implementing 
> methods getResourceResolver() and getAdministrativeResourceResolver() with 
> additional argument defining the mapping location. The advantage of this 
> solution is that the created ResourceResolver can be used many times with the 
> same mappings. The drawback is that the mappings configuration will be found 
> and cached when they resourceresolver will be used for the first time - there 
> is no possibility to define the list of working mappings before. 
> The proposal of API extension:
> {code}
> ResourceResolver getResourceResolver(Map authenticationInfo, 
> String customRootMap) throws LoginException;
>  
> ResourceResolver getAdministrativeResourceResolver(Map 
> authenticationInfo, String customRootMap) throws LoginException;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)