Re: [VOTE] Release Apache Sling Feature Flags 1.2.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Aug 19, 2016 at 9:22 PM, Justin Edelson 
wrote:

> +1
>
> On Fri, Aug 19, 2016 at 12:56 PM Daniel Klco  wrote:
>
> > +1
> >
> > On Fri, Aug 19, 2016 at 12:52 PM, Stefan Seifert  >
> > wrote:
> >
> > > +1
> > >
> > >
> >
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Release Apache Sling Engine 2.6.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Aug 19, 2016 at 3:21 PM, Daniel Klco  wrote:

> +1 (checked signatures and build)
>
> On Fri, Aug 19, 2016 at 6:36 AM, Stefan Seifert 
> wrote:
>
> > +1
> >
> >
>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5982:
---

started discussion on felix list 
http://apache-felix.18485.x6.nabble.com/Converter-Flexible-Adpater-Rule-convert-A-to-X-and-vice-versa-td5018171.html

> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> this is about the context-aware configuration: 
> https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to  
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Karl Pauls]

On Fri, Aug 19, 2016 at 4:03 PM, Bertrand Delacretaz  wrote:

> On Fri, Aug 19, 2016 at 3:19 PM, Karl Pauls  wrote:
> >>... I guess at a minimum I would make sure that the problem is fixed in
> trunk
> >> first so that it at least doesn't happen again.
> >>
> > I can try to look into it tonight if you want me too ...
>
> You're welcome! It's probably very simple but ENOTIME here at the
> moment, doing the headless chicken thing on other fronts ;-)
>

Done.

I guess I went the easy way for now by adding a Include-Resource statement
to the maven-bundle-plugin instructions (a better way probably would be to
move the LICENSE and NOTICE files to src/main/resources/appended-resources
and use the remote resources plugin but oh well).

regards,

Karl


> -Bertrand
>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Updated] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5982:
--
Description: 
this is about the context-aware configuration: 
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config

currently we use the out-of-the-box functionality of the OSGi converter server 
to map a resource valuemap properties to an annotation class. this works very 
well.

however some things need to be improved, and we need a custom conversion 
adapter rules for this:
* the dynamic proxy created by the converter (see 
[ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
 only knows the Map interface, not ValueMap, thus it accesses directly the 
"raw" type from the value map. all the conversion magic that exists in the JCR 
value map implementation is not applied. the converter has it's own magic, but 
it will not always produce the same results as the JCR mapping magic. thus we 
need an adaption rule from ValueMap to  which used the 
valuemap get methods with the type required for the property as second argument.
* problem: the converter service currently supports explicit mappings from type 
A to B, not mapping from type A to any type. most of the rule method variants 
are currently not implemented in the felix converter impl. i will post a 
question for this issues on the felix mailing list.

once we have this custom conversion rule in place we can do further 
improvements:
* create our own sling-variant of "ConversionException" and make sure it is 
thrown in all relevant cases (on conversion, on property accesS) instead of the 
built-in one from the conversion service
* support nested configurations and nested configuration lists - when access to 
a subresource is detected (does currently not work, valuemap returns null) 
adapt the subresource to valuemap and convert it.

  was:
currently we use the out-of-the-box functionality of the OSGi converter server 
to map a resource valuemap properties to an annotation class. this works very 
well.

however some things need to be improved, and we need a custom conversion 
adapter rules for this:
* the dynamic proxy created by the converter (see 
[ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
 only knows the Map interface, not ValueMap, thus it accesses directly the 
"raw" type from the value map. all the conversion magic that exists in the JCR 
value map implementation is not applied. the converter has it's own magic, but 
it will not always produce the same results as the JCR mapping magic. thus we 
need an adaption rule from ValueMap to  which used the 
valuemap get methods with the type required for the property as second argument.
* problem: the converter service currently supports explicit mappings from type 
A to B, not mapping from type A to any type. most of the rule method variants 
are currently not implemented in the felix converter impl. i will post a 
question for this issues on the felix mailing list.

once we have this custom conversion rule in place we can do further 
improvements:
* create our own sling-variant of "ConversionException" and make sure it is 
thrown in all relevant cases (on conversion, on property accesS) instead of the 
built-in one from the conversion service
* support nested configurations and nested configuration lists - when access to 
a subresource is detected (does currently not work, valuemap returns null) 
adapt the subresource to valuemap and convert it.


> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> this is about the context-aware configuration: 
> https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value 

[jira] [Closed] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-5946.
---

> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding 
> {{}} and 

[jira] [Closed] (SLING-5761) add Double XSS validator

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-5761.
---

> add Double XSS validator
> 
>
> Key: SLING-5761
> URL: https://issues.apache.org/jira/browse/SLING-5761
> Project: Sling
>  Issue Type: New Feature
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: XSS Protection API 1.0.12
>
>
> It would be useful to have a getValidDouble(). The underlying method is 
> available in ESAPI, we just need to expose it.
> I don't think there's a need for getValidFloat() at this time.



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

[jira] [Closed] (SLING-5954) Disable non-essential features in XML parser

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-5954.
---

> Disable non-essential features in XML parser
> 
>
> Key: SLING-5954
> URL: https://issues.apache.org/jira/browse/SLING-5954
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: XSS Protection API 1.0.12
>
>
> Non-essential XML parsing features should be disabled in the XSS module's XML 
> parser, to avoid performance hits for example.



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

[jira] [Updated] (SLING-5946) XSSAPI#encodeForJSString is not restrictive enough

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5946:

Fix Version/s: (was: XSS Protection API 1.0.10)
   XSS Protection API 1.0.12

> XSSAPI#encodeForJSString is not restrictive enough
> --
>
> Key: SLING-5946
> URL: https://issues.apache.org/jira/browse/SLING-5946
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: XSS Protection API 1.0.8
>Reporter: Vlad Bailescu
>Assignee: Robert Munteanu
> Fix For: XSS Protection API 1.0.12
>
> Attachments: SLING_5946.patch
>
>
> Since SLING-5445, {{XSSAPI#encodeForJSString}} is no longer properly encoding 
> {{}} and 

Re: [VOTE] Release Apache Sling Feature Flags 1.2.0

[Justin Edelson]

+1

On Fri, Aug 19, 2016 at 12:56 PM Daniel Klco  wrote:

> +1
>
> On Fri, Aug 19, 2016 at 12:52 PM, Stefan Seifert 
> wrote:
>
> > +1
> >
> >
>

[jira] [Created] (SLING-5984) Queries with findResources

[Christoph Thodte (JIRA)]

Christoph Thodte created SLING-5984:
---

 Summary: Queries with findResources
 Key: SLING-5984
 URL: https://issues.apache.org/jira/browse/SLING-5984
 Project: Sling
  Issue Type: Improvement
  Components: NoSQL
Affects Versions: NoSQL MongoDB Resource Provider 1.1.0
Reporter: Christoph Thodte


Query-method in in ResourceProvider for MongoDB is not implemented:
https://github.com/apache/sling/blob/trunk/contrib/nosql/generic/src/main/java/org/apache/sling/nosql/generic/adapter/AbstractNoSqlAdapter.java

and 
https://github.com/apache/sling/blob/trunk/contrib/nosql/mongodb-resourceprovider/src/main/java/org/apache/sling/nosql/mongodb/resourceprovider/impl/MongoDBNoSqlAdapter.java

I think that's an additional task to implement this method. The MongoDB Query 
syntax should be supported. 

What do you think about?



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

[jira] [Commented] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5982:
---

yes, this makes sense. will further check this.

on the other side: we have to keep in mind we need parameter metadata support 
as well. that means supporting a management API for configuration editors which 
can get a list of all configuration parameter metadata (configuration classes, 
parameters, types, default values, documentation) to offer a visual 
configuration editor similar to the functionality OSGi config web console, but 
with support for context/paths, inheritance etc. the only source i currently 
see for this metadata are the annotation classes, perhaps with further 
annotations for lables/descriptions etc.

if we support to convert anything to anything in the configuration API classes, 
it will become very difficult for the configuration editor to catch up and 
automatically provide a generic editor GUI for edit. thus my current plan was 
to stick with annotation classes only, and support only the important primitive 
data types plus nested configuration classes and lists.

> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to  
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

RE: [VOTE] Release Apache Sling Feature Flags 1.2.0

[Stefan Seifert]

+1 

Re: [VOTE] Release Apache Sling Feature Flags 1.2.0

[Daniel Klco]

+1

On Fri, Aug 19, 2016 at 12:52 PM, Stefan Seifert 
wrote:

> +1
>
>

Duplicate Script Cache Clearing Functionality

[Daniel Klco]

Hey All,

I noticed that we have duplicate cache clearing functionality between:

   - JSP Scripting Console
   - FS ClassLoader Console

I also noticed that the FS ClassLoader doesn't reset the JSP Context when
it clears the cache. I'm thinking of:

   - Removing the JSP Scripting Console
   - Adding a method to register listeners into the ClassLoaderWriter for
   cache clears to occur
   - Updating the JSP Engine Factory to register a listener which clears
   out the JSP Context

I thought about exposing the classloader cache clear as a Sling event, but
this seems like such a low-level implementation detail I'm not sure that
makes sense.

Any concerns or questions about this approach?

Regards,
Dan

Please see the ticket for more details about the bundles/classes involved:
https://issues.apache.org/jira/browse/SLING-5980

[jira] [Commented] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5982:
-

[~sseif...@pro-vision.de] The OSGi Converter service is extensible, so we can 
add our own rule for converting a ValueMap to something while still benefiting 
from the general rules. If we can help identifying what is missing in the 
Converter I'm pretty sure we can get it quickly.
I rather would like to use a standard service then creating our own 
implementation, even if it is a small thing


> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to  
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

[jira] [Created] (SLING-5983) Remove deprecated jcr resource API

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5983:
---

 Summary: Remove deprecated jcr resource API
 Key: SLING-5983
 URL: https://issues.apache.org/jira/browse/SLING-5983
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.8.2


The jcr resource API has been deprecated for some time and not used anymore in 
our codebase, we should now remove it from the jcr resource bundle



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

[jira] [Commented] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5982:
---

another thought: if we only support annotation classes for conversion and 
nothing of the other features of the osgi converter service we may think about 
not using it at all.
currently we are using only very few lines of code from it (basically only one 
method 
[ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311]
 mentioned above).

and now we want to replace this method with a custom adapter, using nearly 
nothing of the converter at all, because we want to stick to the conversion 
magic from the jcr value map implementation (or whatever resource provider is 
used), and need the special handling for nested configurations.

> Use custom converter adaption from ValueMap to Annotation class
> ---
>
> Key: SLING-5982
> URL: https://issues.apache.org/jira/browse/SLING-5982
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to  
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

[jira] [Updated] (SLING-5221) Implement query provider

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5221:

Fix Version/s: (was: JCR Resource 2.8.2)

> Implement query provider 
> -
>
> Key: SLING-5221
> URL: https://issues.apache.org/jira/browse/SLING-5221
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Reporter: Carsten Ziegeler
> Attachments: jcrresource-patch.txt
>
>
> We should implement the new query provider interface in the JCR implementation



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

[jira] [Created] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-5982:
-

 Summary: Use custom converter adaption from ValueMap to Annotation 
class
 Key: SLING-5982
 URL: https://issues.apache.org/jira/browse/SLING-5982
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Context-Aware Configuration 1.0.0


currently we use the out-of-the-box functionality of the OSGi converter server 
to map a resource valuemap properties to an annotation class. this works very 
well.

however some things need to be improved, and we need a custom conversion 
adapter rules for this:
* the dynamic proxy created by the converter (see 
[ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
 only knows the Map interface, not ValueMap, thus it accesses directly the 
"raw" type from the value map. all the conversion magic that exists in the JCR 
value map implementation is not applied. the converter has it's own magic, but 
it will not always produce the same results as the JCR mapping magic. thus we 
need an adaption rule from ValueMap to  which used the 
valuemap get methods with the type required for the property as second argument.
* problem: the converter service currently supports explicit mappings from type 
A to B, not mapping from type A to any type. most of the rule method variants 
are currently not implemented in the felix converter impl. i will post a 
question for this issues on the felix mailing list.

once we have this custom conversion rule in place we can do further 
improvements:
* create our own sling-variant of "ConversionException" and make sure it is 
thrown in all relevant cases (on conversion, on property accesS) instead of the 
built-in one from the conversion service
* support nested configurations and nested configuration lists - when access to 
a subresource is detected (does currently not work, valuemap returns null) 
adapt the subresource to valuemap and convert it.



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

[jira] [Updated] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4752:

Labels:   (was: Sling-9-ReleaseNotes)

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
> Attachments: api-patch.txt, resourceresolver-patch.txt
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

[jira] [Updated] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4752:

Fix Version/s: (was: API 2.15.0)
   (was: Resource Resolver 1.5.0)
   (was: JCR Resource 2.9.0)

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
> Attachments: api-patch.txt, resourceresolver-patch.txt
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

Re: [VOTE] Release Apache Sling Feature Flags 1.2.0

[Carsten Ziegeler]

+1


 

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

[VOTE] Release Apache Sling Feature Flags 1.2.0

[Carsten Ziegeler]

Hi,

we solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338056

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1508/

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 1508 /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.

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

[jira] [Resolved] (SLING-5981) Provide access to Features service in execution context

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5981.
-
Resolution: Fixed

Added in rev 1756930

> Provide access to Features service in execution context
> ---
>
> Key: SLING-5981
> URL: https://issues.apache.org/jira/browse/SLING-5981
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Flags
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Feature Flags 1.1.2
>
>
> The execution context currently only provides access to the resource resolver 
> and the request (both optional).
> if a feature wants to check for other features, it needs a reference to the 
> Features service - which in turn gets all Feature services. To avoid a 
> circular dependency chain and to make checking for other features easier we 
> should provide this through the execution context



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

[jira] [Created] (SLING-5980) Duplicate Script Cache Clearing Functionality

[Dan Klco (JIRA)]

Dan Klco created SLING-5980:
---

 Summary: Duplicate Script Cache Clearing Functionality
 Key: SLING-5980
 URL: https://issues.apache.org/jira/browse/SLING-5980
 Project: Sling
  Issue Type: Bug
Affects Versions: File System ClassLoader 1.0.2, Scripting JSP 2.1.8
Reporter: Dan Klco


Currently, there are two ways to clear the scripting classloader cache, one in 
the [JSP Scripting 
Console]((https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java)
 (http://localhost:8080/system/console/slingjsp) and on in the [File System 
ClassLoader 
Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java)
 (http://localhost:8080/system/console/fsclassloader) 
Unfortunately these two consoles perform slightly differently:

 * JSP Scripting Console - only clears out the JSPs and also destroys the JSP 
Runtime Context
 * FS ClassLoader - Clears out all script compiled files including JSP, 
Sightly, etc

I'm thinking about doing the following:

 * Removing the JSP Scripting Console
 * Adding a method into the ClassLoaderWriter for scripting providers to 
register and unregister a listener for classloader cache flushes

Consolidating the functionality will make the use of the console clearer. With 
the callback, the JSP Script Engine (or any other scripting engine for that 
matter) could react to a cache clear and perform the appropriate actions. 



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

[jira] [Created] (SLING-5981) Provide access to Features service in execution context

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5981:
---

 Summary: Provide access to Features service in execution context
 Key: SLING-5981
 URL: https://issues.apache.org/jira/browse/SLING-5981
 Project: Sling
  Issue Type: New Feature
  Components: Feature Flags
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Feature Flags 1.1.2


The execution context currently only provides access to the resource resolver 
and the request (both optional).
if a feature wants to check for other features, it needs a reference to the 
Features service - which in turn gets all Feature services. To avoid a circular 
dependency chain and to make checking for other features easier we should 
provide this through the execution context



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

[jira] [Assigned] (SLING-5980) Duplicate Script Cache Clearing Functionality

[Dan Klco (JIRA)]

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

Dan Klco reassigned SLING-5980:
---

Assignee: Dan Klco

> Duplicate Script Cache Clearing Functionality
> -
>
> Key: SLING-5980
> URL: https://issues.apache.org/jira/browse/SLING-5980
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Scripting JSP 2.1.8, File System ClassLoader 1.0.2
>Reporter: Dan Klco
>Assignee: Dan Klco
>
> Currently, there are two ways to clear the scripting classloader cache, one 
> in the [JSP Scripting 
> Console]((https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java)
>  (http://localhost:8080/system/console/slingjsp) and on in the [File System 
> ClassLoader 
> Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java)
>  (http://localhost:8080/system/console/fsclassloader) 
> Unfortunately these two consoles perform slightly differently:
>  * JSP Scripting Console - only clears out the JSPs and also destroys the JSP 
> Runtime Context
>  * FS ClassLoader - Clears out all script compiled files including JSP, 
> Sightly, etc
> I'm thinking about doing the following:
>  * Removing the JSP Scripting Console
>  * Adding a method into the ClassLoaderWriter for scripting providers to 
> register and unregister a listener for classloader cache flushes
> Consolidating the functionality will make the use of the console clearer. 
> With the callback, the JSP Script Engine (or any other scripting engine for 
> that matter) could react to a cache clear and perform the appropriate 
> actions. 



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

[jira] [Updated] (SLING-5980) Duplicate Script Cache Clearing Functionality

[Dan Klco (JIRA)]

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

Dan Klco updated SLING-5980:

Description: 
Currently, there are two ways to clear the scripting classloader cache, one in 
the [JSP Scripting 
Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java)
 (http://localhost:8080/system/console/slingjsp) and on in the [File System 
ClassLoader 
Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java)
 (http://localhost:8080/system/console/fsclassloader) 
Unfortunately these two consoles perform slightly differently:

 * JSP Scripting Console - only clears out the JSPs and also destroys the JSP 
Runtime Context
 * FS ClassLoader - Clears out all script compiled files including JSP, 
Sightly, etc

I'm thinking about doing the following:

 * Removing the JSP Scripting Console
 * Adding a method into the ClassLoaderWriter for scripting providers to 
register and unregister a listener for classloader cache flushes

Consolidating the functionality will make the use of the console clearer. With 
the callback, the JSP Script Engine (or any other scripting engine for that 
matter) could react to a cache clear and perform the appropriate actions. 

  was:
Currently, there are two ways to clear the scripting classloader cache, one in 
the [JSP Scripting 
Console]((https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java)
 (http://localhost:8080/system/console/slingjsp) and on in the [File System 
ClassLoader 
Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java)
 (http://localhost:8080/system/console/fsclassloader) 
Unfortunately these two consoles perform slightly differently:

 * JSP Scripting Console - only clears out the JSPs and also destroys the JSP 
Runtime Context
 * FS ClassLoader - Clears out all script compiled files including JSP, 
Sightly, etc

I'm thinking about doing the following:

 * Removing the JSP Scripting Console
 * Adding a method into the ClassLoaderWriter for scripting providers to 
register and unregister a listener for classloader cache flushes

Consolidating the functionality will make the use of the console clearer. With 
the callback, the JSP Script Engine (or any other scripting engine for that 
matter) could react to a cache clear and perform the appropriate actions. 


> Duplicate Script Cache Clearing Functionality
> -
>
> Key: SLING-5980
> URL: https://issues.apache.org/jira/browse/SLING-5980
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Scripting JSP 2.1.8, File System ClassLoader 1.0.2
>Reporter: Dan Klco
>Assignee: Dan Klco
>
> Currently, there are two ways to clear the scripting classloader cache, one 
> in the [JSP Scripting 
> Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp/src/main/java/org/apache/sling/scripting/jsp/JspScriptEngineFactory.java)
>  (http://localhost:8080/system/console/slingjsp) and on in the [File System 
> ClassLoader 
> Console](https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/fsclassloader/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java)
>  (http://localhost:8080/system/console/fsclassloader) 
> Unfortunately these two consoles perform slightly differently:
>  * JSP Scripting Console - only clears out the JSPs and also destroys the JSP 
> Runtime Context
>  * FS ClassLoader - Clears out all script compiled files including JSP, 
> Sightly, etc
> I'm thinking about doing the following:
>  * Removing the JSP Scripting Console
>  * Adding a method into the ClassLoaderWriter for scripting providers to 
> register and unregister a listener for classloader cache flushes
> Consolidating the functionality will make the use of the console clearer. 
> With the callback, the JSP Script Engine (or any other scripting engine for 
> that matter) could react to a cache clear and perform the appropriate 
> actions. 



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

[jira] [Resolved] (SLING-5886) Sling Context-Aware Configuration - Initial Contribution

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-5886.
---
   Resolution: Fixed
Fix Version/s: Context-Aware Configuration 1.0.0

thanks carsten for submitting this part. i did some more cosmetic refactorings 
and renamings yesterday and today. most relevant changes are:
* first simple set of integration tests added
* updated unit tests to cover more conversion cases already supported by the 
osgi converter service
* subtle change to ConfiguraitonBuilder API: my goal is that that the "as" 
conversion method never returns null, to avoid constantly checking for null 
when accessing it. (the @NonNull annotation already that this, but the javadoc 
said another and the impl could return null). my goal is to return an empty 
annotation class/with default values in this case. only if even the conversion 
of an empty map fails (e.g. target class is invalid and cannot be instantiated 
at all) a runtime exception is thrown. if we need further discussion on this 
perhaps in a separate ticket.
* currently ConversionExceptions from the osgi converter may get through to the 
upstream code. we may want to prevent this, but this would be another ticket.

i will set this ticket to resolved, further work (and a lot is left) will 
continue in separate tickets.

> Sling Context-Aware Configuration - Initial Contribution
> 
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> as discussed in the mailing list (see [my post from april 
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
>  i want to contribute the wcm.io Configuration parts that are not 
> AEM-specific.
> the current features of wcm.io Configuration are described here: 
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means 
> configuration that is different for different content paths (e.g. sites, 
> tenants).
> during the contribution some changes and refactorings are required/planned, 
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration 
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and 
> support OSGi R6-style annotation classed for typed configuration access
> _Update: as discussed at http://sling.markmail.org/thread/ka3ewlswfgjy7rpu 
> the name of this new module is Context-Aware Configuration_



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

[RESULT][VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Bertrand Delacretaz]

Hi,

On Fri, Aug 12, 2016 at 10:23 AM, Bertrand Delacretaz
 wrote:
> ...Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1500/ ...

The vote passes with +1 from Carsten, Ian, Oliver and myself and -1
from Karl who in his own words "can live with being overruled by the
majority", his +1 is about suboptimal NOTICE/LICENSE info.

Thanks, I'll push the artifacts out now.

-Bertrand

Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Bertrand Delacretaz]

On Fri, Aug 19, 2016 at 3:19 PM, Karl Pauls  wrote:
>>... I guess at a minimum I would make sure that the problem is fixed in trunk
>> first so that it at least doesn't happen again.
>>
> I can try to look into it tonight if you want me too ...

You're welcome! It's probably very simple but ENOTIME here at the
moment, doing the headless chicken thing on other fronts ;-)

-Bertrand

[jira] [Resolved] (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 resolved SLING-5944.
-
Resolution: Fixed

Fixed in [r1756915|https://svn.apache.org/r1756915].

> 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] [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 Compiler 1.0.0

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

Re: [VOTE] Release Apache Sling Engine 2.6.0

[Daniel Klco]

+1 (checked signatures and build)

On Fri, Aug 19, 2016 at 6:36 AM, Stefan Seifert 
wrote:

> +1
>
>

Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Karl Pauls]

On Friday, August 19, 2016, Karl Pauls  wrote:

> On Fri, Aug 19, 2016 at 12:53 PM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
>> Hi Karl,
>>
>> On Wed, Aug 17, 2016 at 12:42 AM, Karl Pauls > > wrote:
>> > ...It seems to me that at a minimum the NOTICE and LICENSE of the source
>> > release should be used for the binary as well, no?...
>>
>> Good catch - what happens is that the bundles/extensions/xss source
>> code provides its own NOTICE/LICENSE files, which might be needed for
>> the binary distribution as that embeds a number of things.
>>
>> But for some reason those files are only taken into account when
>> building the source archive.
>>
>> As you didn't -1 this vote I assume you are ok with releasing as is
>> and taking care of this issue separately?
>>
>
> Well, technically I guess, you have enough +1 votes already to do as you
> please so it really is up to you :-).
>
> Personally, however, I really don't like releasing artifacts with improper
> NOTICE/LICENSE files so I'm -1 but I can live with being overruled by the 
> majority
> vote.
>
> I guess at a minimum I would make sure that the problem is fixed in trunk
> first so that it at least doesn't happen again.
>

I can try to look into it tonight if you want me too ...

regards,

Karl



> regards,
>
> Karl
>
> -Bertrand
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com 
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

[jira] [Updated] (SLING-5886) Sling Context-Aware Configuration - Initial Contribution

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5886:
--
Labels: contextaware-config  (was: )

> Sling Context-Aware Configuration - Initial Contribution
> 
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
>
> as discussed in the mailing list (see [my post from april 
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
>  i want to contribute the wcm.io Configuration parts that are not 
> AEM-specific.
> the current features of wcm.io Configuration are described here: 
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means 
> configuration that is different for different content paths (e.g. sites, 
> tenants).
> during the contribution some changes and refactorings are required/planned, 
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration 
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and 
> support OSGi R6-style annotation classed for typed configuration access
> _Update: as discussed at http://sling.markmail.org/thread/ka3ewlswfgjy7rpu 
> the name of this new module is Context-Aware Configuration_



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

Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Karl Pauls]

On Fri, Aug 19, 2016 at 12:53 PM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:

> Hi Karl,
>
> On Wed, Aug 17, 2016 at 12:42 AM, Karl Pauls  wrote:
> > ...It seems to me that at a minimum the NOTICE and LICENSE of the source
> > release should be used for the binary as well, no?...
>
> Good catch - what happens is that the bundles/extensions/xss source
> code provides its own NOTICE/LICENSE files, which might be needed for
> the binary distribution as that embeds a number of things.
>
> But for some reason those files are only taken into account when
> building the source archive.
>
> As you didn't -1 this vote I assume you are ok with releasing as is
> and taking care of this issue separately?
>

Well, technically I guess, you have enough +1 votes already to do as you
please so it really is up to you :-).

Personally, however, I really don't like releasing artifacts with improper
NOTICE/LICENSE files so I'm -1 but I can live with being overruled by
the majority
vote.

I guess at a minimum I would make sure that the problem is fixed in trunk
first so that it at least doesn't happen again.

regards,

Karl

-Bertrand
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Release Apache Sling XSS Protection Bundle 1.0.12

[Bertrand Delacretaz]

Hi Karl,

On Wed, Aug 17, 2016 at 12:42 AM, Karl Pauls  wrote:
> ...It seems to me that at a minimum the NOTICE and LICENSE of the source
> release should be used for the binary as well, no?...

Good catch - what happens is that the bundles/extensions/xss source
code provides its own NOTICE/LICENSE files, which might be needed for
the binary distribution as that embeds a number of things.

But for some reason those files are only taken into account when
building the source archive.

As you didn't -1 this vote I assume you are ok with releasing as is
and taking care of this issue separately?

-Bertrand

RE: [VOTE] Release Apache Sling Engine 2.6.0

[Stefan Seifert]

+1 

Re: [VOTE] Release Apache Sling Engine 2.6.0

[Carsten Ziegeler]

+1

 

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

[jira] [Closed] (SLING-5964) BackgroundServletStarterFilter is using deprecated filter registration properties

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-5964.
---

> BackgroundServletStarterFilter is using deprecated filter registration 
> properties
> -
>
> Key: SLING-5964
> URL: https://issues.apache.org/jira/browse/SLING-5964
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Background Servlets 1.0.8
>
>




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

[VOTE RESULT] Release Apache Sling bgservlets 1.0.8

[Carsten Ziegeler]

The vote passed with 5 binding +1 votes

 Thanks

Carsten

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

[VOTE] Release Apache Sling Engine 2.6.0

[Carsten Ziegeler]

Hi,

we solved 2 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338055

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1507/

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 1507 /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.

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

[jira] [Resolved] (SLING-5979) RequestLoggerFilter is using wrong registration property

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5979.
-
Resolution: Fixed

> RequestLoggerFilter is using wrong registration property
> 
>
> Key: SLING-5979
> URL: https://issues.apache.org/jira/browse/SLING-5979
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.5.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Engine 2.5.2
>
>
> The filter is using 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN
> but it should use
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN



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

[jira] [Created] (SLING-5979) RequestLoggerFilter is using wrong registration property

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5979:
---

 Summary: RequestLoggerFilter is using wrong registration property
 Key: SLING-5979
 URL: https://issues.apache.org/jira/browse/SLING-5979
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Engine 2.5.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Engine 2.5.2


The filter is using 
HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN
but it should use
HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN



--
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=15427858#comment-15427858
 ] 

Ben Fortuna edited comment on SLING-5973 at 8/19/16 9:26 AM:
-

Ah ok, so my rewriter pipeline includes a reasonably simple transformer 
implementation that extends from DefaultTransformer. See here for details:

https://github.com/micronode/whistlepost/tree/master/whistlepost-rewrite-lib

You'll find the implementation (LinkTransformerFactory) is only concerned with 
rewriting links in the output to remove the /content from the path.

The other references in that config (html-generator, html-serializer) are 
provided by Sling itself. I should also probably mention that I am using the 
official Sling docker container to test this, however I have confirmed the 
default file encoding, etc. is still UTF-8 in this environment.

Now that I think of it, I guess the rewriter (and the html-serializer) is only 
"activated" on the paths specified by the transformer, which means you won't 
have an issue unless the path matches the transformer configuration.


was (Author: fortuna):
Ah ok, so my rewriter pipeline includes a reasonably simple transformer 
implementation that extends from DefaultTransformer. See here for details:

https://github.com/micronode/whistlepost/tree/master/whistlepost-rewrite-lib

You'll find the implementation (LinkTransformerFactory) is only concerned with 
rewriting links in the output to remove the /content from the path.

The other references in that config (html-generator, html-serializer) are 
provided by Sling itself. I should also probably mention that I am using the 
official Sling docker container to test this, however I have confirmed the 
default file encoding, etc. is still UTF-8 in this environment.


> 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=15427858#comment-15427858
 ] 

Ben Fortuna commented on SLING-5973:


Ah ok, so my rewriter pipeline includes a reasonably simple transformer 
implementation that extends from DefaultTransformer. See here for details:

https://github.com/micronode/whistlepost/tree/master/whistlepost-rewrite-lib

You'll find the implementation (LinkTransformerFactory) is only concerned with 
rewriting links in the output to remove the /content from the path.

The other references in that config (html-generator, html-serializer) are 
provided by Sling itself. I should also probably mention that I am using the 
official Sling docker container to test this, however I have confirmed the 
default file encoding, etc. is still UTF-8 in this environment.


> 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=15427836#comment-15427836
 ] 

Oliver Lietz commented on SLING-5973:
-

[~fortuna], enabling the Rewriter alone doesn't cause your problems (see 
{{EmojiIT}}) and I'm trying to get the missing pieces. One is the configuration 
and another is your {{wp-link-rewriter}}. Please add that also.

> 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-4075) Improve test coverage of SCD

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-4075:
---
Summary: Improve test coverage of SCD  (was: Improve test coverage of Sling 
Replication)

> Improve test coverage of SCD
> 
>
> Key: SLING-4075
> URL: https://issues.apache.org/jira/browse/SLING-4075
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> Currently we moved lots of testing to the IT module but it'd be good to have 
> a better test coverage via unit testing in core module, at least to test 
> basic use cases and maybe some edge cases.



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

RE: Sling Model default Implementation Picker

[Stefan Seifert]

>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

the source of this doc is here:
https://svn.apache.org/repos/asf/sling/site/trunk/content/documentation/bundles/models.mdtext

if you can put together a patch file for this we can apply it easily.

stefan

[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=15427738#comment-15427738
 ] 

Ben Fortuna commented on SLING-5973:


[~olli] I don't have any configuration specifically for the html-serializer 
(i.e. just uses defaults). Here is an example of the rewriter config I am using:

{code}
{
  "wp-link-rewriter": {
"generatorType": "html-generator",
"serializerType": "html-serializer",
"paths": ["/content"],
"contentTypes": ["text/html"],
"extensions": ["html"],
"enabled": true,
"transformerTypes": ["wp-link-rewriter"],
"order": 0
  }
}
{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
> 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=15427712#comment-15427712
 ] 

Oliver Lietz commented on SLING-5973:
-

[~fortuna], please add your configuration for the {{HTMLSerializer}}.

> 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)