[jira] [Created] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-3511:
---

 Summary: Support selectors for pipeline configuration
 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6


Currently paths, contentTypes, extensions and resourceTypes are available for 
filtering pipeline configurations. I would be appreciated when filtering by 
selector would also be possible.

We have an intranet/internet application that sends newsletters to different 
groups of users. Some of the users have to access the links provided in the 
generated mails trough a portal application. Due to some other rewriting we 
apply to the links it is necessary to append a prefix to the links in the last 
step of output rewriting but only for a special selector (we use 
someresource.mail.html as representation of the this is a mail view).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:


Affects Version/s: Extensions Rewriter 1.0.4

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:


Affects Version/s: (was: Extensions Rewriter 1.0.4)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:


Attachment: rewriter-selectors-support.patch

I implemented the feature for our project and created a patch for current trunk 
of contrib/extensions/rewriter. Any comments would be appreciated. 

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support.patch

I added a test set for the match() method of the ProcessorConfigurationImpl to 
the patch that tests basic functionality based on the current implementation 
and my expectations of support for selectors.

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: (was: rewriter-selectors-support.patch)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: (was: rewriter-selectors-support.patch)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support.patch

Just added some negative test cases.

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: (was: rewriter-selectors-support.patch)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support.patch

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Commented] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160066#comment-14160066
 ] 

Dirk Rudolph commented on SLING-3511:
-

We should not forget to update the documentation at 
http://sling.apache.org/site/output-rewriting-pipelines-orgapacheslingrewriter.html.

... Good chance to move the page to the CMS :-)



 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Commented] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160121#comment-14160121
 ] 

Dirk Rudolph commented on SLING-3511:
-

Ok, thanks. However we should not forget to update the documentation after 
1.0.6 has been released.

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Commented] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160196#comment-14160196
 ] 

Dirk Rudolph commented on SLING-3511:
-

A patch against the current HTML-page wouldn't be that hard but I think the 
wrong way to provide those changes right? 

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Issue Comment Deleted] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Comment: was deleted

(was: A patch against the current HTML-page wouldn't be that hard but I think 
the wrong way to provide those changes right? )

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support-doc.patch

I added the new selectors configuration to the documentation.

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: (was: rewriter-selectors-support-doc.patch)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: (was: rewriter-selectors-support-doc.patch)

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support-doc.patch

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Updated] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-3511:

Attachment: rewriter-selectors-support-doc.patch

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Closed] (SLING-3511) Support selectors for pipeline configuration

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph closed SLING-3511.
---

Thanks

 Support selectors for pipeline configuration
 

 Key: SLING-3511
 URL: https://issues.apache.org/jira/browse/SLING-3511
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Extensions Rewriter 1.0.4
Reporter: Dirk Rudolph
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Extensions Rewriter 1.0.6

 Attachments: rewriter-selectors-support-doc.patch, 
 rewriter-selectors-support.patch


 Currently paths, contentTypes, extensions and resourceTypes are available for 
 filtering pipeline configurations. I would be appreciated when filtering by 
 selector would also be possible.
 We have an intranet/internet application that sends newsletters to different 
 groups of users. Some of the users have to access the links provided in the 
 generated mails trough a portal application. Due to some other rewriting we 
 apply to the links it is necessary to append a prefix to the links in the 
 last step of output rewriting but only for a special selector (we use 
 someresource.mail.html as representation of the this is a mail view).



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

[jira] [Created] (SLING-4789) Support custom properties in the JNDI context

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-4789:
---

 Summary: Support custom properties in the JNDI context
 Key: SLING-4789
 URL: https://issues.apache.org/jira/browse/SLING-4789
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Registration 1.0.2
Reporter: Dirk Rudolph
Priority: Minor


Currently the JNDI context is generated and populated with the service 
properties of the registration service. Those properties are filtered using a 
whitelist {{java.naming.}}

{code}
if (key.startsWith(java.naming.)) {
env.setProperty(key, (String) props.get(key));
}
{code}

So it is not possible to add custom environment properties that are actually 
used by the JNDI implementation like those defined for simple-jndi: 
{{org.osjava.sj.}}.



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

[jira] [Created] (SLING-4856) Resource resolution breaks selector string when mapped path is not normalised

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-4856:
---

 Summary: Resource resolution breaks selector string when mapped 
path is not normalised
 Key: SLING-4856
 URL: https://issues.apache.org/jira/browse/SLING-4856
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.14
Reporter: Dirk Rudolph
Priority: Minor


*Description* 
During resource resolution the resource metadata are populated with values used 
for the initialisation of the {{SlingHttpServletRequest}} in the 
{{SlingRequestProcessorImpl}}. The problem is that those metadata may be broken 
when there is a misconfigured mapping applied to the request path info.

*How to reproduce* 
1. Configure the {{ResourceResolverFactory}} to have a mapping {{//prefix}}. 
2. Create a {{Resource}} /content/path/to/resource
3. Access the {{Resource}} 
3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
3 b) using /prefix/content/path/to/resource.selector1.selector2.html/suffix.html

_Expected result_
- The path can be resolved to the {{Resource}} (/)
- The selector string is selector1.selector2 (x)
- The suffix is /suffix.html (/)

_Actual result_
In the second case (b) the selector string has a leading .. Which causes the 
{{RequestPathInfo}} to return a {{String\[3\]}}, where the first entry is an 
empty {{String}}.

*Details*
This is caused by the following code in {{resolveInternal}}

{code}
final String path = resolutionPath.toString();
final String pathInfo = absPath.substring(path.length());

resource.getResourceMetadata().setResolutionPath(path);
resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
{code}

The problem is that in this special case the resolved path starts with a // 
and is therefor not properly normalised. As the resolution is working properly 
and returned resource has its path normalised the length of resource path part 
in the absPath and resoultionPath differ by one. This causes resoultion path 
info to contain the last char of the resource path part of the absPath, which 
then causes wrong interpretation and extraction of the selector string from the 
resolution path info in the {{ResourceMetaData}}

*Use case*
In our current project based on AEM6 we use such a path prefix to use separated 
dispatcher farms for caching. We were able to fix the internal issue by 
properly configuring the prefix but as a user i would expect Sling to handle 
this misconfigured scenario either properly or at least log a warning that the 
mapped path is not normalised because debugging it was a little bit tricky. 



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

[jira] [Commented] (SLING-4856) Resource resolution breaks selector string when mapped path is not normalised

[Dirk Rudolph (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613417#comment-14613417
 ] 

Dirk Rudolph commented on SLING-4856:
-

From my point of view there are two possible solutions:

1. Proper handling of not normalised paths in {{resolveInternal}}
- Extend {{ResourceUtil#normalize(String)}} to replace // by single slash
- Call {{ResourceUtil#normalize(String)}} on the path passed to 
{{resolveInternal}}

2. Logging of not normalised result of applied mapping
- Add a method {{ResourceUtil#isNormalized(String)}}
- if log level is warning or higher call it after the mapping has been applied 
and log a warning if it returns false

What do you think? I would volunteer to provide a patch and related test cases 
for that.

 Resource resolution breaks selector string when mapped path is not normalised
 -

 Key: SLING-4856
 URL: https://issues.apache.org/jira/browse/SLING-4856
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.14
Reporter: Dirk Rudolph
Priority: Minor

 *Description* 
 During resource resolution the resource metadata are populated with values 
 used for the initialisation of the {{SlingHttpServletRequest}} in the 
 {{SlingRequestProcessorImpl}}. The problem is that those metadata may be 
 broken when there is a misconfigured mapping applied to the request path info.
 *How to reproduce* 
 1. Configure the {{ResourceResolverFactory}} to have a mapping {{//prefix}}. 
 2. Create a {{Resource}} /content/path/to/resource
 3. Access the {{Resource}} 
 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
 3 b) using 
 /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
 _Expected result_
 - The path can be resolved to the {{Resource}} (/)
 - The selector string is selector1.selector2 (x)
 - The suffix is /suffix.html (/)
 _Actual result_
 In the second case (b) the selector string has a leading .. Which causes 
 the {{RequestPathInfo}} to return a {{String\[3\]}}, where the first entry is 
 an empty {{String}}.
 *Details*
 This is caused by the following code in {{resolveInternal}}
 {code}
 final String path = resolutionPath.toString();
 final String pathInfo = absPath.substring(path.length());
 resource.getResourceMetadata().setResolutionPath(path);
 resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
 {code}
 The problem is that in this special case the resolved path starts with a // 
 and is therefor not properly normalised. As the resolution is working 
 properly and returned resource has its path normalised the length of resource 
 path part in the absPath and resoultionPath differ by one. This causes 
 resoultion path info to contain the last char of the resource path part of 
 the absPath, which then causes wrong interpretation and extraction of the 
 selector string from the resolution path info in the {{ResourceMetaData}}
 *Use case*
 In our current project based on AEM6 we use such a path prefix to use 
 separated dispatcher farms for caching. We were able to fix the internal 
 issue by properly configuring the prefix but as a user i would expect Sling 
 to handle this misconfigured scenario either properly or at least log a 
 warning that the mapped path is not normalised because debugging it was a 
 little bit tricky. 



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

[jira] [Updated] (SLING-4789) Support custom properties in the JNDI context

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-4789:

Attachment: jndi-additional-environment-properties.patch

See attached a patch, that adds a new component property to add additional 
environment properties to the env of the InitialContext (unfiltered)

> Support custom properties in the JNDI context
> -
>
> Key: SLING-4789
> URL: https://issues.apache.org/jira/browse/SLING-4789
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Registration 1.0.2
>Reporter: Dirk Rudolph
>Priority: Minor
> Attachments: jndi-additional-environment-properties.patch
>
>
> Currently the JNDI context is generated and populated with the service 
> properties of the registration service. Those properties are filtered using a 
> whitelist {{java.naming.}}
> {code}
> if (key.startsWith("java.naming.")) {
> env.setProperty(key, (String) props.get(key));
> }
> {code}
> So it is not possible to add custom environment properties that are actually 
> used by the JNDI implementation like those defined for simple-jndi: 
> {{org.osjava.sj.}}.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/29/15 7:29 AM:
--

I can confirm that the solution is working or my use case. Many thanks 
[~cziegeler]


was (Author: diru):
I can confirm that the solution is working or my use case.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068-2.patch, sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

I can confirm that the solution is working or my use case.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068-2.patch, sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/29/15 7:34 AM:
--

I can confirm that the solution is working for my use case. Many thanks 
[~cziegeler]


was (Author: diru):
I can confirm that the solution is working or my use case. Many thanks 
[~cziegeler]

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068-2.patch, sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-4352:
-

What about adding a ResourceResolverWrapper to both API and servlet resolver 
marking the second one as deprecated and switching to the API one when the 
dependency to the API gets updated next time?

I'm not completely sure about the use of reflection in that use case and the 
overhead it introduces for just replacing one method. 

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

The problem I see is, that the Servlet is cached globally and therefor the 
ScriptResource as well. So we have to change the cache to only cache the Path 
of the Resource and get the Resource from the perThreadScriptResolver each 
time. I have no idea how much this will impact the resolution performance. 

Additionally its not ThreadLocal but "RequestLocal" cause of potential Thread 
reuse depending on the (configuration of) the servlet container used. 

WDYT, would it make sense to cache the Servlet resource path only and adapt the 
Resource returned from preThreadScriptResolver to Servlet each time?

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

Isn't that exactly the same as the solution I proposed? I mean the 
ScriptResource gets instantiated with the perThreadScriptResolver anyway (via 
the passed Resource). The only advantage I see is that the sharedResource is 
not ThreadLocal but volatile. Honestly I would prefer my solution because the 
amount of Threads is limited by a ThreadPool anyway and we don't need to 
introduce a volatile member. 

Anyway in most cases sharedResource is returned so I would write an early 
return for sharedResource at the early beginning of getActiveResource(); 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068-2.patch, sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 8:52 PM:
--

Makes sense. It reduces the overhead of having a per thread copy of the 
Resource in Heap for each of the ScriptResource objects.


was (Author: diru):
Isn't that exactly the same as the solution I proposed? I mean the 
ScriptResource gets instantiated with the perThreadScriptResolver anyway (via 
the passed Resource). The only advantage I see is that the sharedResource is 
not ThreadLocal but volatile. Honestly I would prefer my solution because the 
amount of Threads is limited by a ThreadPool anyway and we don't need to 
introduce a volatile member. 

Anyway in most cases sharedResource is returned so I would write an early 
return for sharedResource at the early beginning of getActiveResource(); 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068-2.patch, sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Created] (SLING-5070) ServletResolverCacheMBeanImpl throws NPE when cache is diabled

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-5070:
---

 Summary: ServletResolverCacheMBeanImpl throws NPE when cache is 
diabled
 Key: SLING-5070
 URL: https://issues.apache.org/jira/browse/SLING-5070
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
Reporter: Dirk Rudolph
Priority: Minor


When setting the cache size configuration of SlingServletResolver to a value < 
5 the cache will be disabled and therefor be null. This causes a NPE in the 
MBean. So either the MBean is able to handle this or it will not be registered 
in that case.

{code}
Caused by: java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.SlingServletResolver$ServletResolverCacheMBeanImpl.getCacheSize(SlingServletResolver.java:1383)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at 
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at 
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
... 67 common frames omitted
{code}



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 3:09 PM:
--

Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or 
not alive anymore the shared one is returned by getResourceResolver(). Thats 
why I suggested to use the same approach for the attribute in the ScriptContext 
itself. 

Just tested this ... not working as expected :(


was (Author: diru):
Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or 
not alive anymore the shared one is returned by getResourceResolver(). Thats 
why I suggested to use the same approach for the attribute in the ScriptContext 
itself. 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

I agree. But do we have access to ScriptContext/Bindings somewhere else? From 
architectural point of view it makes sense to set "servlet resolution specific" 
bindings after servlet resolution.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

This is already done with the ScriptResource in 
SlingServletResolver#getServlet(). But the returned Servlet is shared between 
threads.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

[~cziegeler]: What about implementing a special case for get() of this 
attribute which then consumes a WeakReference instead of hard reference? When 
the reference disappears we can easily get the shared RR from the script 
resource by calling getResourceResolver again?

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

Did you mean "not set to the per thread resource resolver"? Because currently, 
as far as I understood this its set the the per thread resource resolver which 
is then closed by another thread. So it should be the shared one in each case?

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

Currently there is no ThreadLocal in ScriptResource. 

So you suggest to instead of using a WeakReference we use a ThreadLoacel to 
refer to the perThreadScriptResolver and in case it is not set we return the 
shared one. Sounds good, will give it a try. 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5070) ServletResolverCacheMBeanImpl throws NPE when cache is disabled

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5070:

Summary: ServletResolverCacheMBeanImpl throws NPE when cache is disabled  
(was: ServletResolverCacheMBeanImpl throws NPE when cache is diabled)

> ServletResolverCacheMBeanImpl throws NPE when cache is disabled
> ---
>
> Key: SLING-5070
> URL: https://issues.apache.org/jira/browse/SLING-5070
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
>Reporter: Dirk Rudolph
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Servlets Resolver 2.3.8
>
>
> When setting the cache size configuration of SlingServletResolver to a value 
> < 5 the cache will be disabled and therefor the member will be null. This 
> causes a NPE in the MBean. So either the MBean is able to handle this or it 
> will not be registered in that case.
> {code}
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.sling.servlets.resolver.internal.SlingServletResolver$ServletResolverCacheMBeanImpl.getCacheSize(SlingServletResolver.java:1383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at 
> com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> at 
> com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> ... 67 common frames omitted
> {code}



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Environment: We are facing the following issue with AEM 6.1 build on top of 
Servlet Resolver 2.3.6.  (was: We facing the following issue with AEM 6.1 build 
on top of Servlet Resolver 2.3.6.)

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on 
> top of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 3:36 PM:
--

Currently there is no ThreadLocal in ScriptResource. 

So you suggest to instead of using a WeakReference we use a ThreadLoacel to 
refer to the perThreadScriptResolver and in case it is not set we return the 
shared one. Sounds good, will give it a try. 

Or even better: we make the resource it self ThreadLocal. If not set we set it 
using path and shared RR.


was (Author: diru):
Currently there is no ThreadLocal in ScriptResource. 

So you suggest to instead of using a WeakReference we use a ThreadLoacel to 
refer to the perThreadScriptResolver and in case it is not set we return the 
shared one. Sounds good, will give it a try. 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

Works with a small modification. Because of thread reuse (I guess) there has 
been a resource in the ThreadLocal which had the perThreadScriptResolver which 
was closed by a already finished request (some minutes ago). So I checked both 
existence and state of the ResourceResolver.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 2:08 PM:
--

Did you mean "not set to the per thread resource resolver"? Because currently, 
as far as I understood this, its set the the per thread resource resolver which 
is then closed by another thread. So it should be the shared one in each case?


was (Author: diru):
Did you mean "not set to the per thread resource resolver"? Because currently, 
as far as I understood this its set the the per thread resource resolver which 
is then closed by another thread. So it should be the shared one in each case?

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

A simple workaround is setting the SlingServletResolver cache size to 0. But 
keep in mind that there will be noticeable performance decrease.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 2:04 PM:
--

[~cziegeler]: What about implementing a special case for getAttribute() for 
this attribute which then consumes a WeakReference instead of hard reference? 
When the reference disappears we can easily get the shared RR from the script 
resource by calling getResourceResolver again?


was (Author: diru):
[~cziegeler]: What about implementing a special case for get() of this 
attribute which then consumes a WeakReference instead of hard reference? When 
the reference disappears we can easily get the shared RR from the script 
resource by calling getResourceResolver again?

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: sling-5068.patch

The attached patch

 - uses a ThreadLocal for the Resource
 - in case the ScriptResource is accessed from another thread the ThreadLocal 
is unset and gets set to a Resource returned by the shared Resource Resolver
 - in case the ScriptResource is accessed from the thread that created it the 
Resource gets verified to ensure the ResourceResolver is still alive. If not 
the shared ResourceResolver will be used to fetch the resource again.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5070) ServletResolverCacheMBeanImpl throws NPE when cache is diabled

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5070:

Description: 
When setting the cache size configuration of SlingServletResolver to a value < 
5 the cache will be disabled and therefor the member will be null. This causes 
a NPE in the MBean. So either the MBean is able to handle this or it will not 
be registered in that case.

{code}
Caused by: java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.SlingServletResolver$ServletResolverCacheMBeanImpl.getCacheSize(SlingServletResolver.java:1383)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at 
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at 
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
... 67 common frames omitted
{code}

  was:
When setting the cache size configuration of SlingServletResolver to a value < 
5 the cache will be disabled and therefor be null. This causes a NPE in the 
MBean. So either the MBean is able to handle this or it will not be registered 
in that case.

{code}
Caused by: java.lang.NullPointerException: null
at 
org.apache.sling.servlets.resolver.internal.SlingServletResolver$ServletResolverCacheMBeanImpl.getCacheSize(SlingServletResolver.java:1383)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at 
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at 
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
... 67 common frames omitted
{code}


> ServletResolverCacheMBeanImpl throws NPE when cache is diabled
> --
>
> Key: SLING-5070
> URL: https://issues.apache.org/jira/browse/SLING-5070
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> When setting the cache size configuration of SlingServletResolver to a value 
> < 5 the cache will be disabled and therefor the member will be null. This 
> causes a NPE in the MBean. So either the MBean is able to handle this or it 
> will not be registered in that case.
> {code}
> Caused by: java.lang.NullPointerException: null
> at 
> 

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 3:03 PM:
--

Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or 
not alive anymore the shared one is returned by getResourceResolver(). Thats 
why I suggested to use the same approach for the attribute in the ScriptContext 
itself. 


was (Author: diru):
Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or 
not alive anymore the shared one is returned by getResourceResolver(). Thats 
why is suggested to use the same approach for the attribute in the 
ScriptContext itself. 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or 
not alive anymore the shared one is returned by getResourceResolver(). Thats 
why is suggested to use the same approach for the attribute in the 
ScriptContext itself. 

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Comment Edited] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5068 at 9/28/15 4:19 PM:
--

The attached patch uses a ThreadLocal for the Resource.

In case the ScriptResource is accessed from another thread the ThreadLocal is 
unset and gets set to a Resource returned by the shared Resource Resolver

In case the ScriptResource is accessed from the thread that created it the 
Resource gets verified to ensure the ResourceResolver is still alive. If not 
the shared ResourceResolver will be used to fetch the resource again.


was (Author: diru):
The attached patch

 - uses a ThreadLocal for the Resource
 - in case the ScriptResource is accessed from another thread the ThreadLocal 
is unset and gets set to a Resource returned by the shared Resource Resolver
 - in case the ScriptResource is accessed from the thread that created it the 
Resource gets verified to ensure the ResourceResolver is still alive. If not 
the shared ResourceResolver will be used to fetch the resource again.

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt, 
> sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-4352:
-

You could als expose an abstract ResourceResolverWrapper in the API which 
implements the actual ResourceResolver interface with delegation. The 
implementation would then only replace the close method. In that case both, 
servlet resolver and resource resolver API are still decoupled but without 
introducing reflection and without intercepting any method invocation. 

And maybe ResourceResolverWrapper would be useful in other use-cases as well.

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Comment Edited] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-4352 at 9/28/15 8:08 PM:
--

You could also expose an abstract ResourceResolverWrapper in the API which 
implements the actual ResourceResolver interface with delegation. The 
implementation would then only replace the close method. In that case both, 
servlet resolver and resource resolver API are still decoupled (depending on 
the major version only I think) but without introducing reflection and without 
intercepting any method invocation. 

And maybe ResourceResolverWrapper would be useful in other use-cases as well.


was (Author: diru):
You could also expose an abstract ResourceResolverWrapper in the API which 
implements the actual ResourceResolver interface with delegation. The 
implementation would then only replace the close method. In that case both, 
servlet resolver and resource resolver API are still decoupled but without 
introducing reflection and without intercepting any method invocation. 

And maybe ResourceResolverWrapper would be useful in other use-cases as well.

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Comment Edited] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-4352 at 9/28/15 1:20 PM:
--

This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes an ISE within 
ResourceResolver#checkClosed when the request that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.


was (Author: diru):
This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes a ISE within 
ResourceResolver#checkClosed when the Requests that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Comment Edited] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-4352 at 9/28/15 1:22 PM:
--

This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes an ISE within 
ResourceResolver#checkClosed when the request that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.

Maybe thats not the same issue but kind of related?


was (Author: diru):
This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes an ISE within 
ResourceResolver#checkClosed when the request that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-4352:
-

This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes a ISE within 
ResourceResolver#checkClosed when the Requests that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Issue Comment Deleted] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-4352:

Comment: was deleted

(was: This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 
2.3.6.

It happens that when the internal Cache of the Servlet resolver is flushed and 
multiple concurrent requests are handled by the same Servlet/Script the 
perThreadResolver is reused in different Threads and causes an ISE within 
ResourceResolver#checkClosed when the request that initially got the 
ScriptResource has been finished but the perThreadResolver is still in the 
ScriptContext of another Thread.

Maybe thats not the same issue but kind of related?)

> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Radu Cotescu
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver 
> ({{sharedScriptResolver}}) for script resolution. This same resolver is 
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in 
> {{SlingServletResolver#findScript}} (see 
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}} 
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should 
> be protected against accidental closing from downstream callers.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Summary: perThreadScriptResolver is shared between multiple Threads causing 
ISE in ResourceResolverImpl  (was: perThreadScriptResolver is shared between 
multiple Threads)

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Created] (SLING-5068) perThreadScriptResolver is shared between multiple Threads

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-5068:
---

 Summary: perThreadScriptResolver is shared between multiple Threads
 Key: SLING-5068
 URL: https://issues.apache.org/jira/browse/SLING-5068
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
 Environment: We facing the following issue with AEM 6.1 build on top 
of Servlet Resolver 2.3.6.
Reporter: Dirk Rudolph
Priority: Critical


We are building a single page application that loads small markup pieces in 
several subsequent requests. For each request the same rendering applies and so 
the same script is used.

When cleaning the ServletResolvers internal cache we get a lot of ISE 
("Resource resolver is already closed") which seems to be because the 
ResourceResolver is used in multiple Threads. 

The problem seems to be that the first request creates an entry in the servlet 
resolvers cache with a servlet that sets the perThreadScriptResolver of this 
request/thread to the context. This entry is reused in another thread. When now 
the first one finishes the processing the perThreadScriptResolver gets closed 
in the onEvent method of ServletResolver but is still used in the ScriptContext 
of another Thread. 

See the attached Exceptions we got by adding some trace logging to the 
ResourceResolverImpl (1.2.4). It proves that it is the perThreadScriptResolver 
and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: opened-and-closed-trace.txt
error-stacktrace.txt

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: error-stacktrace.txt

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, error-stacktrace.txt, 
> opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: (was: opened-and-closed-trace.txt)

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: (was: error-stacktrace.txt)

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5068:

Attachment: opened-and-closed-trace.txt

> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5068:
-

I will have a look how to implement an integration test for that. Unfortunately 
I think it will not be possible to reproduce this with an Unit test.

Think about the following timeline:

1) Request A calls resolution of Servlet A with ScriptResource using 
ResourceResolver (clone of shared RR) of Request A
2) Request B calls resolution of Servlet A and gets the cached one from 1) 
because Request A is still processed
3) Request B sets ATTR_SCRIPT_RESOURCE_RESOLVER of ScriptContext to 
ResourceResolver of scriptResource which is the ResourceResolver of Request A
4) Request A finishes and RR cloned from shared RR gets closed
5) Request B accesses ATTR_SCRIPT_RESOURCE_RESOLVER stored in ScriptContext => 
Exception



> perThreadScriptResolver is shared between multiple Threads causing ISE in 
> ResourceResolverImpl
> --
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.3.6
> Environment: We facing the following issue with AEM 6.1 build on top 
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> We are building a single page application that loads small markup pieces in 
> several subsequent requests. For each request the same rendering applies and 
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE 
> ("Resource resolver is already closed") which seems to be because the 
> ResourceResolver is used in multiple Threads. 
> The problem seems to be that the first request creates an entry in the 
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver 
> of this request/thread to the context. This entry is reused in another 
> thread. When now the first one finishes the processing the 
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver 
> but is still used in the ScriptContext of another Thread. 
> See the attached Exceptions we got by adding some trace logging to the 
> ResourceResolverImpl (1.2.4). It proves that it is the 
> perThreadScriptResolver and not the shared one that causes the problem.



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

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2][3]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
> [3] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59



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

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2][3]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
> [3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59



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

[jira] [Created] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-5516:
---

 Summary: ParameterSupportHttpServletRequestWrapper is not conform 
to Servlet API 3.0
 Key: SLING-5516
 URL: https://issues.apache.org/jira/browse/SLING-5516
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Engine 2.4.6
Reporter: Dirk Rudolph
Priority: Minor


According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2].

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127



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

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2].

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127



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

[jira] [Created] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-5947:
---

 Summary: MockSlingHttpServletRequest used with 
SlingRequestProcessor causes UnsupportedOperationException
 Key: SLING-5947
 URL: https://issues.apache.org/jira/browse/SLING-5947
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Servlet Helpers 1.0.0
Reporter: Dirk Rudolph
 Fix For: Servlet Helpers 1.0.2


{{getServletPath() throws the UnsupportedOperationException in 
MockSlingHttpServletRequest

http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685

It gets called from the SlingHttpServletRequestImpl constructor 

http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71

causing the following stacktrace:

{code}
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at 
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at 
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at 
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}



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

[jira] [Updated] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5947:

Description: 
{{getServletPath()}} throws the UnsupportedOperationException in 
MockSlingHttpServletRequest

http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685

It gets called from the SlingHttpServletRequestImpl constructor 

http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71

causing the following stacktrace:

{code}
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at 
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at 
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at 
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}

  was:
{{getServletPath() throws the UnsupportedOperationException in 
MockSlingHttpServletRequest

http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685

It gets called from the SlingHttpServletRequestImpl constructor 

http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71

causing the following stacktrace:

{code}
Caused by: java.lang.UnsupportedOperationException: null
at 
org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
at 
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
at 
org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
at 
org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
{code}


> MockSlingHttpServletRequest used with SlingRequestProcessor causes 
> UnsupportedOperationException
> 
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
> Fix For: Servlet Helpers 1.0.2
>
>
> {{getServletPath()}} throws the UnsupportedOperationException in 
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at 
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at 
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at 
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}



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

[jira] [Commented] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5947:
-

Same applies for {{getPathInfo()}}

> MockSlingHttpServletRequest used with SlingRequestProcessor causes 
> UnsupportedOperationException
> 
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
> Fix For: Servlet Helpers 1.0.2
>
>
> {{getServletPath()}} throws the UnsupportedOperationException in 
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at 
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at 
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at 
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}



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

[jira] [Commented] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-5947:
-

Fix Version should be 1.1.0 as this changes the API of 
MockSlingHttpServletRequest by adding additional setters. 

> MockSlingHttpServletRequest used with SlingRequestProcessor causes 
> UnsupportedOperationException
> 
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
>
> {{getServletPath()}} throws the UnsupportedOperationException in 
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at 
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at 
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at 
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}



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

[jira] [Comment Edited] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-5947 at 8/5/16 10:37 AM:
--

Same applies for {{getPathInfo()}}, {{getRequestURI()}}, {{getRequestURL()}}, 
{{getAuthType()}}


was (Author: diru):
Same applies for {{getPathInfo()}}

> MockSlingHttpServletRequest used with SlingRequestProcessor causes 
> UnsupportedOperationException
> 
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
>
> {{getServletPath()}} throws the UnsupportedOperationException in 
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at 
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at 
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at 
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}



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

[jira] [Updated] (SLING-5947) MockSlingHttpServletRequest used with SlingRequestProcessor causes UnsupportedOperationException

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5947:

Fix Version/s: (was: Servlet Helpers 1.0.2)

> MockSlingHttpServletRequest used with SlingRequestProcessor causes 
> UnsupportedOperationException
> 
>
> Key: SLING-5947
> URL: https://issues.apache.org/jira/browse/SLING-5947
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Servlet Helpers 1.0.0
>Reporter: Dirk Rudolph
>
> {{getServletPath()}} throws the UnsupportedOperationException in 
> MockSlingHttpServletRequest
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/servlet-helpers/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java?revision=1728734=markup#l685
> It gets called from the SlingHttpServletRequestImpl constructor 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/SlingHttpServletRequestImpl.java?view=markup#l71
> causing the following stacktrace:
> {code}
> Caused by: java.lang.UnsupportedOperationException: null
> at 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest.getServletPath(MockSlingHttpServletRequest.java:685)
> at 
> org.apache.sling.engine.impl.SlingHttpServletRequestImpl.(SlingHttpServletRequestImpl.java:71)
> at 
> org.apache.sling.engine.impl.request.RequestData$1.createRequest(RequestData.java:700)
> at 
> org.apache.sling.engine.impl.request.RequestData.(RequestData.java:215)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:121)
> at 
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:247)
> {code}



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

[jira] [Created] (SLING-6067) DefaultPropertyBasedCustomizer should be able to deploy additional bundles as test preparation

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6067:
---

 Summary: DefaultPropertyBasedCustomizer should be able to deploy 
additional bundles as test preparation
 Key: SLING-6067
 URL: https://issues.apache.org/jira/browse/SLING-6067
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: JUnit Tests Teleporter 1.0.8
Reporter: Dirk Rudolph
Priority: Minor


In general the examples of teleporter based integration tests are using 
slingstart projects to execute them, where slingstart provisions and starts a 
new sling instance to run the tests on.

In our more advanced usecase we want to run those integration tests against a 
dedicated already provisioned instance. (not Sling, but AEM). To ensure that 
the most recent build of the bundle to test ist deployed we need to deploy it 
before we run the tests. At the moment we do so using CI or locally but as an 
individual step. 

It would be nice, when the teleporter would allow to configure bundles which 
get deployed before the actual test runs. So we could deploy and run the test 
in the same step of our build.



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

[jira] [Comment Edited] (SLING-4443) Whitespace removal for Sightly HTML output

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-4443 at 9/19/16 9:51 AM:
--

What about implementing a {{CommandHandler}} similar to {{CoalescingWrites}} 
that trims all {{OutText}} commands? 

(we would welcome this functionality as well, as we are rendering components to 
package them for delivery to mobile apps and want to optimise almost everything 
possible)


was (Author: diru):
What about implementing a {{CommandHandler}} similar to {{CoalescingWrites}} 
that trims all {{OutText}} commands? 

> Whitespace removal for Sightly HTML output
> --
>
> Key: SLING-4443
> URL: https://issues.apache.org/jira/browse/SLING-4443
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Dan Chapman
>Priority: Minor
>
> Can there be a way to remove whitespace from Sightly components HTML output, 
> that is  created when elements are hidden e.g.  Previously in JSPs we could use - trimDirectiveWhitespaces="true" 



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

[jira] [Commented] (SLING-4443) Whitespace removal for Sightly HTML output

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-4443:
-

What about implementing a {{CommandHandler}} similar to {{CoalescingWrites}} 
that trims all {{OutText}} commands? 

> Whitespace removal for Sightly HTML output
> --
>
> Key: SLING-4443
> URL: https://issues.apache.org/jira/browse/SLING-4443
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Dan Chapman
>Priority: Minor
>
> Can there be a way to remove whitespace from Sightly components HTML output, 
> that is  created when elements are hidden e.g.  Previously in JSPs we could use - trimDirectiveWhitespaces="true" 



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

[jira] [Updated] (SLING-6071) JcrModifiableValueMap#remove(key) breaks Map<String, Object> contract

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6071:

Summary: JcrModifiableValueMap#remove(key) breaks Map 
contract  (was: JcrModifiableValueMap#remove(key) break Map 
contract)

> JcrModifiableValueMap#remove(key) breaks Map contract
> -
>
> Key: SLING-6071
> URL: https://issues.apache.org/jira/browse/SLING-6071
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.7.4
>Reporter: Dirk Rudolph
>
> From the contract of Map
> {quote}
> Returns the value to which this map previously associated the key, or null if 
> the map contained no mapping for the key.
> {quote}
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-
> So my expectation is that I get the value object stored in the value map, but 
> the implementation returns an instance of JcrPropertyMapCacheEntry.
> Instead of returning this object the value from the internal valueCache 
> should be returned.



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

[jira] [Created] (SLING-6071) JcrModifiableValueMap#remove(key) break Map<String, Object> contract

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6071:
---

 Summary: JcrModifiableValueMap#remove(key) break Map contract
 Key: SLING-6071
 URL: https://issues.apache.org/jira/browse/SLING-6071
 Project: Sling
  Issue Type: Bug
Affects Versions: JCR Resource 2.7.4
Reporter: Dirk Rudolph


>From the contract of Map
{quote}
Returns the value to which this map previously associated the key, or null if 
the map contained no mapping for the key.
{quote}
https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-

So my expectation is that I get the value object stored in the value map, but 
the implementation returns an instance of JcrPropertyMapCacheEntry.

Instead of returning this object the value from the internal valueCache should 
be returned.



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

[jira] [Updated] (SLING-6387) ContentLoader shouldn't commit changes or at least allow to disable auto commit

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6387:

Priority: Minor  (was: Major)

> ContentLoader shouldn't commit changes or at least allow to disable auto 
> commit
> ---
>
> Key: SLING-6387
> URL: https://issues.apache.org/jira/browse/SLING-6387
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.2
>Reporter: Dirk Rudolph
>Priority: Minor
>
> The {{ContentLoader}} always, automatically persists changes made to the 
> given {{ResoureResolver}}. This makes it hard to use for test on classes 
> implementing transactional changes. 
> Example: Having high-level APIs that do changes on the {{ResourceResolver}} 
> allowing to automatically commiting them (PageManager, AssetManager in AEM as 
> implementation on top of sling). But to keep it abstract, lets say I have a 
> class {{SpecificBinaryFileSetResource}}, which has a method 
> {{addBinaryFile}}. The goal is to implement a mock for that, so I'm using 
> {{ContentLoader}} to create a binary file in the {{ResourceResolver}}. This 
> will automatically commit the changes. Now lets extend the {{addBinaryFile}} 
> to accept a boolean parameter to not automatically commit those changes 
> (maybe because I want to make multiple changes rolling them back on error). 
> This isn't not supported so far when using ContentLoader.



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

[jira] [Commented] (SLING-6387) ContentLoader shouldn't commit changes or at least allow to disable auto commit

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6387:
-

My suggestion: Extend the API of {{ContentLoader}} with a optional boolean 
{{commit}} for each of the methods. Alternatively we could add a 
{{setAutoCommit}} method which enables/disables auto commit. But this would 
introduce a state into the {{ContentLoader}} which I want to prevent.

> ContentLoader shouldn't commit changes or at least allow to disable auto 
> commit
> ---
>
> Key: SLING-6387
> URL: https://issues.apache.org/jira/browse/SLING-6387
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.2
>Reporter: Dirk Rudolph
>
> The {{ContentLoader}} always, automatically persists changes made to the 
> given {{ResoureResolver}}. This makes it hard to use for test on classes 
> implementing transactional changes. 
> Example: Having high-level APIs that do changes on the {{ResourceResolver}} 
> allowing to automatically commiting them (PageManager, AssetManager in AEM as 
> implementation on top of sling). But to keep it abstract, lets say I have a 
> class {{SpecificBinaryFileSetResource}}, which has a method 
> {{addBinaryFile}}. The goal is to implement a mock for that, so I'm using 
> {{ContentLoader}} to create a binary file in the {{ResourceResolver}}. This 
> will automatically commit the changes. Now lets extend the {{addBinaryFile}} 
> to accept a boolean parameter to not automatically commit those changes 
> (maybe because I want to make multiple changes rolling them back on error). 
> This isn't not supported so far when using ContentLoader.



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

[jira] [Created] (SLING-6387) ContentLoader shouldn't commit changes or at least allow to disable auto commit

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6387:
---

 Summary: ContentLoader shouldn't commit changes or at least allow 
to disable auto commit
 Key: SLING-6387
 URL: https://issues.apache.org/jira/browse/SLING-6387
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing Sling Mock 2.1.2
Reporter: Dirk Rudolph


The {{ContentLoader}} always, automatically persists changes made to the given 
{{ResoureResolver}}. This makes it hard to use for test on classes implementing 
transactional changes. 

Example: Having high-level APIs that do changes on the {{ResourceResolver}} 
allowing to automatically commiting them (PageManager, AssetManager in AEM as 
implementation on top of sling). But to keep it abstract, lets say I have a 
class {{SpecificBinaryFileSetResource}}, which has a method {{addBinaryFile}}. 
The goal is to implement a mock for that, so I'm using {{ContentLoader}} to 
create a binary file in the {{ResourceResolver}}. This will automatically 
commit the changes. Now lets extend the {{addBinaryFile}} to accept a boolean 
parameter to not automatically commit those changes (maybe because I want to 
make multiple changes rolling them back on error). This isn't not supported so 
far when using ContentLoader.



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

[jira] [Commented] (SLING-6388) Support tracking changes of JCR Mock MockSession

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6388:
-

The Unit tests I wrote for SLING-6387 unfortunately fail as {{hasChanges}} 
doesn't return the expected value.

> Support tracking changes of JCR Mock MockSession
> 
>
> Key: SLING-6388
> URL: https://issues.apache.org/jira/browse/SLING-6388
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.16
>Reporter: Dirk Rudolph
>Priority: Minor
>
> {{org.apache.sling.testing.mock.jcr.MockSession#hasPendingChanges}} always 
> returns {{false}}. This causes the {{ResourceResolver}} to return {{false}} 
> for {{hasChanges()}} as well, making it difficult to use the JCR Mock 
> {{ResourceResolverType}} for tests of transactional implementations using 
> {{ResourceResolver}}



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

[jira] [Updated] (SLING-6388) Support tracking changes of JCR Mock MockSession

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6388:

Priority: Minor  (was: Major)

> Support tracking changes of JCR Mock MockSession
> 
>
> Key: SLING-6388
> URL: https://issues.apache.org/jira/browse/SLING-6388
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.16
>Reporter: Dirk Rudolph
>Priority: Minor
>
> {{org.apache.sling.testing.mock.jcr.MockSession#hasPendingChanges}} always 
> returns {{false}}. This causes the {{ResourceResolver}} to return {{false}} 
> for {{hasChanges()}} as well, making it difficult to use the JCR Mock 
> {{ResourceResolverType}} for tests of transactional implementations using 
> {{ResourceResolver}}



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

[jira] [Created] (SLING-6388) Support tracking changes of JCR Mock MockSession

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6388:
---

 Summary: Support tracking changes of JCR Mock MockSession
 Key: SLING-6388
 URL: https://issues.apache.org/jira/browse/SLING-6388
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing JCR Mock 1.1.16
Reporter: Dirk Rudolph


{{org.apache.sling.testing.mock.jcr.MockSession#hasPendingChanges}} always 
returns {{false}}. This causes the {{ResourceResolver}} to return {{false}} for 
{{hasChanges()}} as well, making it difficult to use the JCR Mock 
{{ResourceResolverType}} for tests of transactional implementations using 
{{ResourceResolver}}



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

[jira] [Comment Edited] (SLING-6387) ContentLoader shouldn't commit changes or at least allow to disable auto commit

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6387 at 12/10/16 10:12 PM:


My suggestion: Extend the API of {{ContentLoader}} with a optional boolean 
{{commit}} for each of the methods. Alternatively we could add a 
{{setAutoCommit}} method which enables/disables auto commit. This would 
introduce a state into the {{ContentLoader}} which I want to prevent.


was (Author: diru):
My suggestion: Extend the API of {{ContentLoader}} with a optional boolean 
{{commit}} for each of the methods. Alternatively we could add a 
{{setAutoCommit}} method which enables/disables auto commit. But this would 
introduce a state into the {{ContentLoader}} which I want to prevent.

> ContentLoader shouldn't commit changes or at least allow to disable auto 
> commit
> ---
>
> Key: SLING-6387
> URL: https://issues.apache.org/jira/browse/SLING-6387
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.2
>Reporter: Dirk Rudolph
>Priority: Minor
>
> The {{ContentLoader}} always, automatically persists changes made to the 
> given {{ResoureResolver}}. This makes it hard to use for test on classes 
> implementing transactional changes. 
> Example: Having high-level APIs that do changes on the {{ResourceResolver}} 
> allowing to automatically commiting them (PageManager, AssetManager in AEM as 
> implementation on top of sling). But to keep it abstract, lets say I have a 
> class {{SpecificBinaryFileSetResource}}, which has a method 
> {{addBinaryFile}}. The goal is to implement a mock for that, so I'm using 
> {{ContentLoader}} to create a binary file in the {{ResourceResolver}}. This 
> will automatically commit the changes. Now lets extend the {{addBinaryFile}} 
> to accept a boolean parameter to not automatically commit those changes 
> (maybe because I want to make multiple changes rolling them back on error). 
> This isn't not supported so far when using ContentLoader.



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

[jira] [Created] (SLING-6369) Exceptions thrown by reflection API in ModelAdapterFactory#setField() are not logged

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6369:
---

 Summary: Exceptions thrown by reflection API in 
ModelAdapterFactory#setField() are not logged
 Key: SLING-6369
 URL: https://issues.apache.org/jira/browse/SLING-6369
 Project: Sling
  Issue Type: Bug
Affects Versions: Sling Models Impl 1.2.8
Reporter: Dirk Rudolph
Priority: Minor


We got the following exception due to  "reflection issues"

{code}
06.12.2016 09:36:08.242 *WARN* [172.19.143.86 [1481013368241] GET /[…] 
HTTP/1.1] org.apache.sling.models.impl.ModelAdapterFactory Could not adapt to 
model
org.apache.sling.models.factory.MissingElementsException: Could not inject all 
required fields into class my.Model
Could not inject private org.apache.sling.api.adapter.AdapterManager 
my.Model.adapterManager caused by Could not inject field due to reflection 
issues
at 
org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:549)
at 
org.apache.sling.models.impl.ModelAdapterFactory.internalCreateModel(ModelAdapterFactory.java:310)
at 
org.apache.sling.models.impl.ModelAdapterFactory.getAdapter(ModelAdapterFactory.java:186)
at 
org.apache.sling.adapter.internal.AdapterManagerImpl.getAdapter(AdapterManagerImpl.java:147)
at 
org.apache.sling.api.adapter.SlingAdaptable.adaptTo(SlingAdaptable.java:104)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.adaptTo(ResourceResolverImpl.java:837)
at […]
at 
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:68)
at 
com.adobe.granite.resourceresolverhelper.impl.ResourceResolverHelperImpl.doFilter(ResourceResolverHelperImpl.java:84)
at 
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:68)
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:129)
at 
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:68)
at 
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:151)
at 
org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:216)
at 
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
at 
com.adobe.granite.license.impl.LicenseCheckFilter.doFilter(LicenseCheckFilter.java:308)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at 
org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:89)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at 
org.apache.sling.security.impl.ReferrerFilter.doFilter(ReferrerFilter.java:290)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at 
org.apache.sling.featureflags.impl.FeatureManager.doFilter(FeatureManager.java:116)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at 
org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:129)
at 
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
at 
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:74)
at 
org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
at 
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

This is not what this is about. See I have a resource

{code}
/content/www/my/pages/apage
 + sling:resourceType='my/test/page'
 + ...
{code}

and want to export this resource once as metadata requested with 
"model.metadata" and with "model.data" where each of the selectors represent 
different models of the same resource. So I created 

{code}
@Model(adaptables = Resource.class, resourceType='my/test/page')
@Exporter(..., selector="model.metadata")
class ModelA {
 public String getProp1() { ... } 
 public String getProp2() { ... } 
}
{code} 

and

{code}
@Model(adaptables = Resource.class, resourceType='my/test/page')
@Exporter(..., selector="model.data")
class ModelB {
 public String[] getAllProps() { ... }
}
{code} 

This is a really simplified example where the actual code applies a lot of 
*different* business logic within the different models.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

That indeed was my initial idea. Having 2 models AImpl and BImpl both 
registered to the resourceType 'my/resource/type' but having different 
selectors set for @Exporter. This unfortunately doesn't work.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

You mean registering jackson exporter again with a different name? Well from my 
expectation the exporter name somehow defines the output format: jackson => 
json, fancyxml => xml, but not the data it actually exports. I discussed this 
offline with [~kwindszus] and will propose a way we think it makes sense.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6655:

Description: 
As far as I understood the the whole story behind Sling Models API is/was that 
it can be used to adapt ordinary objects to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API, what is the purpose of that methods? I 
agree that it makes much sense to have a binding between the resourceType of 
{{Resource}} and maybe even {{SlingHttpServletRequest}} and a model, but this 
resulting into an ordinary object from API perspective makes it kind of 
pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object

  was:
As far as I understood the the whole story behind Sling Models API is/was that 
I can be used to adapt {{Adaptable}}s to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API what is the purpose of that methods? How 
and why to use them? I agree that it makes much sense to have a binding between 
the resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and 
a Model, but this resulting into an ordinary object from API perspective makes 
it kind of pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object


> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and scripting itself). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6652 at 3/16/17 7:21 PM:
--

The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

And this issue is about: multiple adapter per resourceType in general and for 
the exporter in particular. 


was (Author: diru):
The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

By example? The only one that would come to my mind is javascript. Sightly's 
use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6655:
---

 Summary: Remove untyped getModelFrom* methods from ModelFactory
 Key: SLING-6655
 URL: https://issues.apache.org/jira/browse/SLING-6655
 Project: Sling
  Issue Type: Wish
Affects Versions: Sling Models Impl 1.3.0
Reporter: Dirk Rudolph


As far as I understood the the whole story behind Sling Models API is/was that 
I can be used to adapt {{Adaptable}}s to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API what is the purpose of that methods? How 
and why to use them? I agree that it makes much sense to have a binding between 
the resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and 
a Model, but this resulting into an ordinary object from API perspective makes 
it kind of pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6655 at 3/16/17 6:58 PM:
--

By example? The only one (from sling/bundles/scripting) that would come to my 
mind is javascript. Sightly's use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?


was (Author: diru):
By example? The only one that would come to my mind is javascript. Sightly's 
use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6655 at 3/16/17 7:06 PM:
--

Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and SLING-2919 has been closed with Won't fix). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?


was (Author: diru):
Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and scripting itself). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

The difference is that its not obvious to understand what the purpose of a 
certain piece of the implementation is. Anyway, would you be so kind and point 
us to the right place where those methods are used for Handlebars? I guess 
there is a JSR-223 compliant implementation somehow exposing adaptTo() or the 
ModelFactory to the scripts themself. IMHO that one is responsible for finding 
the right adapterType instead of enforcing 1:1 resourceType to adapterType. 

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

I see your point now, thanks. 

To summarise the discussion from my perspective, there are 3 things implemented:

1. Exporter which obviously doesn't really need the model to resouceType 
binding. It only leverages the resourceType to register the {{ExportServlet}} 
accordingly 
2. The {{ResourceTypeBasedResourcePicker}} responsible for picking the right 
implementation of an adapter based on the nearest resourceType if the adaptable 
is {{Resource}} or {{SlingHttpServletRequest}}.
3. The methods {{Object getModelFromResource(...)}} and {{Object 
getModelFromRequest(...)}} used for scripting.

Still, IMHO, 3 doesn't belong to the {{ModelFactory}} but more to something 
scripting related. Having said that the implementation of those methods could 
also just use createModel(resource, Object.class) if the models itself are 
registered with adapater = Object.class, or even better using a marker 
interface. This would better fit the semantics of the ModelFactory's purpose. 
Wdyt?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)