[jira] [Comment Edited] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna edited comment on SLING-5973 at 8/19/16 5:01 AM:
-

[~olli] I'm not able to run that test in my local env just now, however I have 
created another simple test that I believe demonstrates this issue:

https://github.com/micronode/whistlepost/blob/master/whistlepost-rewrite-lib/src/test/groovy/org/apache/cocoon/components/serializers/encoding/XMLEncoderTest.groovy

As these emoji characters exist above the 16bit unicode range, they can't be 
represented by a single unicode escape sequence in Java. However they can be 
represented as a "surrogate pair". eg:

{code}U+1F340 in Java is: "\ud83c\udf40"{code}

I found a good explanation of this here: 
http://stackoverflow.com/a/26231925/163223

The Cocoon HTMLSerializer uses an XMLEncoder implementation that encodes 
characters *one at a time*. Which means that it doesn't realize these two 
characters are a surrogate pair, and subsequently doesn't return the correct 
HTML escape code.

So I don't think this is necessarily a Sling issue, but perhaps a workaround 
might be to provide a different encoder that supports surrogate pairs.

*NOTE:* I will also raise this issue in the Cocoon project - it's interesting 
to search Apache.org to see this same problem in other projects (possibly with 
solutions):

https://issues.apache.org/jira/browse/THRIFT-3403?jql=text%20~%20%22surrogate%20pairs%22



was (Author: fortuna):
[~olli] I'm not able to run that test in my local env just now, however I have 
created another simple test that I believe demonstrates this issue:

https://github.com/micronode/whistlepost/blob/master/whistlepost-rewrite-lib/src/test/groovy/org/apache/cocoon/components/serializers/encoding/XMLEncoderTest.groovy

As these emoji characters exist above the 16bit unicode range, they can't be 
represented by a single unicode escape sequence in Java. However they can be 
represented as a "surrogate pair". eg:

{code}U+1F340 in Java is: "\ud83c\udf40"{code}

I found a good explanation of this here: 
http://stackoverflow.com/a/26231925/163223

The Cocoon HTMLSerializer uses an XMLEncoder implementation that encodes 
characters *one at a time*. Which means that it doesn't realize these two 
characters are a surrogate pair, and subsequently doesn't return the correct 
HTML escape code.

So I don't think this is necessarily a Sling issue, but perhaps a workaround 
might be to provide a different encoder that supports surrogate pairs.

NOTE: I will also raise this issue in the Cocoon project - it's interesting to 
search Apache.org to see this same problem in other projects (possibly with 
solutions):

https://issues.apache.org/jira/browse/THRIFT-3403?jql=text%20~%20%22surrogate%20pairs%22


> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Comment Edited] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna edited comment on SLING-5973 at 8/19/16 5:00 AM:
-

[~olli] I'm not able to run that test in my local env just now, however I have 
created another simple test that I believe demonstrates this issue:

https://github.com/micronode/whistlepost/blob/master/whistlepost-rewrite-lib/src/test/groovy/org/apache/cocoon/components/serializers/encoding/XMLEncoderTest.groovy

As these emoji characters exist above the 16bit unicode range, they can't be 
represented by a single unicode escape sequence in Java. However they can be 
represented as a "surrogate pair". eg:

{code}U+1F340 in Java is: "\ud83c\udf40"{code}

I found a good explanation of this here: 
http://stackoverflow.com/a/26231925/163223

The Cocoon HTMLSerializer uses an XMLEncoder implementation that encodes 
characters *one at a time*. Which means that it doesn't realize these two 
characters are a surrogate pair, and subsequently doesn't return the correct 
HTML escape code.

So I don't think this is necessarily a Sling issue, but perhaps a workaround 
might be to provide a different encoder that supports surrogate pairs.

NOTE: I will also raise this issue in the Cocoon project - it's interesting to 
search Apache.org to see this same problem in other projects (possibly with 
solutions):

https://issues.apache.org/jira/browse/THRIFT-3403?jql=text%20~%20%22surrogate%20pairs%22



was (Author: fortuna):
[~olli] I'm not able to run that test in my local env just now, however I have 
created another simple test that I believe demonstrates this issue:

https://github.com/micronode/whistlepost/blob/master/whistlepost-rewrite-lib/src/test/groovy/org/apache/cocoon/components/serializers/encoding/XMLEncoderTest.groovy

As these emoji characters exist above the 16bit unicode range, they can't be 
represented by a single unicode escape sequence in Java. However they can be 
represented as a "surrogate pair". eg:

{code}U+1F340 in Java is: "\ud83c\udf40"{code}

I found a good explanation of this here: 
http://stackoverflow.com/a/26231925/163223

The Cocoon HTMLSerializer uses an XMLEncoder implementation that encodes 
characters *one at a time*. Which means that it doesn't realize these two 
characters are a surrogate pair, and subsequently doesn't return the correct 
HTML escape code.

So I don't think this is necessarily a Sling issue, but perhaps a workaround 
might be to provide a different encoder that supports surrogate pairs.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna commented on SLING-5973:


[~olli] I'm not able to run that test in my local env just now, however I have 
created another simple test that I believe demonstrates this issue:

https://github.com/micronode/whistlepost/blob/master/whistlepost-rewrite-lib/src/test/groovy/org/apache/cocoon/components/serializers/encoding/XMLEncoderTest.groovy

As these emoji characters exist above the 16bit unicode range, they can't be 
represented by a single unicode escape sequence in Java. However they can be 
represented as a "surrogate pair". eg:

{code}U+1F340 in Java is: "\ud83c\udf40"{code}

I found a good explanation of this here: 
http://stackoverflow.com/a/26231925/163223

The Cocoon HTMLSerializer uses an XMLEncoder implementation that encodes 
characters *one at a time*. Which means that it doesn't realize these two 
characters are a surrogate pair, and subsequently doesn't return the correct 
HTML escape code.

So I don't think this is necessarily a Sling issue, but perhaps a workaround 
might be to provide a different encoder that supports surrogate pairs.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

RE: Sling Model default Implementation Picker

[Shurmer, Jordan]

Hi Stefan,

That makes sense. I was just surprised that Sling ended up picking the 
implementation for me. I'll try to put together something to make it 
configurable :)

It would be awesome to see details about this default FirstImplementationPicker 
added to the Sling Models [documentation][1]. I'm not familiar with where that 
project lives, but if someone points me in the right direction I'd be glad to 
submit an update to the doc as well.

[1]: https://sling.apache.org/documentation/bundles/models.html

Thanks,
Jordan Shurmer

-Original Message-
From: Stefan Seifert [mailto:sseif...@pro-vision.de] 
Sent: Thursday, August 18, 2016 5:30 PM
To: dev@sling.apache.org
Subject: RE: Sling Model default Implementation Picker

hello jordan.

you're right - the interface contract is defined here:
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/api/src/main/java/org/apache/sling/models/spi/ImplementationPicker.java

returning null always means "i cannot pick an implementation", but not "pick no 
other implementation and return null for the adaption". so the default first 
implementation picker always steps in as last resort.

if you really need this behavior and cannot find another solution for your 
usecase please create an improvement ticket. we cannot change the existing 
behavior, but we could make it configurable (e.g. a switch to disable the first 
implementation picker by configuration), or provide other means to further 
control the implementation picking behavior.

stefan


>-Original Message-
>From: Shurmer, Jordan [mailto:jshur...@scrippsnetworks.com]
>Sent: Thursday, August 18, 2016 10:07 PM
>To: dev@sling.apache.org
>Subject: Sling Model default Implementation Picker
>
>Hello Sling Devs,
>
>I've got a question about the sling models [FirstImplementationPicker][1].
>This appears to essentially be a "default" implementation picker. It 
>will be used in two situation: (1) my app doesn't provide any other 
>ImplementationPickers; (2) all my app's ImplementationPickers returned 
>null, declaring that they couldn't find an implementation.
>
>The Second situation has caused me a bit of pain today, and I'm 
>wondering FirstImplementationPicker was intended to act in that 
>situation. Here's my
>thinking:
>
>I have an interface which has multiple implementations. The correct 
>implementation will be chosen based on a property of the Resource being 
>adapted. If there is no Implementation found for one of the possible 
>values of that property, I would like the resource to *not* be adapted 
>(i.e. the
>adaptTo() returning null). So, I wrote a custom ImplementationPicker 
>and returned null when there is no matching implementation, but then 
>saw that one of my Impl's was chosen seemingly arbitrarily.
>
>I wonder if a "better" default implementation picker would return null 
>if it is given multiple implementationTypes since it can't determine 
>how one would want to choose one over the other, and only return the 
>implementationType if there is only one to choose from.
>
>WDYT? Do I just have bad expectations of this Interface?
>
>[1]:
>https://github.com/apache/sling/blob/trunk/bundles/extensions/models/im
>pl/s 
>rc/main/java/org/apache/sling/models/impl/FirstImplementationPicker.jav
>a
>
>
>Jordan Shurmer | Software Engineer | Scripps Lifestyle Studios
>
>9721 Sherrill Blvd, Knoxville TN 37932
>Office: 865-560-4887
>jshur...@scrippsnetworks.com
>
>SCRIPPS NETWORKS INTERACTIVE | the Leader in Lifestyle Media | 
>scrippsnetworksinteractive.com HGTV | Food Network | Travel Channel | 
>DIY Network | Cooking Channel | Great American Country | TVN | Fine 
>Living | Asian Food Channel

[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Lars Krapf (JIRA)]

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

Lars Krapf edited comment on SLING-4560 at 8/18/16 10:47 PM:
-

Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the test mentioned above does not contain bengali / 
hindi characters. FWIW, I tried to come up with a hindi test using google 
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class 
{code}\p{L}{code} is matching single unicode *code points* only. To match any 
letter including diacritics, one might use {code}\p{L}\p{M}*+{code}. See also 
[1] ("Unicode Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 


was (Author: chaotic):
Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the test mentioned above does not contain bengali / 
hindi characters. FWIW, I tried to come up with a hindi test using google 
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \\p\{L\} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \\p\{L\}\\p\{M\}*+. See also [1] ("Unicode 
Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Lars Krapf (JIRA)]

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

Lars Krapf edited comment on SLING-4560 at 8/18/16 10:47 PM:
-

Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the test mentioned above does not contain bengali / 
hindi characters. FWIW, I tried to come up with a hindi test using google 
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \\p\{L\} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \\p\{L\}\\p\{M\}*+. See also [1] ("Unicode 
Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 


was (Author: chaotic):
Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the test mentioned above does not contain bengali / 
hindi characters. FWIW, I tried to come up with a hindi test using google 
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \p{L} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Updated] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Lars Krapf (JIRA)]

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

Lars Krapf updated SLING-4560:
--
Attachment: xssapi.patch

Adding potential patch.

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Lars Krapf (JIRA)]

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

Lars Krapf edited comment on SLING-4560 at 8/18/16 10:44 PM:
-

Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the test mentioned above does not contain bengali / 
hindi characters. FWIW, I tried to come up with a hindi test using google 
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \p{L} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 


was (Author: chaotic):
Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the added test does not contain bengali / hindi 
characters. FWIW, I tried to come up with a hindi test using google translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \p{L} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Commented] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Lars Krapf (JIRA)]

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

Lars Krapf commented on SLING-4560:
---

Hello [~radu.cotescu]

With this change {{onSiteURL}} will accept spaces and colons and thus does no 
longer filter external  (and/or " javascript:") URLs.

This could be caught by the following additional 
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
 {"http://www.google.com\;>", ""},
{code}

Please note however, that the added test does not contain bengali / hindi 
characters. FWIW, I tried to come up with a hindi test using google translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
   {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
  
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
 
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}

Nonetheless, the summary is correct, this test too fails with the old regexps. 
The reason for this is that the unicode "letter" character class \p{L} is 
matching single unicode *code points* only. To match any letter including 
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").

I've added a corresponding patch to the regexp (changing only the character 
class) and added a couple of tests. 

Note, The test provided by [~jck] *would still fail* even with this change, but 
AFAICT that's correct, since these characters are symbols and not letters. 

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

RE: Sling Model default Implementation Picker

[Stefan Seifert]

hello jordan.

you're right - the interface contract is defined here:
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/api/src/main/java/org/apache/sling/models/spi/ImplementationPicker.java

returning null always means "i cannot pick an implementation", but not "pick no 
other implementation and return null for the adaption". so the default first 
implementation picker always steps in as last resort.

if you really need this behavior and cannot find another solution for your 
usecase please create an improvement ticket. we cannot change the existing 
behavior, but we could make it configurable (e.g. a switch to disable the first 
implementation picker by configuration), or provide other means to further 
control the implementation picking behavior.

stefan


>-Original Message-
>From: Shurmer, Jordan [mailto:jshur...@scrippsnetworks.com]
>Sent: Thursday, August 18, 2016 10:07 PM
>To: dev@sling.apache.org
>Subject: Sling Model default Implementation Picker
>
>Hello Sling Devs,
>
>I've got a question about the sling models [FirstImplementationPicker][1].
>This appears to essentially be a "default" implementation picker. It will
>be used in two situation: (1) my app doesn't provide any other
>ImplementationPickers; (2) all my app's ImplementationPickers returned
>null, declaring that they couldn't find an implementation.
>
>The Second situation has caused me a bit of pain today, and I'm wondering
>FirstImplementationPicker was intended to act in that situation. Here's my
>thinking:
>
>I have an interface which has multiple implementations. The correct
>implementation will be chosen based on a property of the Resource being
>adapted. If there is no Implementation found for one of the possible values
>of that property, I would like the resource to *not* be adapted (i.e. the
>adaptTo() returning null). So, I wrote a custom ImplementationPicker and
>returned null when there is no matching implementation, but then saw that
>one of my Impl's was chosen seemingly arbitrarily.
>
>I wonder if a "better" default implementation picker would return null if
>it is given multiple implementationTypes since it can't determine how one
>would want to choose one over the other, and only return the
>implementationType if there is only one to choose from.
>
>WDYT? Do I just have bad expectations of this Interface?
>
>[1]:
>https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/s
>rc/main/java/org/apache/sling/models/impl/FirstImplementationPicker.java
>
>
>Jordan Shurmer | Software Engineer | Scripps Lifestyle Studios
>
>9721 Sherrill Blvd, Knoxville TN 37932
>Office: 865-560-4887
>jshur...@scrippsnetworks.com
>
>SCRIPPS NETWORKS INTERACTIVE | the Leader in Lifestyle Media |
>scrippsnetworksinteractive.com
>HGTV | Food Network | Travel Channel | DIY Network | Cooking Channel |
>Great American Country | TVN | Fine Living | Asian Food Channel

Sling Model default Implementation Picker

[Shurmer, Jordan]

Hello Sling Devs,

I've got a question about the sling models [FirstImplementationPicker][1]. This 
appears to essentially be a "default" implementation picker. It will be used in 
two situation: (1) my app doesn't provide any other ImplementationPickers; (2) 
all my app's ImplementationPickers returned null, declaring that they couldn't 
find an implementation.

The Second situation has caused me a bit of pain today, and I'm wondering 
FirstImplementationPicker was intended to act in that situation. Here's my 
thinking:

I have an interface which has multiple implementations. The correct 
implementation will be chosen based on a property of the Resource being 
adapted. If there is no Implementation found for one of the possible values of 
that property, I would like the resource to *not* be adapted (i.e. the 
adaptTo() returning null). So, I wrote a custom ImplementationPicker and 
returned null when there is no matching implementation, but then saw that one 
of my Impl's was chosen seemingly arbitrarily. 

I wonder if a "better" default implementation picker would return null if it is 
given multiple implementationTypes since it can't determine how one would want 
to choose one over the other, and only return the implementationType if there 
is only one to choose from.

WDYT? Do I just have bad expectations of this Interface?
 
[1]: 
https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/FirstImplementationPicker.java


Jordan Shurmer | Software Engineer | Scripps Lifestyle Studios

9721 Sherrill Blvd, Knoxville TN 37932
Office: 865-560-4887
jshur...@scrippsnetworks.com

SCRIPPS NETWORKS INTERACTIVE | the Leader in Lifestyle Media | 
scrippsnetworksinteractive.com
HGTV | Food Network | Travel Channel | DIY Network | Cooking Channel | Great 
American Country | TVN | Fine Living | Asian Food Channel

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5973:
-

[~fortuna], when you add {{System.out.println(document.html());}} to the test 
you will see the emojis in console output (OS X).

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5973:
-

bq. escaping in form {{&\#x2602;}} is HTML specific and not compatible with the 
JSON spec.

[~sseif...@pro-vision.de], the HTML entities are just strings in JSON also. Why 
should they not be compatible? I think it's absolutely fine to put HTML in JSON 
strings (as long following the simple escape rules from RFC 4627 2.5).

{quote}
2.5.  Strings

   The representation of strings is similar to conventions used in the C
   family of programming languages.  A string begins and ends with
   quotation marks.  All Unicode characters may be placed within the
   quotation marks except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+
   through U+001F).
{quote}

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

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

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5944:


Yes, I would also like it better if Sightly would allow to explicitly switch 
the context. If that is possible the Adobe documentation doesn't need to be 
fixed.
Otherwise if we stick to what has been specified in the HTL spec the usage of 
data-sly-element is quite limited IMHO (just think about AngularJS directives 
which are based on an element names).

> 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 Sightly Engine 1.0.20
>
>  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] [Commented] (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:comment-tabpanel=15426755#comment-15426755
 ] 

Radu Cotescu commented on SLING-5944:
-

I guess the better approach here would be to actually allow switching the 
context to 'unsafe'. BTW, the source of truth is the HTL specification. I'll 
ask my documentation colleagues to correct the information from 
https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element.

> 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 Sightly Engine 1.0.20
>
>  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] [Commented] (SLING-5869) htl doesn't escape '%' character in uri context

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-5869:


[~radu.cotescu] AEM 6.1's 1.0.2

> htl doesn't escape '%' character in uri context
> ---
>
> Key: SLING-5869
> URL: https://issues.apache.org/jira/browse/SLING-5869
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>
> % char in an href will not be escaped by sightly. This will cause an issue in 
> case a space is immediately after it, e.g.
> "?message=5% fat only" will be escaped like "5%%20fat%20only", and %%20 will 
> crash some servers' request processing, at least it crashes sling's with 
> something like:
> {noformat}
> org.apache.sling.engine.impl.parameters.ParameterSupport 
> getRequestParameterMapInternal: Error parsing request
> java.lang.IllegalArgumentException: Bad escape sequence: %=l
> at 
> org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
> at 
> org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
> {noformat}



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

[jira] [Commented] (SLING-5869) htl doesn't escape '%' character in uri context

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5869:
-

What version of the Sightly engine did you use?

> htl doesn't escape '%' character in uri context
> ---
>
> Key: SLING-5869
> URL: https://issues.apache.org/jira/browse/SLING-5869
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>
> % char in an href will not be escaped by sightly. This will cause an issue in 
> case a space is immediately after it, e.g.
> "?message=5% fat only" will be escaped like "5%%20fat%20only", and %%20 will 
> crash some servers' request processing, at least it crashes sling's with 
> something like:
> {noformat}
> org.apache.sling.engine.impl.parameters.ParameterSupport 
> getRequestParameterMapInternal: Error parsing request
> java.lang.IllegalArgumentException: Bad escape sequence: %=l
> at 
> org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
> at 
> org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
> {noformat}



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

[jira] [Assigned] (SLING-5869) htl doesn't escape '%' character in uri context

[Radu Cotescu (JIRA)]

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

Radu Cotescu reassigned SLING-5869:
---

Assignee: Radu Cotescu

> htl doesn't escape '%' character in uri context
> ---
>
> Key: SLING-5869
> URL: https://issues.apache.org/jira/browse/SLING-5869
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>
> % char in an href will not be escaped by sightly. This will cause an issue in 
> case a space is immediately after it, e.g.
> "?message=5% fat only" will be escaped like "5%%20fat%20only", and %%20 will 
> crash some servers' request processing, at least it crashes sling's with 
> something like:
> {noformat}
> org.apache.sling.engine.impl.parameters.ParameterSupport 
> getRequestParameterMapInternal: Error parsing request
> java.lang.IllegalArgumentException: Bad escape sequence: %=l
> at 
> org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
> at 
> org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
> {noformat}



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

[jira] [Assigned] (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 reassigned SLING-5945:
---

Assignee: Radu Cotescu

> 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 Sightly 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] [Assigned] (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 reassigned SLING-5944:
---

Assignee: Radu Cotescu

> 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 Sightly Engine 1.0.20
>
>  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] [Created] (SLING-5978) Make Sightly throw compilation errors when unknown data-sly-* plugins are used

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-5978:
---

 Summary: 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 Sightly Compiler 1.0.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Priority: Minor


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] [Assigned] (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 reassigned SLING-5863:
---

Assignee: Radu Cotescu  (was: Robert Munteanu)

> 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: Radu Cotescu
> Fix For: Sightly 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] [Updated] (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 updated SLING-5944:

Fix Version/s: Scripting Sightly Engine 1.0.20

> 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
> Fix For: Scripting Sightly Engine 1.0.20
>
>  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] [Commented] (SLING-5841) Self closing DIV when using 'html' context in Sightly

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5841:
-

[~danchapman-pearson], how can I reproduce this? You haven't provided any 
details regarding the platform you're using.

> Self closing DIV when using 'html' context in Sightly
> -
>
> Key: SLING-5841
> URL: https://issues.apache.org/jira/browse/SLING-5841
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Dan Chapman
>Priority: Minor
>
> When I do:
> ${'' @context='html'}
> It outputs invalid HTML, it self-closes the element:
> 
> Only a set number of elements are permitted to self-close - 
> http://xahlee.info/js/html5_non-closing_tag.html.



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

[jira] [Updated] (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 updated SLING-5945:

Fix Version/s: Scripting Sightly Engine 1.0.20

> 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
> Fix For: Scripting Sightly 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] [Resolved] (SLING-5889) SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-5889.
-
Resolution: Cannot Reproduce

> SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails
> --
>
> Key: SLING-5889
> URL: https://issues.apache.org/jira/browse/SLING-5889
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Radu Cotescu
>  Labels: sling-IT
>
> Running mvn clean install in {{bundles/scripting/sightly/testing}} :
> {code}
> Failed tests: 
>   SlingSpecificsSightlyIT.testRepositoryPojoUpdate:186 expected:<[updated]> 
> but was:<[original]>
> Tests run: 388, Failures: 1, Errors: 0, Skipped: 0
> {code}
> Tentatively assigning to [~radu.cotescu], svn says you were there a lot ;-)



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

[jira] [Resolved] (SLING-5889) SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-5889.
-
Resolution: Fixed

Cannot reproduce any more - I think it was a side-effect of SLING-5253 while we 
were still working on SLING-5830, SLING-5838 and SLING-5930.

> SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails
> --
>
> Key: SLING-5889
> URL: https://issues.apache.org/jira/browse/SLING-5889
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Radu Cotescu
>  Labels: sling-IT
>
> Running mvn clean install in {{bundles/scripting/sightly/testing}} :
> {code}
> Failed tests: 
>   SlingSpecificsSightlyIT.testRepositoryPojoUpdate:186 expected:<[updated]> 
> but was:<[original]>
> Tests run: 388, Failures: 1, Errors: 0, Skipped: 0
> {code}
> Tentatively assigning to [~radu.cotescu], svn says you were there a lot ;-)



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

[jira] [Reopened] (SLING-5889) SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails

[Radu Cotescu (JIRA)]

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

Radu Cotescu reopened SLING-5889:
-

> SlingSpecificsSightlyIT.testRepositoryPojoUpdate fails
> --
>
> Key: SLING-5889
> URL: https://issues.apache.org/jira/browse/SLING-5889
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Radu Cotescu
>  Labels: sling-IT
>
> Running mvn clean install in {{bundles/scripting/sightly/testing}} :
> {code}
> Failed tests: 
>   SlingSpecificsSightlyIT.testRepositoryPojoUpdate:186 expected:<[updated]> 
> but was:<[original]>
> Tests run: 388, Failures: 1, Errors: 0, Skipped: 0
> {code}
> Tentatively assigning to [~radu.cotescu], svn says you were there a lot ;-)



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

[jira] [Closed] (SLING-5962) i18n filter should be registered with all servlet contexts

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-5962.
---

> i18n filter should be registered with all servlet contexts
> --
>
> Key: SLING-5962
> URL: https://issues.apache.org/jira/browse/SLING-5962
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: i18n 2.5.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.2
>
>
> With versions < 2.5.0 the i18n filter was registered using the Apache Felix 
> whiteboard, which means the filter was run with every request
> With 2.5.0, the filter is now registered using the OSGi Http Whiteboard, but 
> just with the Sling context.
> We should change this and register it with all contexts - as it was before.



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

[VOTE RESULT] Release Apache Sling i18n 2.5.2

[Carsten Ziegeler]

Vote passes with five binding +1 votes

Thanks

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Resolved] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-4560.
-
Resolution: Fixed

Pushed a potential fix in [r1756802|https://svn.apache.org/r1756802].

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Updated] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-4560:

Fix Version/s: XSS Protection API 1.0.14

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Assigned] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters

[Radu Cotescu (JIRA)]

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

Radu Cotescu reassigned SLING-4560:
---

Assignee: Radu Cotescu

> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
>
> I added (locally) 2 test cases to 
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi 
> characters) although it should pass as they are valid characters.



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

[jira] [Comment Edited] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Roland Schaer (JIRA)]

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

Roland Schaer edited comment on SLING-5975 at 8/18/16 2:33 PM:
---

[~kwin] This is useful especially when using jQuery to modify content which i 
assume might be a relatively common use-case. jQuery >= 1.3 is submitting 
multi-value fields in this form by default. As of now it's possible to switch 
back to the old behaviour by adding a request option {{traditional: true}} (see 
http://api.jquery.com/jquery.param/) but this needs to be set explicitly which 
is not obvious.

I found a more detailed reasoning about this change at 
http://benalman.com/news/2009/12/jquery-14-param-demystified.

As there is a workaround the type might be changed to Improvement or Wish.


was (Author: rschaer):
[~kwin] This is useful especially when using jQuery to modify content which i 
assume might be a relatively common use-case. jQuery >= 1.3 is submitting 
multi-value fields in this form by default. As of now it's possible to switch 
back to the old behaviour by adding a request option {{traditional: true}} (see 
http://api.jquery.com/jquery.param/) but this needs to be set explicitly which 
is not obvious.

I found a more detailed reasoning about this change at 
http://benalman.com/news/2009/12/jquery-14-param-demystified.

> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[jira] [Comment Edited] (SLING-5977) Refactor out SimpleDistributionAgent inner classes

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili edited comment on SLING-5977 at 8/18/16 2:30 PM:
-

fixed in r1756791 and 1756793.


was (Author: teofili):
fixed in r1756791.

> Refactor out SimpleDistributionAgent inner classes 
> ---
>
> Key: SLING-5977
> URL: https://issues.apache.org/jira/browse/SLING-5977
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{SimpleDistributionAgent}} has 2 inner classes that were created time ago 
> and that grew up in importance and complexity over time; it'd be good to 
> refactor those classes out for reading and testing code more comfortably.



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

[jira] [Commented] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Roland Schaer (JIRA)]

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

Roland Schaer commented on SLING-5975:
--

[~kwin] This is useful especially when using jQuery to modify content which i 
assume might be a relatively common use-case. jQuery >= 1.3 is submitting 
multi-value fields in this form by default. As of now it's possible to switch 
back to the old behaviour by adding a request option {{traditional: true}} (see 
http://api.jquery.com/jquery.param/) but this needs to be set explicitly which 
is not obvious.

I found a more detailed reasoning about this change at 
http://benalman.com/news/2009/12/jquery-14-param-demystified.

> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[jira] [Resolved] (SLING-5977) Refactor out SimpleDistributionAgent inner classes

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-5977.

Resolution: Fixed

fixed in r1756791.

> Refactor out SimpleDistributionAgent inner classes 
> ---
>
> Key: SLING-5977
> URL: https://issues.apache.org/jira/browse/SLING-5977
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{SimpleDistributionAgent}} has 2 inner classes that were created time ago 
> and that grew up in importance and complexity over time; it'd be good to 
> refactor those classes out for reading and testing code more comfortably.



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

[jira] [Updated] (SLING-5977) Refactor out SimpleDistributionAgent inner classes

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5977:
---
Component/s: Distribution

> Refactor out SimpleDistributionAgent inner classes 
> ---
>
> Key: SLING-5977
> URL: https://issues.apache.org/jira/browse/SLING-5977
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> {{SimpleDistributionAgent}} has 2 inner classes that were created time ago 
> and that grew up in importance and complexity over time; it'd be good to 
> refactor those classes out for reading and testing code more comfortably.



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

[jira] [Created] (SLING-5977) Refactor out SimpleDistributionAgent inner classes

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-5977:
--

 Summary: Refactor out SimpleDistributionAgent inner classes 
 Key: SLING-5977
 URL: https://issues.apache.org/jira/browse/SLING-5977
 Project: Sling
  Issue Type: Improvement
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution 0.2.0


{{SimpleDistributionAgent}} has 2 inner classes that were created time ago and 
that grew up in importance and complexity over time; it'd be good to refactor 
those classes out for reading and testing code more comfortably.



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

[jira] [Created] (SLING-5976) [SCD] Configurable "repacke and retry" transport mechanism

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-5976:
--

 Summary: [SCD] Configurable "repacke and retry" transport mechanism
 Key: SLING-5976
 URL: https://issues.apache.org/jira/browse/SLING-5976
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution 0.2.0


In some scenarios (e.g. distribution of resources whose binary properties are 
referenced) it may be required to have "recreate package and send again" 
mechanism.




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

[jira] [Updated] (SLING-5976) [SCD] Configurable "repackage and retry" transport mechanism

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5976:
---
Summary: [SCD] Configurable "repackage and retry" transport mechanism  
(was: [SCD] Configurable "repacke and retry" transport mechanism)

> [SCD] Configurable "repackage and retry" transport mechanism
> 
>
> Key: SLING-5976
> URL: https://issues.apache.org/jira/browse/SLING-5976
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> In some scenarios (e.g. distribution of resources whose binary properties are 
> referenced) it may be required to have "recreate package and send again" 
> mechanism.



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

[jira] [Resolved] (SLING-5686) Use distribution package info to pass remote.package.id

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-5686.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

> Use distribution package info to pass remote.package.id
> ---
>
> Key: SLING-5686
> URL: https://issues.apache.org/jira/browse/SLING-5686
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> Remote package id is passed via http header but we can now pass it as the 
> package info.



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

[jira] [Commented] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5975:


Why do we need to support those "modern parameter names"? Is there any RFC 
about multi-value parameter names ending withj {{[]}}?
I could only find the following reference about GET multi-value parameters 
http://stackoverflow.com/questions/24059773/correct-way-to-pass-multiple-values-for-same-parameter-name-in-get-request
 which is basically saying that there is no standard.

> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[jira] [Issue Comment Deleted] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Roland Schaer (JIRA)]

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

Roland Schaer updated SLING-5975:
-
Comment: was deleted

(was: See https://github.com/apache/sling/pull/162 for a possible patch.)

> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[jira] [Commented] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Roland Schaer (JIRA)]

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

Roland Schaer commented on SLING-5975:
--

See https://github.com/apache/sling/pull/162 for a possible patch.

> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[jira] [Commented] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-5975:
---

GitHub user roele opened a pull request:

https://github.com/apache/sling/pull/162

SLING-5975 - POST fails with modern multi-value parameter names containing 
brackets



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/roele/sling SLING-5975

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/162.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #162


commit 363fd50b6a40e0e1b8de03b4770bfcbb724ec48b
Author: Roland Schaer 
Date:   2016-08-18T13:42:41Z

SLING-5975 - POST fails with modern multi-value parameter names containing 
brackets




> POST fails with modern multi-value parameter names containing brackets
> --
>
> Key: SLING-5975
> URL: https://issues.apache.org/jira/browse/SLING-5975
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.12
>Reporter: Roland Schaer
>
> A POST to update a multi-valued property fails with an error message if 
> modern parameter names with trailing brackets (i.e. {{myparam[]}}) are used.
> {code:title=cURL (resty)}
> POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
> "test@Delete="
> {code}
> {code:title=error.log}
> 18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
> /content/test HTTP/1.1] 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
> during response processing.
> javax.jcr.RepositoryException: Invalid name or path: test[]
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
>   at 
> org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
>   at 
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
>   at 
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
>   at 
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
> {code}



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

[GitHub] sling pull request #162: SLING-5975 - POST fails with modern multi-value par...

[roele]

GitHub user roele opened a pull request:

https://github.com/apache/sling/pull/162

SLING-5975 - POST fails with modern multi-value parameter names containing 
brackets



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/roele/sling SLING-5975

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/162.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #162


commit 363fd50b6a40e0e1b8de03b4770bfcbb724ec48b
Author: Roland Schaer 
Date:   2016-08-18T13:42:41Z

SLING-5975 - POST fails with modern multi-value parameter names containing 
brackets




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5965:


[~chetanm], I can go via JMX yes - however would be good to release 
commons.metrics 1.0.2 (see [mail on 
list|http://markmail.org/message/gm6bxavnxumhz4pj] as in 1.0.0 metrics are not 
exposed as JMX.

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5965.patch
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



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

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5965:


[~cziegeler], re
bq. I think we should move the HC to a separate bundle
I believe we don't consistently separate health-checks from their bundles, so 
probably have introduced a dependency to the HC bundle elsewhere. The exception 
to this seems to be 
[installer/hc|https://github.com/apache/sling/tree/trunk/installer/hc].
How would you see this separation, a _new_ bundle with 1 class?

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5965.patch
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



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

Re: svn commit: r1756736 - /sling/site/trunk/content/news.mdtext

[Andrei Dulvac]

Oops, sorry about that! And thanks for fixing it. I don’t know what went
wrong :(


- andrei

On Thu, Aug 18, 2016 at 2:56 PM Bertrand Delacretaz 
wrote:

> Hi,
>
> It looks like the many deletes in the below commit to our website
> content were not on purpose - I (think) I have fixed that in
> http://svn.apache.org/r1756769
>
> -Bertrand
>
> On Thu, Aug 18, 2016 at 10:06 AM,   wrote:
> > Author: dulvac
> > Date: Thu Aug 18 08:06:46 2016
> > New Revision: 1756736
> >
> > URL: http://svn.apache.org/viewvc?rev=1756736=rev
> > Log:
> > CMS commit to sling by dulvac
> >
> > Modified:
> > sling/site/trunk/content/news.mdtext
> >
> > Modified: sling/site/trunk/content/news.mdtext
> > URL:
> http://svn.apache.org/viewvc/sling/site/trunk/content/news.mdtext?rev=1756736=1756735=1756736=diff
> >
> ==
> > --- sling/site/trunk/content/news.mdtext (original)
> > +++ sling/site/trunk/content/news.mdtext Thu Aug 18 08:06:46 2016
> > @@ -1,167 +1,6 @@
> >  Title: News
> > -* New Releases: Apache Sling Testing PaxExam 0.0.2, Apache Sling JCR
> Oak Server 1.1.0 (August 17th, 2016)
> > -* New Release: Apache Sling Security 1.1.0 (August 15th, 2016)
> > -* New Releases: Apache Sling i18n 2.5.0 and Apache Sling i18n 2.4.10
> (August 8th, 2016)
> > -* New Releases: Apache Sling Engine 2.5.0, Apache Sling i18n 2.4.8, and
> Apache Sling Feature Flags 1.1.0 (August 5th, 2016)
> > -* New Release: Apache Sling Event Support 4.1.0 (August 1st, 2016)
> > -* New Releases: Apache Sling Resource Resolver 1.4.16, Apache Sling
> Launchpad Testing Services 2.0.10, Testing Services WAR 2.0.10, Apache
> Sling Integration Tests 1.0.2, Apache Sling API 2.14.0 (July 25th, 2016)
> > -* New Release: Apache Sling Commons Scheduler 2.5.0 (July 24th, 2016)
> > -* New Release: Apache Sling Resource Resolver 1.4.14 (July 21st, 2016)
> > -* New Releases: Apache Sling Discovery Base 1.1.4, Apache Sling
> Discovery Impl 1.2.8, Apache Sling Discovery Oak 1.2.8 (July 17th, 2016)
> > -* New Releases: Apache Sling Testing Sling Mock 1.7.0, Sling Mock
> 2.0.0, Sling Mock Oak 2.0.0 (July 15th, 2016)
> > -* New Releases: Apache Sling Commons Testing 2.0.26, Apache Sling
> Scripting Core 2.0.38, Apache Sling Servlets Resolver 2.4.4 (July 13th,
> 2016)
> > -* New Releases: Apache Sling Repoinit Parser 1.0.2, Repoinit JCR 1.0.0
> (July 11th, 2016)
> > -* New Release: Apache Sling API 2.12.0 (July 9th, 2016)
> > -* New Release: Apache Sling Scripting Thymeleaf 1.0.0 (July 4th, 2016)
> > -* New Release: Apache Sling Auth Core 1.3.16 (June 29th, 2016)
> > -* New Releases: Apache Sling Adapter Manager 2.1.8 (June 28th, 2016)
> > -* New Releases: Apache Sling Repository API Bundle 2.4.0, Apache Sling
> JCR Base Bundle 2.4.0 (June 27th, 2016)
> > -* New Release: Apache Sling Rewriter 1.1.4 (June 26th, 2016)
> > -* New Releases: Apache Sling JCR Resource 2.8.0 and Apache Sling
> Scripting JavaScript 2.0.30 (June 22nd, 2016)
> > -* New Releases: Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4,
> ResourceResolver Mock 1.1.14 (June 13th, 2016)
> > -* New Releases: Apache Sling Provisioning Model 1.4.4, and Slingstart
> Maven Plugin 1.4.4 (June 10th, 2016)
> > -* New Release: Apache Sling Servlets Post 2.3.12 (June 1st, 2016)
> > -* New Release: Apache Sling JSON Library 2.0.16 (May 27th, 2016)
> > -* New Release: Apache Sling Discovery API 1.0.4 (April 29th, 2016)
> > -* New Release: Apache Sling Log Tracer version 1.0.0, Apache Sling
> Resource Resolver 1.4.12 (April 25th, 2016)
> > -* New Release: Apache Sling Scripting JSP-Taglib version 2.2.6 (April
> 21st, 2016)
> > -* New Release: Apache Sling Auth Core 1.3.14 (April 12th, 2016)
> > -* New Release: Apache Sling Servlets Post (April 10th, 2016)
> > -* New Release: Apache Sling Resource Resolver (April 7th, 2016)
> > -* New Release: Apache Sling Event 4.0.2 (April 4th, 2016)
> > -* New Release: Apache Sling Discovery Commons 1.0.12 (March 29th, 2016)
> > -* New Release: Apache Sling Scripting Sightly Engine 1.0.18 (March
> 18th, 2016)
> > -* New Release: Apache Maven Sling Plugin 2.1.8 (March 16th, 2016)
> > -* New Release: [Apache Sling IDE Tooling for Eclipse
> 1.1.0]({{refs.sling-ide-tooling-11-released.path}}) (March 14th, 2016)
> > -* New Releases: Apache Sling Resource Resolver 1.4.8, Apache Sling JCR
> Resource 2.7.4, and Apache Sling Installer Core 3.6.8 (March 11th, 2016)
> > -* New Releases: Apache Sling Health Check Core 1.2.4, Apache Sling
> Health Checks Annotations 1.0.4, Apache Sling JCR Davex 1.3.2, and Apache
> Sling JCR Webdav 2.3.4 (March 8th, 2016)
> > -* New Release: Apache Sling Scripting Sightly Engine 1.0.16 (March 5th,
> 2016)
> > -* New Release: Apache Sling Tooling Support Source 1.0.0 (March 3rd,
> 2016)
> > -* New Releases: Apache Sling Background Servlets Engine 1.0.6, Apache
> Sling Background Servlets Integration Test 1.0.0 (March 2nd, 2016)
> > -* New Releases: 

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna commented on SLING-5973:


Actually I did try both the html escaped and native unicode in that example 
(see the last two chars):

" \ud83c\udf40"

The results are the same for both. I will update the example to only use native 
unicode though.


> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Comment Edited] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna edited comment on SLING-5973 at 8/18/16 1:02 PM:
-

Actually I did try both the html escaped and native unicode in that example 
(see the last two chars):

{code}" 
\ud83c\udf40"{code}

The results are the same for both. I will update the example to only use native 
unicode though.



was (Author: fortuna):
Actually I did try both the html escaped and native unicode in that example 
(see the last two chars):

" \ud83c\udf40"

The results are the same for both. I will update the example to only use native 
unicode though.


> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5973:
---

ok - as a next step please fix/remove the wrong escaping in your content as 
noted in [my 
comment|https://issues.apache.org/jira/browse/SLING-5973?focusedCommentId=15426098#comment-15426098]
 - i assume this will solve the problem.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna commented on SLING-5973:


Thanks for following up so quickly. I just added two images demonstrating what 
I am seeing when I enable/disable Sling rewriter bundle.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Updated] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna updated SLING-5973:
---
Attachment: emoji-with-sling-rewriter.png
emoji-no-sling-rewriter.png

Examples of rendering emoji with and without Sling rewriter bundle enabled.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
> Attachments: emoji-no-sling-rewriter.png, 
> emoji-with-sling-rewriter.png
>
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

Re: svn commit: r1756736 - /sling/site/trunk/content/news.mdtext

[Bertrand Delacretaz]

Hi,

It looks like the many deletes in the below commit to our website
content were not on purpose - I (think) I have fixed that in
http://svn.apache.org/r1756769

-Bertrand

On Thu, Aug 18, 2016 at 10:06 AM,   wrote:
> Author: dulvac
> Date: Thu Aug 18 08:06:46 2016
> New Revision: 1756736
>
> URL: http://svn.apache.org/viewvc?rev=1756736=rev
> Log:
> CMS commit to sling by dulvac
>
> Modified:
> sling/site/trunk/content/news.mdtext
>
> Modified: sling/site/trunk/content/news.mdtext
> URL: 
> http://svn.apache.org/viewvc/sling/site/trunk/content/news.mdtext?rev=1756736=1756735=1756736=diff
> ==
> --- sling/site/trunk/content/news.mdtext (original)
> +++ sling/site/trunk/content/news.mdtext Thu Aug 18 08:06:46 2016
> @@ -1,167 +1,6 @@
>  Title: News
> -* New Releases: Apache Sling Testing PaxExam 0.0.2, Apache Sling JCR Oak 
> Server 1.1.0 (August 17th, 2016)
> -* New Release: Apache Sling Security 1.1.0 (August 15th, 2016)
> -* New Releases: Apache Sling i18n 2.5.0 and Apache Sling i18n 2.4.10 (August 
> 8th, 2016)
> -* New Releases: Apache Sling Engine 2.5.0, Apache Sling i18n 2.4.8, and 
> Apache Sling Feature Flags 1.1.0 (August 5th, 2016)
> -* New Release: Apache Sling Event Support 4.1.0 (August 1st, 2016)
> -* New Releases: Apache Sling Resource Resolver 1.4.16, Apache Sling 
> Launchpad Testing Services 2.0.10, Testing Services WAR 2.0.10, Apache Sling 
> Integration Tests 1.0.2, Apache Sling API 2.14.0 (July 25th, 2016)
> -* New Release: Apache Sling Commons Scheduler 2.5.0 (July 24th, 2016)
> -* New Release: Apache Sling Resource Resolver 1.4.14 (July 21st, 2016)
> -* New Releases: Apache Sling Discovery Base 1.1.4, Apache Sling Discovery 
> Impl 1.2.8, Apache Sling Discovery Oak 1.2.8 (July 17th, 2016)
> -* New Releases: Apache Sling Testing Sling Mock 1.7.0, Sling Mock 2.0.0, 
> Sling Mock Oak 2.0.0 (July 15th, 2016)
> -* New Releases: Apache Sling Commons Testing 2.0.26, Apache Sling Scripting 
> Core 2.0.38, Apache Sling Servlets Resolver 2.4.4 (July 13th, 2016)
> -* New Releases: Apache Sling Repoinit Parser 1.0.2, Repoinit JCR 1.0.0 (July 
> 11th, 2016)
> -* New Release: Apache Sling API 2.12.0 (July 9th, 2016)
> -* New Release: Apache Sling Scripting Thymeleaf 1.0.0 (July 4th, 2016)
> -* New Release: Apache Sling Auth Core 1.3.16 (June 29th, 2016)
> -* New Releases: Apache Sling Adapter Manager 2.1.8 (June 28th, 2016)
> -* New Releases: Apache Sling Repository API Bundle 2.4.0, Apache Sling JCR 
> Base Bundle 2.4.0 (June 27th, 2016)
> -* New Release: Apache Sling Rewriter 1.1.4 (June 26th, 2016)
> -* New Releases: Apache Sling JCR Resource 2.8.0 and Apache Sling Scripting 
> JavaScript 2.0.30 (June 22nd, 2016)
> -* New Releases: Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4, 
> ResourceResolver Mock 1.1.14 (June 13th, 2016)
> -* New Releases: Apache Sling Provisioning Model 1.4.4, and Slingstart Maven 
> Plugin 1.4.4 (June 10th, 2016)
> -* New Release: Apache Sling Servlets Post 2.3.12 (June 1st, 2016)
> -* New Release: Apache Sling JSON Library 2.0.16 (May 27th, 2016)
> -* New Release: Apache Sling Discovery API 1.0.4 (April 29th, 2016)
> -* New Release: Apache Sling Log Tracer version 1.0.0, Apache Sling Resource 
> Resolver 1.4.12 (April 25th, 2016)
> -* New Release: Apache Sling Scripting JSP-Taglib version 2.2.6 (April 21st, 
> 2016)
> -* New Release: Apache Sling Auth Core 1.3.14 (April 12th, 2016)
> -* New Release: Apache Sling Servlets Post (April 10th, 2016)
> -* New Release: Apache Sling Resource Resolver (April 7th, 2016)
> -* New Release: Apache Sling Event 4.0.2 (April 4th, 2016)
> -* New Release: Apache Sling Discovery Commons 1.0.12 (March 29th, 2016)
> -* New Release: Apache Sling Scripting Sightly Engine 1.0.18 (March 18th, 
> 2016)
> -* New Release: Apache Maven Sling Plugin 2.1.8 (March 16th, 2016)
> -* New Release: [Apache Sling IDE Tooling for Eclipse 
> 1.1.0]({{refs.sling-ide-tooling-11-released.path}}) (March 14th, 2016)
> -* New Releases: Apache Sling Resource Resolver 1.4.8, Apache Sling JCR 
> Resource 2.7.4, and Apache Sling Installer Core 3.6.8 (March 11th, 2016)
> -* New Releases: Apache Sling Health Check Core 1.2.4, Apache Sling Health 
> Checks Annotations 1.0.4, Apache Sling JCR Davex 1.3.2, and Apache Sling JCR 
> Webdav 2.3.4 (March 8th, 2016)
> -* New Release: Apache Sling Scripting Sightly Engine 1.0.16 (March 5th, 2016)
> -* New Release: Apache Sling Tooling Support Source 1.0.0 (March 3rd, 2016)
> -* New Releases: Apache Sling Background Servlets Engine 1.0.6, Apache Sling 
> Background Servlets Integration Test 1.0.0 (March 2nd, 2016)
> -* New Releases: Apache Sling NoSQL Generic Resource Provider 1.1.0, 
> Couchbase Client 1.0.2, Couchbase Resource Provider 1.1.0, MongoDB Resource 
> Provider 1.1.0 (February 27th, 2016)
> -* New Release: Apache Sling Resource Resolver 1.4.4, Apache Sling Scripting 
> Sightly Engine 1.0.14 (February 26th, 

[ANN] Apache Sling Hypermedia API client-side tools 1.0.0 Released

[Andrei Dulvac]

The Apache Sling team is pleased to announce the release of Apache
Sling  Hypermedia API client-side tools version 1.0.0

Apache Sling is a web framework that uses a Java Content Repository,
such as Apache Jackrabbit, to store and manage content. Sling
applications use either scripts or Java servlets, selected based on
simple name conventions, to process HTTP requests in a RESTful way.
The Hypermedia API client-side tools 1.0.0 (HApi client) is a small
bundle with a java http client that can interact with HTML pages
instrumented with the HApi server-side tools.

This release is available from http://sling.apache.org/site/downloads.cgi

Building from verified sources is recommended, but convenience binaries are
also available via Maven:

org.apache.sling
org.apache.sling.hapi.client
1.0.0
Release Notes - Sling - Version HApi Client 1.0.0

** Improvement
* [SLING-5136] - [HApi] Add java HApi microdata client
* [SLING-5390] - [HApi] Allow HApi microdata client to fitler
links and forms based on a relation set as class
* [SLING-5880] - [hapi client] Make org.apache.sling.hapi.client
into a bundle


Enjoy!

-The Sling team

[jira] [Created] (SLING-5975) POST fails with modern multi-value parameter names containing brackets

[Roland Schaer (JIRA)]

Roland Schaer created SLING-5975:


 Summary: POST fails with modern multi-value parameter names 
containing brackets
 Key: SLING-5975
 URL: https://issues.apache.org/jira/browse/SLING-5975
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Post 2.3.12
Reporter: Roland Schaer


A POST to update a multi-valued property fails with an error message if modern 
parameter names with trailing brackets (i.e. {{myparam[]}}) are used.

{code:title=cURL (resty)}
POST /content/test -F "test[]=a" -F "test[]=b" -F "test@TypeHint=String[]" -F 
"test@Delete="
{code}

{code:title=error.log}
18.08.2016 14:29:04.282 *ERROR* [0:0:0:0:0:0:0:1 [1471523344280] POST 
/content/test HTTP/1.1] 
org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception during 
response processing.
javax.jcr.RepositoryException: Invalid name or path: test[]
at 
org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:359)
at 
org.apache.jackrabbit.oak.jcr.session.ItemImpl.getOakPathOrThrow(ItemImpl.java:323)
at 
org.apache.jackrabbit.oak.jcr.session.NodeImpl.hasProperty(NodeImpl.java:844)
at 
org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.getType(SlingPropertyValueHandler.java:398)
at 
org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(SlingPropertyValueHandler.java:284)
at 
org.apache.sling.servlets.post.impl.helper.SlingPropertyValueHandler.setProperty(SlingPropertyValueHandler.java:158)
at 
org.apache.sling.servlets.post.impl.operations.ModifyOperation.writeContent(ModifyOperation.java:411)
at 
org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:101)
at 
org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
at 
org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:202)
{code}



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

[jira] [Commented] (SLING-5969) Support multiple model/raw sources in jcr.repoinit.RepositoryInitializer configuration

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5969:


Docs are now up to date at 
https://sling.apache.org/documentation/bundles/repository-initialization.html , 
rewrote the _Providing repoinit statements from the Sling provisioning model or 
other URLs_ section there.

> Support multiple model/raw sources in jcr.repoinit.RepositoryInitializer 
> configuration
> --
>
> Key: SLING-5969
> URL: https://issues.apache.org/jira/browse/SLING-5969
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.0.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit JCR 1.0.2
>
>
> As suggested by [~olli] it is convenient to use multiple URI-like references 
> to define where the {{RepositoryInitializer}} gets its repoinit statements, 
> something like
> {code}
> model@section:context:/resources/provisioning/model.txt
> raw:classpath://com.example.sling.repoinit/repoinit.txt
> {code}
> Dropping the existing configuration parameters is not backwards compatible 
> with V1.0.0 of this module, but that looks reasonable as the new format is 
> much more convenient and we've had little feedback about usage of this module 
> so far. I'll add warnings in case the old parameters are still used.



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

[jira] [Resolved] (SLING-5974) Allow to configure/document misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5974.

   Resolution: Fixed
Fix Version/s: Commons Scheduler 2.5.2

> Allow to configure/document misfire behaviour of Sling Scheduler
> 
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

[jira] [Updated] (SLING-5974) Allow to configure/document misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5974:
---
Summary: Allow to configure/document misfire behaviour of Sling Scheduler  
(was: Allow to configure misfire behaviour of Sling Scheduler)

> Allow to configure/document misfire behaviour of Sling Scheduler
> 
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

[jira] [Commented] (SLING-5974) Allow to configure misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5974:


Since coming up with a configurable misfire behaviour binds the API really 
tightly to Quartz and would require quite some extensions to the API (because 
not all options are available for all triggers). Also with the default misfire 
behaviour explicitly documented I don't really feel the need of adjusting it 
for a certain use case. Therefore just adjusting the javadoc is good enough for 
the moment.

> Allow to configure misfire behaviour of Sling Scheduler
> ---
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

[jira] [Resolved] (SLING-5792) API to manage Authentication Requirement

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5792.
-
Resolution: Fixed

> API to manage Authentication Requirement
> 
>
> Key: SLING-5792
> URL: https://issues.apache.org/jira/browse/SLING-5792
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.18
>
>
> Apart from the constant {{AuthConstants.AUTH_REQUIREMENTS}} there is no 
> public API available that allowed applications to change the list of 
> authentication requirement entries.
> Instead, applications need to know and rely on implementation details, which 
> not only includes registering services with the  
> {{AuthConstants.AUTH_REQUIREMENTS}} property included but also know about the 
> required format of the property, which from my point of view should be and 
> remain an implementation detail of 
> {{org.apache.sling.auth.core.impl.SlingAuthenticator}}, which IMO should not 
> be considered public API.
> To me it would feel more natural if there existed a 
> {{AuthenticationRequirement}} interface defining methods to 
> extend/update/clear the auth-requirements bound to a particular service 
> reference and having {{org.apache.sling.auth.core.impl.SlingAuthenticator}} 
> implementing that interface.
> Doing so, might also be beneficial from a performance/scalability POV but I 
> would like to cover that in a separate sub-task.
> Proposal for this sub-tasks will follow as I am moving forward.



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

[jira] [Resolved] (SLING-5795) Allow for adding/removing individual AuthenticationRequirementHolder entries

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5795.
-
Resolution: Fixed

> Allow for adding/removing individual AuthenticationRequirementHolder entries
> 
>
> Key: SLING-5795
> URL: https://issues.apache.org/jira/browse/SLING-5795
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.18
>
>
> Today the {{SlingAuthenticator}} comes with a 
> {{SlingAuthenticatorServiceListener}}, that listens for all services that are 
> registered with an {{AuthConstants.AUTH_REQUIREMENTS}} property. This allows 
> for arbitrary services to extend the list of authentication requirements 
> originally intended to be configured with the {{SlingAuthenticatior}}.
> The implementation consequently requires those services to provide their full 
> list of auth-requirements: this not only forces the services to recompute 
> that information but also forces the {{SlingAuthenticatorServiceListener}} to 
> process the whole information upon every single change (see 
> {{SlingAuthenticatorServiceListener.addService}} and 
> {{SlingAuthenticatorServiceListener.removeService}}, which also includes an 
> update of the {{PathBasedHolderCache}}.
> At a Adobe we make use of this ability in a service that may contain several 
> thousand requirement entries which in addition are prone to frequent changes, 
> which IMO is not super-optimal with the implementation at hand.
> This assessment is not yet backed with decent performance testing, but based 
> on what I found while trying to rewrite that particular service to address 
> known issues.
> To summarize: What I have been looking for was the ability to inform the 
> listener about a single entry that would need to be added or removed from the 
> list of auth-requirements collected (and registered) by my service, without 
> having to compute (or cache) the complete list and without having all items 
> associated with my service being processed over and over again.
> Maybe envisioning SLING-5792 would offer the opportunity to also reconsider 
> this wish.



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

[jira] [Assigned] (SLING-5795) Allow for adding/removing individual AuthenticationRequirementHolder entries

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-5795:
---

Assignee: Carsten Ziegeler

> Allow for adding/removing individual AuthenticationRequirementHolder entries
> 
>
> Key: SLING-5795
> URL: https://issues.apache.org/jira/browse/SLING-5795
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.18
>
>
> Today the {{SlingAuthenticator}} comes with a 
> {{SlingAuthenticatorServiceListener}}, that listens for all services that are 
> registered with an {{AuthConstants.AUTH_REQUIREMENTS}} property. This allows 
> for arbitrary services to extend the list of authentication requirements 
> originally intended to be configured with the {{SlingAuthenticatior}}.
> The implementation consequently requires those services to provide their full 
> list of auth-requirements: this not only forces the services to recompute 
> that information but also forces the {{SlingAuthenticatorServiceListener}} to 
> process the whole information upon every single change (see 
> {{SlingAuthenticatorServiceListener.addService}} and 
> {{SlingAuthenticatorServiceListener.removeService}}, which also includes an 
> update of the {{PathBasedHolderCache}}.
> At a Adobe we make use of this ability in a service that may contain several 
> thousand requirement entries which in addition are prone to frequent changes, 
> which IMO is not super-optimal with the implementation at hand.
> This assessment is not yet backed with decent performance testing, but based 
> on what I found while trying to rewrite that particular service to address 
> known issues.
> To summarize: What I have been looking for was the ability to inform the 
> listener about a single entry that would need to be added or removed from the 
> list of auth-requirements collected (and registered) by my service, without 
> having to compute (or cache) the complete list and without having all items 
> associated with my service being processed over and over again.
> Maybe envisioning SLING-5792 would offer the opportunity to also reconsider 
> this wish.



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

[jira] [Updated] (SLING-5795) Allow for adding/removing individual AuthenticationRequirementHolder entries

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5795:

Fix Version/s: Auth Core 1.3.18

> Allow for adding/removing individual AuthenticationRequirementHolder entries
> 
>
> Key: SLING-5795
> URL: https://issues.apache.org/jira/browse/SLING-5795
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.18
>
>
> Today the {{SlingAuthenticator}} comes with a 
> {{SlingAuthenticatorServiceListener}}, that listens for all services that are 
> registered with an {{AuthConstants.AUTH_REQUIREMENTS}} property. This allows 
> for arbitrary services to extend the list of authentication requirements 
> originally intended to be configured with the {{SlingAuthenticatior}}.
> The implementation consequently requires those services to provide their full 
> list of auth-requirements: this not only forces the services to recompute 
> that information but also forces the {{SlingAuthenticatorServiceListener}} to 
> process the whole information upon every single change (see 
> {{SlingAuthenticatorServiceListener.addService}} and 
> {{SlingAuthenticatorServiceListener.removeService}}, which also includes an 
> update of the {{PathBasedHolderCache}}.
> At a Adobe we make use of this ability in a service that may contain several 
> thousand requirement entries which in addition are prone to frequent changes, 
> which IMO is not super-optimal with the implementation at hand.
> This assessment is not yet backed with decent performance testing, but based 
> on what I found while trying to rewrite that particular service to address 
> known issues.
> To summarize: What I have been looking for was the ability to inform the 
> listener about a single entry that would need to be added or removed from the 
> list of auth-requirements collected (and registered) by my service, without 
> having to compute (or cache) the complete list and without having all items 
> associated with my service being processed over and over again.
> Maybe envisioning SLING-5792 would offer the opportunity to also reconsider 
> this wish.



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

[jira] [Updated] (SLING-5792) API to manage Authentication Requirement

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5792:

Fix Version/s: Auth Core 1.3.18

> API to manage Authentication Requirement
> 
>
> Key: SLING-5792
> URL: https://issues.apache.org/jira/browse/SLING-5792
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.18
>
>
> Apart from the constant {{AuthConstants.AUTH_REQUIREMENTS}} there is no 
> public API available that allowed applications to change the list of 
> authentication requirement entries.
> Instead, applications need to know and rely on implementation details, which 
> not only includes registering services with the  
> {{AuthConstants.AUTH_REQUIREMENTS}} property included but also know about the 
> required format of the property, which from my point of view should be and 
> remain an implementation detail of 
> {{org.apache.sling.auth.core.impl.SlingAuthenticator}}, which IMO should not 
> be considered public API.
> To me it would feel more natural if there existed a 
> {{AuthenticationRequirement}} interface defining methods to 
> extend/update/clear the auth-requirements bound to a particular service 
> reference and having {{org.apache.sling.auth.core.impl.SlingAuthenticator}} 
> implementing that interface.
> Doing so, might also be beneficial from a performance/scalability POV but I 
> would like to cover that in a separate sub-task.
> Proposal for this sub-tasks will follow as I am moving forward.



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

[jira] [Commented] (SLING-5974) Allow to configure misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5974:


Applied the javadoc fix in [r1756757|https://svn.apache.org/r1756757].

> Allow to configure misfire behaviour of Sling Scheduler
> ---
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

[jira] [Commented] (SLING-5974) Allow to configure misfire behaviour of Sling Scheduler

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5974:
-

lgtm, thanks

> Allow to configure misfire behaviour of Sling Scheduler
> ---
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

[jira] [Updated] (SLING-5974) Allow to configure misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5974:
---
Attachment: SLING-5974-javadoc-v1.patch

Attached is a patch which just extends the javadoc by stating the default 
misfire behaviour.

[~cziegeler] Can you have a look?

> Allow to configure misfire behaviour of Sling Scheduler
> ---
>
> Key: SLING-5974
> URL: https://issues.apache.org/jira/browse/SLING-5974
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Konrad Windszus
> Attachments: SLING-5974-javadoc-v1.patch
>
>
> Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
> Unfortunately the API exposed through Sling does not allow to configure the 
> so misfire behaviour (compare with 
> http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
>  and https://dzone.com/articles/quartz-scheduler-misfire).
> Especially since the default misfire behaviour (called smart policy) differs 
> by trigger type the default should be documented and it should be possible to 
> overwrite the default.



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

Re: [Context Aware Configs] Merging?

[Bertrand Delacretaz]

On Thu, Aug 18, 2016 at 11:52 AM, Stefan Seifert  wrote:
> ...perhaps we find a way to support both ways with the pluggable architecture 
> i've in mind and
> that in good parts is already in use in wcm.io - activate the property-level 
> merging osgi service or
> bundle if you want you want to use it, or leave it out if not

Having a service to control merging things sounds like the safest thing to do.

We might provide a basic implementation along with an extension point
for fancier logic.

And the logging that helps troubleshooting who merged what.

-Bertrand

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5973:
-



> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5965:


Going via JMX requires SLING-5424 - ie commons.metrics 1.0.2 to be released

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5965.patch
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



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

RE: [Context Aware Configs] Merging?

[Stefan Seifert]

>So far, no one needed it, as the implementation which is used today does
>not support it.

well, depends which implementation is referenced - in the wcm.io Config 
property-level merging for parameter inheritance is supported.

i agree with the arguments from justin and georg, and see more usecases where 
property-level merging is helpful than where it is harmful. keep in mind that 
content-aware configuration is often outside the scope of the devops-controlled 
automated configuration.

in our usecases (worldwide-distributed marketing websites) we often have a big 
number of "business parameters" that control features on the websites which are 
switched on and off be editors using a graphical configuration editor within 
their CMS GUI. the devops team only maintains a sensible set of global/default 
confgurations which can be overridden by each of the hundreds of websites. 
without property merging a new parameter in a global/default configuration 
would mean to adjust hundreds of inherited configuration objects as well.

in wcm.io config we also added support to "lock" a single configuration 
property on a certain context level, e.g. this allows to define a global or 
region-wide parameter and disallows the editors in the website to override it. 
useful e.g. to switch off a feature centrally which is currently malfunctioning 
until the application is fixed, and then the lock is removed again preserving 
the previous configuration state in each site.

if we support object merging we already open "pandora's box" - if it is feared 
that property-level inheritance can do harm, the same can apply to object-level 
inheritance as well.

we also have a third special case in inheritance: object/resource collection 
inheritance (object/resource collections are comparable to osgi factory 
configurations). we need to decide what happens when globally there are objects 
A and B in the config collection, and local there is C. is the result A+B+C or 
only C? some of the existing configuration solutions already support special 
properties to decide what is happening, because there are usecases for both 
results. the resource merger also has concepts for this. this usecase is 
currently missing in ians specification draft 
https://gist.github.com/ieb/460504e79c861cb980f4f0154210a869

in my pov it is not always correct the have the analogy of osgi configuration 
vs. context-aware configuration when deciding if thinks like property merging 
are useful or not - osgi configuration is per definition always global, never 
tenant-specific, never depending on context e.g. content tree, never 
hierarchical. this makes the usecases for inheritance and property merging more 
complex for context-aware configuration than for osgi configurations.

perhaps we find a way to support both ways with the pluggable architecture i've 
in mind and that in good parts is already in use in wcm.io - activate the 
property-level merging osgi service or bundle if you want you want to use it, 
or leave it out if not.

stefan

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5973:


Thanks [~olli] - I have converted the (cute ;-) emoji to unicode escapes in 
http://svn.apache.org/r1756751 - I think it's safer to avoid non-ASCII chars in 
our source code.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Konrad Windszus]

I created https://issues.apache.org/jira/browse/SLING-5974 for making it 
possible to configure the misfire behaviour through the Sling Scheduler API.

> On 18 Aug 2016, at 11:12, Konrad Windszus  wrote:
> 
> The default behaviour of Quartz seems to be a different one:
> https://dzone.com/articles/quartz-scheduler-misfire 
> 
> 
> MISFIRE_INSTRUCTION_FIRE_ONCE_NOW, which means a misfired execution (e.g. a 
> missed cron time) leads to the immediate execution of that job once the 
> Scheduler is running again.
> Maybe that should be clarified in the Javadoc of the Scheduler itself.
> 
> Konrad
> 
> 
>> On 18 Aug 2016, at 10:59, Konrad Windszus  wrote:
>> 
>> This is not what I experience (I only tried with AEM 6.1 SP2 where 
>> maintenance tasks are executed with a scheduler). The jobs are executed 
>> immediately after the computer is waking up even if that is hours after the 
>> scheduled time.
>> 
>>> On 18 Aug 2016, at 10:55, Carsten Ziegeler  wrote:
>>> 
 How does the Sling Scheduler behave in case two jobs are scheduled with a 
 cron expression (one at 1am, one at 2am on a daily basis) and Sling is 
 either not running or the computer is in sleep mode at that time?
 Will both be executed immediately when the Sling Scheduler is active 
 again? 
 What about the order of both Jobs? Is the one with the earlier cron 
 expression always being executed first?
>>> 
>>> We're using the quartz library for this, and if Sling is not running at
>>> those times, then these jobs will be scheduled for the next day. It's
>>> like adding a cron job to your computer. If your computer is off at the
>>> scheduled time, the job does not run
>>> 
>>> Carsten
>>> 
>>> 
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>>> 
>> 
> 

[jira] [Created] (SLING-5974) Allow to configure misfire behaviour of Sling Scheduler

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5974:
--

 Summary: Allow to configure misfire behaviour of Sling Scheduler
 Key: SLING-5974
 URL: https://issues.apache.org/jira/browse/SLING-5974
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Scheduler 2.5.0
Reporter: Konrad Windszus


Scheduler is internally relying on Quartz (http://www.quartz-scheduler.org/). 
Unfortunately the API exposed through Sling does not allow to configure the so 
misfire behaviour (compare with 
http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/tutorial-lesson-04.html
 and https://dzone.com/articles/quartz-scheduler-misfire).
Especially since the default misfire behaviour (called smart policy) differs by 
trigger type the default should be documented and it should be possible to 
overwrite the default.



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

Re: Questions about o.a.s.commons.metrics and SLING-5965

[Stefan Egli]

Hi,

On 16/08/16 13:51, "Stefan Egli"  wrote:

>>2) Does the metrics library by default make all values available via
>>JMX as well?
>
>That I don't know, couldn't find it at least.

FYI: due to SLING-5424 (jmxReporter not started) this indeed doesn't work
in commons.metrics-1.0.0 yet, only in 1.0.2 (not yet released). Albeit
with an empty (JMX) 'Type' - which seems to be due to [1] not using a
custom ObjectNameFactory as [0] does. So perhaps we should also use such a
factory for commons metrics?

Cheers,
Stefan
--
[0] 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/
org/apache/jackrabbit/oak/plugins/metric/MetricStatisticsProvider.java#L77
[1] 
https://github.com/apache/sling/blob/trunk/bundles/commons/metrics/src/main
/java/org/apache/sling/commons/metrics/internal/MetricsServiceImpl.java#L21
5

[jira] [Updated] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-5973:

Component/s: Extensions

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5973:
-

I've added a test in [r1756747|https://svn.apache.org/r1756747]. Feel free to 
adjust.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Konrad Windszus]

Hmm, I tend to disagree here. I dug deep into the code and 
com.adobe.granite.maintenance.impl.TaskSchedulerImpl is internally relying on 
org.apache.sling.commons.scheduler.Scheduler.
Konrad


> On 18 Aug 2016, at 11:11, Carsten Ziegeler  wrote:
> 
>> This is not what I experience (I only tried with AEM 6.1 SP2 where 
>> maintenance tasks are executed with a scheduler). The jobs are executed 
>> immediately after the computer is waking up even if that is hours after the 
>> scheduled time.
>> 
> Maintenance tasks is an AEM feature which is not using the scheduler
> 
> Carsten
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Konrad Windszus]

The default behaviour of Quartz seems to be a different one:
https://dzone.com/articles/quartz-scheduler-misfire 


MISFIRE_INSTRUCTION_FIRE_ONCE_NOW, which means a misfired execution (e.g. a 
missed cron time) leads to the immediate execution of that job once the 
Scheduler is running again.
Maybe that should be clarified in the Javadoc of the Scheduler itself.

Konrad


> On 18 Aug 2016, at 10:59, Konrad Windszus  wrote:
> 
> This is not what I experience (I only tried with AEM 6.1 SP2 where 
> maintenance tasks are executed with a scheduler). The jobs are executed 
> immediately after the computer is waking up even if that is hours after the 
> scheduled time.
> 
>> On 18 Aug 2016, at 10:55, Carsten Ziegeler  wrote:
>> 
>>> How does the Sling Scheduler behave in case two jobs are scheduled with a 
>>> cron expression (one at 1am, one at 2am on a daily basis) and Sling is 
>>> either not running or the computer is in sleep mode at that time?
>>> Will both be executed immediately when the Sling Scheduler is active again? 
>>> What about the order of both Jobs? Is the one with the earlier cron 
>>> expression always being executed first?
>> 
>> We're using the quartz library for this, and if Sling is not running at
>> those times, then these jobs will be scheduled for the next day. It's
>> like adding a cron job to your computer. If your computer is off at the
>> scheduled time, the job does not run
>> 
>> Carsten
>> 
>> 
>> 
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 
> 

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Carsten Ziegeler]

> This is not what I experience (I only tried with AEM 6.1 SP2 where 
> maintenance tasks are executed with a scheduler). The jobs are executed 
> immediately after the computer is waking up even if that is hours after the 
> scheduled time.
> 
Maintenance tasks is an AEM feature which is not using the scheduler

Carsten


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Konrad Windszus]

This is not what I experience (I only tried with AEM 6.1 SP2 where maintenance 
tasks are executed with a scheduler). The jobs are executed immediately after 
the computer is waking up even if that is hours after the scheduled time.

> On 18 Aug 2016, at 10:55, Carsten Ziegeler  wrote:
> 
>> How does the Sling Scheduler behave in case two jobs are scheduled with a 
>> cron expression (one at 1am, one at 2am on a daily basis) and Sling is 
>> either not running or the computer is in sleep mode at that time?
>> Will both be executed immediately when the Sling Scheduler is active again? 
>> What about the order of both Jobs? Is the one with the earlier cron 
>> expression always being executed first?
> 
> We're using the quartz library for this, and if Sling is not running at
> those times, then these jobs will be scheduled for the next day. It's
> like adding a cron job to your computer. If your computer is off at the
> scheduled time, the job does not run
> 
> Carsten
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 

Re: Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Carsten Ziegeler]

> How does the Sling Scheduler behave in case two jobs are scheduled with a 
> cron expression (one at 1am, one at 2am on a daily basis) and Sling is either 
> not running or the computer is in sleep mode at that time?
> Will both be executed immediately when the Sling Scheduler is active again? 
> What about the order of both Jobs? Is the one with the earlier cron 
> expression always being executed first?

We're using the quartz library for this, and if Sling is not running at
those times, then these jobs will be scheduled for the next day. It's
like adding a cron job to your computer. If your computer is off at the
scheduled time, the job does not run

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Scheduler behaviour in case it is not running at the time where a job was supposed to be executed

[Konrad Windszus]

How does the Sling Scheduler behave in case two jobs are scheduled with a cron 
expression (one at 1am, one at 2am on a daily basis) and Sling is either not 
running or the computer is in sleep mode at that time?
Will both be executed immediately when the Sling Scheduler is active again? 
What about the order of both Jobs? Is the one with the earlier cron expression 
always being executed first?
Thanks for clarification.
Konrad

[jira] [Comment Edited] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Stefan Seifert (JIRA)]

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

Stefan Seifert edited comment on SLING-5973 at 8/18/16 8:32 AM:


i tried out your application in sling launchpad and opened the URL 
http://localhost:8080/emojistrip/ - what should i see if it is correct or not?

looking at http://localhost:8080/emojistrip/phrases/list/good-luck.json or 
https://github.com/Whistlepost/emojistrip/blob/master/emojistrip-content/src/main/resources/SLING-INF/content/phrases.json
 it think the problem is the escaping you use in the JCR content.

escaping in form {{&\#x2602;}} is HTML specific and not compatible with the 
JSON spec. you should store the UTF-8 data natively in JSON/JCR and let the 
HTML serializer take care of escaping the only when rendering the page. so you 
can either put the UTF-8 character directly into the JSON file, or escape them 
as definied in "2.5.  Strings" in [RFC4627|http://www.ietf.org/rfc/rfc4627.txt 
e.g. {{\u005C}}. when storing date using JCR API or Sling API you should not do 
any escaping manually, just store the UTF-8 string.


was (Author: sseif...@pro-vision.de):
i tried out your application in sling launchpad and opened the URL 
http://localhost:8080/emojistrip/ - what should i see if it is correct or not?

looking at http://localhost:8080/emojistrip/phrases/list/good-luck.json or 
https://github.com/Whistlepost/emojistrip/blob/master/emojistrip-content/src/main/resources/SLING-INF/content/phrases.json
 it think the problem is the escaping you use in the JCR content.

escaping in form {{}} is HTML specific and not compatible with the JSON 
spec. you should store the UTF-8 data natively in JSON/JCR and let the HTML 
serializer take care of escaping the only when rendering the page. so you can 
either put the UTF-8 character directly into the JSON file, or escape them as 
definied in "2.5.  Strings" in [RFC4627|http://www.ietf.org/rfc/rfc4627.txt 
e.g. {{\u005C}}. when storing date using JCR API or Sling API you should not do 
any escaping manually, just store the UTF-8 string.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5973:
---

i tried out your application in sling launchpad and opened the URL 
http://localhost:8080/emojistrip/ - what should i see if it is correct or not?

looking at http://localhost:8080/emojistrip/phrases/list/good-luck.json or 
https://github.com/Whistlepost/emojistrip/blob/master/emojistrip-content/src/main/resources/SLING-INF/content/phrases.json
 it think the problem is the escaping you use in the JCR content.

escaping in form {{}} is HTML specific and not compatible with the JSON 
spec. you should store the UTF-8 data natively in JSON/JCR and let the HTML 
serializer take care of escaping the only when rendering the page. so you can 
either put the UTF-8 character directly into the JSON file, or escape them as 
definied in "2.5.  Strings" in [RFC4627|http://www.ietf.org/rfc/rfc4627.txt 
e.g. {{\u005C}}. when storing date using JCR API or Sling API you should not do 
any escaping manually, just store the UTF-8 string.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

As discussed with [~cziegeler] the patch will be improved by 
- moving the API to auth.core
- adjust {{SlingAuthenticator}} to make use of the optional 
{{LoginPathProvider}}

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



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

Re: [VOTE] Release Sling Hypermedia API client-side tools 1.0.0 - take TWO

[Andrei Dulvac]

Thanks Stefan!

I did all the necessary steps now :)

- Andrei


On Wed, Aug 17, 2016 at 6:34 PM Stefan Seifert 
wrote:

> hello andrei.
>
> i can help. please execute all steps from [1] yourself:
> - "Wait for the Results" (official [RESULT] [VOTE] mail)
> - "Promoting the Release"
> - "Update JIRA"
>
> the only step you cannot do yourself is "Push the release to
> https://dist.apache.org/repos/dist/release/sling/; - i've completed this
> step just now (rev. 14852)
>
> stefan
>
> [1]
> http://sling.apache.org/documentation/development/release-management.html
>
>
> >-Original Message-
> >From: Andrei Dulvac [mailto:andrei.dul...@gmail.com]
> >Sent: Wednesday, August 17, 2016 8:59 AM
> >To: dev@sling.apache.org
> >Subject: Re: [VOTE] Release Sling Hypermedia API client-side tools 1.0.0 -
> >take TWO
> >
> >Thanks Everyone.
> >We have 5 +1's. Could someone in the PMC finalize the release?
> >
> >- Andrei
> >
> >
> >On Tue, Aug 16, 2016 at 11:50 PM Karl Pauls  wrote:
> >
> >> +1
> >>
> >> regards,
> >>
> >> Karl
> >>
> >> On Fri, Aug 12, 2016 at 11:02 AM, Andrei Dulvac 
> >wrote:
> >>
> >> > Hi,
> >> >
> >> > We solved 3 issues for this initial
> >> > release:
> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
> >> > Staging repository:
> >> >
> >> >
> https://repository.apache.org/content/repositories/orgapachesling-1499/
> >> >
> >> > You can use this UNIX script to download the release and verify the
> >> > signatures:http://svn.apache.org/repos/asf/sling/trunk/
> >> > check_staged_release.sh
> >> > Usage:
> >> >
> >> > sh check_staged_release.sh 1499 /tmp/sling-staging
> >> >
> >> > Please vote to approve this release:
> >> >
> >> >   [ ] +1 Approve the release
> >> >   [ ]  0 Don't care
> >> >   [ ] -1 Don't release, because ...
> >> > This majority vote is open for at least 72 hours.
> >> >
> >> > Thanks,
> >> > - Andrei
> >> >
> >>
> >>
> >>
> >> --
> >> Karl Pauls
> >> karlpa...@gmail.com
> >>
>

[jira] [Reopened] (SLING-5906) Allow to filter resource by properties

[Timothee Maret (JIRA)]

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

Timothee Maret reopened SLING-5906:
---

Reverted the path in r1756735, need to depend on released 
jackrabbit-filevault-3.1.28.

> Allow to filter resource by properties
> --
>
> Key: SLING-5906
> URL: https://issues.apache.org/jira/browse/SLING-5906
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5906.patch
>
>
> In some scenarios, it is useful to allow filtering out some properties when 
> importing content. Those properties may be used to filter out ACLs (e.g. 
> {{jcr:primaryType=rep:ACL}} or more generally properties that are instance 
> specific.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna commented on SLING-5973:


In order to create a unit test I'll probably need to do some more investigation 
to narrow down where the issue is - I suspect it might be in Cocoon so I'll let 
you know if I find anything.

Another interesting aspect of this is that it appears to be outputting the 
"surrogate pair" of the unicode character, which is apparently used to 
represent UTF-16 characters (which incidentally is the Java internal 
representation charset). e.g:

http://apps.timwhitlock.info/unicode/inspect/hex/1F601

Also, lower order unicode characters are output correctly: eg: 
{code}{code}



> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Updated] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna updated SLING-5973:
---
Description: 
I've noticed that when I have unicode special characters (e.g. emoji) in my 
sling content and the sling rewriter is enabled the characters are not output 
correctly to the browser. For example:

{code}{code} becomes {code}{code}

If I disable the rewriter pipeline the output is as expected.

I've looked in the code and I suspect the issue is in the HTMLSerializer from 
the Cocoon library, however I'm not sure why as it should be using the default 
encoding for output (which is UTF-8). My rewriter pipeline is using the default 
html-generator and html-serializer provided by sling.

My code is available on GitHub here:

https://github.com/Whistlepost/emojistrip

It provides a very simple app/content project pair with some emoji characters 
in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
thanks.


  was:
I've noticed that when I have unicode special characters (e.g. emoji) in my 
sling content and the sling rewriter is enabled the characters are not output 
correctly to the browser. For example:

{code}{code} becomes {code}{code}

If I disable the rewriter pipeline the output is as expected.

I've looked in the code and I suspect the issue is in the HTMLSerializer from 
the Cocoon library, however I'm not sure why as it should be using the default 
encoding for output (which is UTF-8). My rewriter pipeline is using the default 
html-generator and html-serializer provided by sling.

My code is available on GitHub here:

https://github.com/Whistlepost/emojistrip

It provides a very simple app/content project pair with some emoji characters 
in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
thanks.



> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Comment Edited] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-5973 at 8/18/16 7:26 AM:
-

Would you be able to narrow the problem down by (ideally) creating a JUnit test 
that demonstrates it? 
Or supply a minimal failure scenario that does not require running your 
complete app.


was (Author: bdelacretaz):
Would you be able to narrow the problem down by (ideally) creating a JUnit test 
that demonstrate it? 
Or supply a minimal failure scenario that does not require running your 
complete app.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Commented] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5973:


Would you be able to narrow the problem down by (ideally) creating a JUnit test 
that demonstrate it? 
Or supply a minimal failure scenario that does not require running your 
complete app.

> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Updated] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

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

Ben Fortuna updated SLING-5973:
---
Description: 
I've noticed that when I have unicode special characters (e.g. emoji) in my 
sling content and the sling rewriter is enabled the characters are not output 
correctly to the browser. For example:

{code}{code} becomes {code}{code}

If I disable the rewriter pipeline the output is as expected.

I've looked in the code and I suspect the issue is in the HTMLSerializer from 
the Cocoon library, however I'm not sure why as it should be using the default 
encoding for output (which is UTF-8). My rewriter pipeline is using the default 
html-generator and html-serializer provided by sling.

My code is available on GitHub here:

https://github.com/Whistlepost/emojistrip

It provides a very simple app/content project pair with some emoji characters 
in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
thanks.


  was:
I've noticed that when I have unicode special characters (e.g. emoji) in my 
sling content and the sling rewriter is enabled the characters are not output 
correctly to the browser. For example:

 becomes 

If I disable the rewriter pipeline the output is as expected.

I've looked in the code and I suspect the issue is in the HTMLSerializer from 
the Cocoon library, however I'm not sure why as it should be using the default 
encoding for output (which is UTF-8). My rewriter pipeline is using the default 
html-generator and html-serializer provided by sling.

My code is available on GitHub here:

https://github.com/Whistlepost/emojistrip

It provides a very simple app/content project pair with some emoji characters 
in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
thanks.



> HTMLSerializer not handling some unicode characters (emoji, etc.)
> -
>
> Key: SLING-5973
> URL: https://issues.apache.org/jira/browse/SLING-5973
> Project: Sling
>  Issue Type: Bug
>Reporter: Ben Fortuna
>
> I've noticed that when I have unicode special characters (e.g. emoji) in my 
> sling content and the sling rewriter is enabled the characters are not output 
> correctly to the browser. For example:
> {code}{code} becomes {code}{code}
> If I disable the rewriter pipeline the output is as expected.
> I've looked in the code and I suspect the issue is in the HTMLSerializer from 
> the Cocoon library, however I'm not sure why as it should be using the 
> default encoding for output (which is UTF-8). My rewriter pipeline is using 
> the default html-generator and html-serializer provided by sling.
> My code is available on GitHub here:
> https://github.com/Whistlepost/emojistrip
> It provides a very simple app/content project pair with some emoji characters 
> in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
> thanks.



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

[jira] [Created] (SLING-5973) HTMLSerializer not handling some unicode characters (emoji, etc.)

[Ben Fortuna (JIRA)]

Ben Fortuna created SLING-5973:
--

 Summary: HTMLSerializer not handling some unicode characters 
(emoji, etc.)
 Key: SLING-5973
 URL: https://issues.apache.org/jira/browse/SLING-5973
 Project: Sling
  Issue Type: Bug
Reporter: Ben Fortuna


I've noticed that when I have unicode special characters (e.g. emoji) in my 
sling content and the sling rewriter is enabled the characters are not output 
correctly to the browser. For example:

 becomes 

If I disable the rewriter pipeline the output is as expected.

I've looked in the code and I suspect the issue is in the HTMLSerializer from 
the Cocoon library, however I'm not sure why as it should be using the default 
encoding for output (which is UTF-8). My rewriter pipeline is using the default 
html-generator and html-serializer provided by sling.

My code is available on GitHub here:

https://github.com/Whistlepost/emojistrip

It provides a very simple app/content project pair with some emoji characters 
in the content (see src/main/resources/SLING-INF/content/phrases.json). Many 
thanks.




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

[RESULT] [VOTE] Release Sling Hypermedia API client-side tools 1.0.0

[Andrei Dulvac]

Hi,
The vote has passed with the following result :
+5 (binding): Carsten Ziegler, Stefan Egli, Stefan Seifert, Daniel
Klco, Karl Pauls
I will copy this release to the Sling dist directory andpromote the
artifacts to the central Maven repository.