[jira] [Resolved] (SLING-6592) JCR Content Parser

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6592.
---
Resolution: Fixed

Revision: 1787499

content parser API is changed to a Stream API (as discussed in mailing list)

> JCR Content Parser
> --
>
> Key: SLING-6592
> URL: https://issues.apache.org/jira/browse/SLING-6592
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR Content Parser 1.0.0
>
>
> for different usecases around file system resource provider and sling mocks 
> (see related tickets) we need to parse content structures from files in the 
> file system, e.g. in JSON format or JCR XML format.
> we should put this code in a new commons library so it can be reused from the 
> different projects.



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

[jira] [Commented] (SLING-6592) JCR Content Parser

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> JCR Content Parser
> --
>
> Key: SLING-6592
> URL: https://issues.apache.org/jira/browse/SLING-6592
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR Content Parser 1.0.0
>
>
> for different usecases around file system resource provider and sling mocks 
> (see related tickets) we need to parse content structures from files in the 
> file system, e.g. in JSON format or JCR XML format.
> we should put this code in a new commons library so it can be reused from the 
> different projects.



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

[GitHub] sling pull request #203: SLING-6592 switch to stream-based API for ContentPa...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


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

[jira] [Commented] (SLING-6592) JCR Content Parser

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> JCR Content Parser
> --
>
> Key: SLING-6592
> URL: https://issues.apache.org/jira/browse/SLING-6592
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR Content Parser 1.0.0
>
>
> for different usecases around file system resource provider and sling mocks 
> (see related tickets) we need to parse content structures from files in the 
> file system, e.g. in JSON format or JCR XML format.
> we should put this code in a new commons library so it can be reused from the 
> different projects.



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

[GitHub] sling pull request #202: SLING-6592 introduce "Content" interface instead of...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


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

Re: [Vote] Apache Sling Commons Json 2.0.20

[Karl Pauls]

On Fri, Mar 17, 2017 at 7:10 PM, Oliver Lietz  wrote:
> On Friday 17 March 2017 17:56:58 Karl Pauls wrote:
>> Hi,
>>
>> this release will deprecate the module and basically conclude its lifecycle.
>>
>> we solved 1 issue in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12335851
>
> +1 (baseline spits out some warnings due to excessive version increase)

Yeah, that was on purpose - its only the tick version.

regards,

Karl

> O.
>



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

Re: [Vote] Apache Sling Commons Json 2.0.20

[Oliver Lietz]

On Friday 17 March 2017 17:56:58 Karl Pauls wrote:
> Hi,
> 
> this release will deprecate the module and basically conclude its lifecycle.
> 
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12335851

+1 (baseline spits out some warnings due to excessive version increase)

O.

[VOTE] Release Apache Sling Scripting Thymeleaf 1.1.0

[Oliver Lietz]

Hi,

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

NOTE: The build requires following artifacts under vote:

org.apache.sling.testing.paxexam 0.0.4
org.apache.sling.jcr.oak.server 1.1.4
org.apache.sling.karaf-repoinit 0.2.0
org.apache.sling.scripting.jsp 2.3.0

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1671 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[VOTE] Release Apache Sling Resource Presence 0.0.2

[Oliver Lietz]

Hi,

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

NOTE: The build requires following artifacts under vote:

org.apache.sling.testing.paxexam 0.0.4
org.apache.sling.jcr.oak.server 1.1.4
org.apache.sling.karaf-repoinit 0.2.0

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1669 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[VOTE] Release Apache Sling JCR Oak Server 1.1.4

[Oliver Lietz]

Hi,

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

NOTE: The build requires following artifacts under vote:

org.apache.sling.testing.paxexam 0.0.4

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1668 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[VOTE] Release Apache Sling Testing PaxExam 0.0.4

[Oliver Lietz]

Hi,

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

NOTE: The build requires following artifacts under vote:

org.apache.sling.scripting.jsp-api 1.0.0
org.apache.sling.scripting.el-api 1.0.0

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1670 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[Vote] Apache Sling Commons Json 2.0.20

[Karl Pauls]

Hi,

this release will deprecate the module and basically conclude its lifecycle.

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

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

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1672 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

[jira] [Commented] (SLING-6639) Avoid split packages in the HTL Engine and HTL Java Compiler bundles

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6639:
---

The good thing about this change too is that previously, we had a cycle between 
these two components which is now gone. 

> Avoid split packages in the HTL Engine and HTL Java Compiler bundles
> 
>
> Key: SLING-6639
> URL: https://issues.apache.org/jira/browse/SLING-6639
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Tomek Rękawek
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.34, Scripting HTL Java Compiler 
> 1.0.10
>
> Attachments: SLING-6639.patch
>
>
> {{ResourceResolution}} and {{SightlyException}} classes should be moved to 
> the java-compiler bundle, as this is the one exporting 
> {{org.apache.sling.scripting.sightly}} package. Right now they are the part 
> of the engine bundle, which doesn't export anything and it may lead to issues 
> if some bundle tries to use these two classes.



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

[jira] [Resolved] (SLING-6536) Deprecate JSON implementation derived from org.json code

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-6536.
---
Resolution: Fixed

Now that the classes are deprecated I will do one more release with only this 
issue and that should conclude the lifetime of this module. 

I will open new issues for replacing the usage in the other sling modules after 
the release is done.

> Deprecate JSON implementation derived from org.json code
> 
>
> Key: SLING-6536
> URL: https://issues.apache.org/jira/browse/SLING-6536
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.18
>Reporter: Stefan Seifert
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Commons JSON 2.1.0
>
>
> following the discussion in
> https://lists.apache.org/thread.html/ee51bace078681765d5dcfeda1939628ccefb9b4261b1d7f6a56d420@%3Cdev.sling.apache.org%3E
> we have to replace the implementation of all classes in Commons JSON that 
> were derived from the original org.json code.
> the affected packages are
> * 
> [org.apache.sling.commons.json|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json]
> * 
> [org.apache.sling.commons.json.http|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/http]
> * 
> [org.apache.sling.commons.json.io|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/io]
> * 
> [org.apache.sling.commons.json.util|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/util]
> * 
> [org.apache.sling.commons.json.xml|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/xml]
> unfortunately the unit test coverage for those packages is not very high. the 
> main package has a line coverage of 42%, the other packages less than that or 
> no at all.
> although we might encourage modules to switch to a standard JSON 
> implementation a lot of modules inside sling and perhaps much more outside 
> sling depend on this json implementation, so we should try to keep the 
> exported API and functionality.



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

[jira] [Commented] (SLING-6536) Deprecate JSON implementation derived from org.json code

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6536:
---

As [~kwin] points out, the decision is to deprecate the full API, do one more 
release, and then retire this module. I changed the title of this issue to 
reflect this. Furthermore, I added @Deprecated to all classes and updated the 
packages tick versions in r1787440.

> Deprecate JSON implementation derived from org.json code
> 
>
> Key: SLING-6536
> URL: https://issues.apache.org/jira/browse/SLING-6536
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.18
>Reporter: Stefan Seifert
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Commons JSON 2.1.0
>
>
> following the discussion in
> https://lists.apache.org/thread.html/ee51bace078681765d5dcfeda1939628ccefb9b4261b1d7f6a56d420@%3Cdev.sling.apache.org%3E
> we have to replace the implementation of all classes in Commons JSON that 
> were derived from the original org.json code.
> the affected packages are
> * 
> [org.apache.sling.commons.json|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json]
> * 
> [org.apache.sling.commons.json.http|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/http]
> * 
> [org.apache.sling.commons.json.io|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/io]
> * 
> [org.apache.sling.commons.json.util|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/util]
> * 
> [org.apache.sling.commons.json.xml|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/xml]
> unfortunately the unit test coverage for those packages is not very high. the 
> main package has a line coverage of 42%, the other packages less than that or 
> no at all.
> although we might encourage modules to switch to a standard JSON 
> implementation a lot of modules inside sling and perhaps much more outside 
> sling depend on this json implementation, so we should try to keep the 
> exported API and functionality.



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

[jira] [Updated] (SLING-6536) Deprecate JSON implementation derived from org.json code

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-6536:
--
Summary: Deprecate JSON implementation derived from org.json code  (was: 
Replace JSON implementation derived from org.json code)

> Deprecate JSON implementation derived from org.json code
> 
>
> Key: SLING-6536
> URL: https://issues.apache.org/jira/browse/SLING-6536
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.18
>Reporter: Stefan Seifert
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Commons JSON 2.1.0
>
>
> following the discussion in
> https://lists.apache.org/thread.html/ee51bace078681765d5dcfeda1939628ccefb9b4261b1d7f6a56d420@%3Cdev.sling.apache.org%3E
> we have to replace the implementation of all classes in Commons JSON that 
> were derived from the original org.json code.
> the affected packages are
> * 
> [org.apache.sling.commons.json|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json]
> * 
> [org.apache.sling.commons.json.http|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/http]
> * 
> [org.apache.sling.commons.json.io|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/io]
> * 
> [org.apache.sling.commons.json.util|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/util]
> * 
> [org.apache.sling.commons.json.xml|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/xml]
> unfortunately the unit test coverage for those packages is not very high. the 
> main package has a line coverage of 42%, the other packages less than that or 
> no at all.
> although we might encourage modules to switch to a standard JSON 
> implementation a lot of modules inside sling and perhaps much more outside 
> sling depend on this json implementation, so we should try to keep the 
> exported API and functionality.



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

Re: [VOTE] Apache Sling Karaf repoinit 0.2.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Mar 17, 2017 at 9:30 AM, Oliver Lietz  wrote:
> Hi,
>
> we solved 3 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338048
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1664/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1664 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>



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

Re: [VOTE] Apache Sling Scripting JSP 2.3.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Mar 17, 2017 at 11:23 AM, Oliver Lietz  wrote:
> Hi,
>
> we solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339340
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1667/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1667 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>



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

Re: [VOTE] Apache Sling Scripting JSP API Wrapper 1.0.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Mar 17, 2017 at 11:22 AM, Oliver Lietz  wrote:
> Hi,
>
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339658
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1665/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1665 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>



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

Re: [VOTE] Apache Sling Scripting EL API Wrapper 1.0.0

[Karl Pauls]

+1

regards,

Karl

On Fri, Mar 17, 2017 at 11:22 AM, Oliver Lietz  wrote:
> Hi,
>
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339659
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1666/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1666 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>



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

Re: [VOTE] Apache Sling Karaf repoinit 0.2.0

[Daniel Klco]

+1 - Checked signatures and build

On Fri, Mar 17, 2017 at 4:30 AM, Oliver Lietz  wrote:

> Hi,
>
> we solved 3 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338048
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1664/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1664 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>
>

[jira] [Assigned] (SLING-6519) Remove dependency to org.json

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-6519:
--

Assignee: Konrad Windszus

> Remove dependency to org.json
> -
>
> Key: SLING-6519
> URL: https://issues.apache.org/jira/browse/SLING-6519
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Carsten Ziegeler
>Assignee: Konrad Windszus
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Some IDE code is using org.json. We have to replace this. This is the list of 
> files using that code:
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONArray;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONException;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONObject;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONTokener;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONArray;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONObject;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONTokener;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONArray;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONObject;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java:import
>  org.json.JSONObject;



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

[jira] [Commented] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

Thanks for getting that resolved quickly!

> Allow multiple Exporter annotated models being used with the same 
> 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
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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] [Resolved] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6652.
---
Resolution: Fixed

Patch applied in r1787388.

Thanks for working this through!

> Allow multiple Exporter annotated models being used with the same 
> 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
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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 Exporter annotated models being used with the same resourceType binding

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Allow multiple Exporter annotated models being used with the same 
> 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
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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] [Assigned] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-6652:
-

Assignee: Justin Edelson

> Allow multiple Exporter annotated models being used with the same 
> 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
>Assignee: Justin Edelson
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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)

[GitHub] sling pull request #207: SLING-6652

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Resolved] (SLING-6658) Register models with their implType implicitly

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6658.
---
Resolution: Fixed

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[jira] [Updated] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6652:
--
Fix Version/s: Sling Models Impl 1.3.10

> Allow multiple Exporter annotated models being used with the same 
> 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
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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 Exporter annotated models being used with the same resourceType binding

[ASF GitHub Bot (JIRA)]

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

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

GitHub user Buuhuu opened a pull request:

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

SLING-6652



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

$ git pull https://github.com/Buuhuu/sling feature/SLING-6652-+-SLING-6658

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

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

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

This closes #207


commit ee46f4884373c434c614ce025b40f0a826045a3c
Author: Dirk Rudolph 
Date:   2017-03-17T07:47:45Z

SLING-6652:
 - applied justin’s patch

commit ec8564eaf6cda06e025607f885fe48617b28d8b6
Author: Dirk Rudolph 
Date:   2017-03-17T07:51:30Z

SLING-6658:
 - always reigster the model with its implType, even not specified as 
adapter explicitly

commit 53f22ad86012b9f83f3b4163b12853e54b3b4680
Author: Dirk Rudolph 
Date:   2017-03-17T13:18:17Z

Merge remote-tracking branch 'origin/feature/SLING-6658' into 
feature/SLING-6652-+-SLING-6658

commit 7d2b8250881804c77b6eb822126a75ab37b9e77f
Author: Dirk Rudolph 
Date:   2017-03-17T13:31:38Z

SLING-6652:
 - moved logic collection Exporter annotations out of the nested for loops.

commit 29a1c8d4cc60fe205219e35f64f5ab03f6356fd2
Author: Dirk Rudolph 
Date:   2017-03-17T13:32:31Z

SLING-6652:
 - instantiate accessor using concret implType instead of implicitly 
assuming the first of the adapterTypes should be taken

commit e32d4d617f9d5f1443d5969bd18904dc4fae1984
Author: Dirk Rudolph 
Date:   2017-03-17T13:49:05Z

Merge remote-tracking branch 'origin/trunk2' into 
feature/SLING-6652-+-SLING-6658

# Conflicts:
#   
bundles/extensions/models/integration-tests/src/main/java/org/apache/sling/models/it/ImplementsExtendsTest.java




> Allow multiple Exporter annotated models being used with the same 
> 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
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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)

[GitHub] sling pull request #207: SLING-6652

[Buuhuu]

GitHub user Buuhuu opened a pull request:

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

SLING-6652



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

$ git pull https://github.com/Buuhuu/sling feature/SLING-6652-+-SLING-6658

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

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

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

This closes #207


commit ee46f4884373c434c614ce025b40f0a826045a3c
Author: Dirk Rudolph 
Date:   2017-03-17T07:47:45Z

SLING-6652:
 - applied justin’s patch

commit ec8564eaf6cda06e025607f885fe48617b28d8b6
Author: Dirk Rudolph 
Date:   2017-03-17T07:51:30Z

SLING-6658:
 - always reigster the model with its implType, even not specified as 
adapter explicitly

commit 53f22ad86012b9f83f3b4163b12853e54b3b4680
Author: Dirk Rudolph 
Date:   2017-03-17T13:18:17Z

Merge remote-tracking branch 'origin/feature/SLING-6658' into 
feature/SLING-6652-+-SLING-6658

commit 7d2b8250881804c77b6eb822126a75ab37b9e77f
Author: Dirk Rudolph 
Date:   2017-03-17T13:31:38Z

SLING-6652:
 - moved logic collection Exporter annotations out of the nested for loops.

commit 29a1c8d4cc60fe205219e35f64f5ab03f6356fd2
Author: Dirk Rudolph 
Date:   2017-03-17T13:32:31Z

SLING-6652:
 - instantiate accessor using concret implType instead of implicitly 
assuming the first of the adapterTypes should be taken

commit e32d4d617f9d5f1443d5969bd18904dc4fae1984
Author: Dirk Rudolph 
Date:   2017-03-17T13:49:05Z

Merge remote-tracking branch 'origin/trunk2' into 
feature/SLING-6652-+-SLING-6658

# Conflicts:
#   
bundles/extensions/models/integration-tests/src/main/java/org/apache/sling/models/it/ImplementsExtendsTest.java




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

[GitHub] sling pull request #205: Feature/sling 6652 justin

[Buuhuu]

Github user Buuhuu closed the pull request at:

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


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

[jira] [Updated] (SLING-6658) Register models with their implType implicitly

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6658:

Attachment: models.mdtext.patch

Added a patch targeting the models documentation page.

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[jira] [Commented] (SLING-6658) Register models with their implType implicitly

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[GitHub] sling pull request #206: SLING-6658:

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (SLING-6658) Register models with their implType implicitly

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6658:
---

applied patch in r1787379. Thanks!

I also changed the class passed to 
{{adapterImplementations.registerModelToResourceType}} to be {{implType}} 
rather than getting the value back out of the array.

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[jira] [Updated] (SLING-6658) Register models with their implType implicitly

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6658:
--
Fix Version/s: Sling Models Impl 1.3.10

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[jira] [Assigned] (SLING-6658) Register models with their implType implicitly

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-6658:
-

Assignee: Justin Edelson

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[jira] [Commented] (SLING-6658) Register models with their implType implicitly

[ASF GitHub Bot (JIRA)]

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

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

GitHub user Buuhuu opened a pull request:

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

SLING-6658:

 - always reigster the model with its implType, even not specified as 
adapter explicitly

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

$ git pull https://github.com/Buuhuu/sling feature/SLING-6658

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

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

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

This closes #206


commit ec8564eaf6cda06e025607f885fe48617b28d8b6
Author: Dirk Rudolph 
Date:   2017-03-17T07:51:30Z

SLING-6658:
 - always reigster the model with its implType, even not specified as 
adapter explicitly




> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Priority: Minor
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



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

[GitHub] sling pull request #206: SLING-6658:

[Buuhuu]

GitHub user Buuhuu opened a pull request:

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

SLING-6658:

 - always reigster the model with its implType, even not specified as 
adapter explicitly

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

$ git pull https://github.com/Buuhuu/sling feature/SLING-6658

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

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

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

This closes #206


commit ec8564eaf6cda06e025607f885fe48617b28d8b6
Author: Dirk Rudolph 
Date:   2017-03-17T07:51:30Z

SLING-6658:
 - always reigster the model with its implType, even not specified as 
adapter explicitly




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

[jira] [Commented] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

Done: SLING-6658. Will create a PR for that as well, removing the overhead here.

> Allow multiple Exporter annotated models being used with the same 
> 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
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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-6658) Register models with their implType implicitly

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6658:
---

 Summary: Register models with their implType implicitly
 Key: SLING-6658
 URL: https://issues.apache.org/jira/browse/SLING-6658
 Project: Sling
  Issue Type: Improvement
Reporter: Dirk Rudolph
Priority: Minor


As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
introduced a undocumented assumption of the order of the adapterTypes. 

This ticket is about always registering any {{@Model}} implicitly with its 
{{implType}}, if not specified explicitly. This will allow the ExportServlet to 
always use the {{implType}} while creating the {{@Model}} its going to export.  



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

[jira] [Resolved] (SLING-6464) Update options and versions to latest features

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6464.
-
Resolution: Done

> Update options and versions to latest features
> --
>
> Key: SLING-6464
> URL: https://issues.apache.org/jira/browse/SLING-6464
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing PaxExam 0.0.4
>
>




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

[jira] [Resolved] (SLING-6653) Make slingLaunchpadOak() private

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6653.
-
Resolution: Won't Do

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



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

[jira] [Commented] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

I'm good with adding {{implType}} to the {{adapterType}} list. But I think that 
change should be explicitly listed. Please create a separate JIRA for it.

> Allow multiple Exporter annotated models being used with the same 
> 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
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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] [Comment Edited] (SLING-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6652 at 3/17/17 12:40 PM:
---

Change the title and description to better express, what this ticket is about.


was (Author: diru):
Change the title better express, what this ticket is about.

> Allow multiple Exporter annotated models being used with the same 
> 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
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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-6652) Allow multiple Exporter annotated models being used with the same resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6652:

Description: 
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. 
This mechanism is used in the ExportServlet to get the Object form either 
{{SlingHttpServletRequest}} or {{Resource}}. 

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. 

  was:
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. 

Summary: Allow multiple Exporter annotated models being used with the 
same resourceType binding  (was: Allow multiple adapters for Models with 
resourceType binding)

Change the title better express, what this ticket is about.

> Allow multiple Exporter annotated models being used with the same 
> 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
> Attachments: SLING-6652.diff
>
>
> 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. 
> This mechanism is used in the ExportServlet to get the Object form either 
> {{SlingHttpServletRequest}} or {{Resource}}. 
> 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-6536) Replace JSON implementation derived from org.json code

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6536:


Compare with the discussion at 
http://www.mail-archive.com/dev@sling.apache.org/msg65534.html. Outcome was to 
deprecate the full API and then no longer maintain this module. All consumers 
have to use a different JSON library.

> Replace JSON implementation derived from org.json code
> --
>
> Key: SLING-6536
> URL: https://issues.apache.org/jira/browse/SLING-6536
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons JSON 2.0.18
>Reporter: Stefan Seifert
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Commons JSON 2.1.0
>
>
> following the discussion in
> https://lists.apache.org/thread.html/ee51bace078681765d5dcfeda1939628ccefb9b4261b1d7f6a56d420@%3Cdev.sling.apache.org%3E
> we have to replace the implementation of all classes in Commons JSON that 
> were derived from the original org.json code.
> the affected packages are
> * 
> [org.apache.sling.commons.json|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json]
> * 
> [org.apache.sling.commons.json.http|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/http]
> * 
> [org.apache.sling.commons.json.io|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/io]
> * 
> [org.apache.sling.commons.json.util|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/util]
> * 
> [org.apache.sling.commons.json.xml|https://github.com/apache/sling/tree/trunk/bundles/commons/json/src/main/java/org/apache/sling/commons/json/xml]
> unfortunately the unit test coverage for those packages is not very high. the 
> main package has a line coverage of 42%, the other packages less than that or 
> no at all.
> although we might encourage modules to switch to a standard JSON 
> implementation a lot of modules inside sling and perhaps much more outside 
> sling depend on this json implementation, so we should try to keep the 
> exported API and functionality.



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

Dirk Rudolph commented on SLING-6652:
-

Its indeed explained in 
https://issues.apache.org/jira/browse/SLING-3886?focusedCommentId=14112711=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14112711.
 The only concern I have is that we implicitly expect the {{adapterType}}s 
being sorted in a certain way, which - I'm not sure - might not be clear to 
those developers using it. 

Having said that, [~sseif...@pro-vision.de] didn't had a problem making 
{{implType}} always part of the {{adapterType}}s. So +1 for that, wdyt?



> 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
> Attachments: SLING-6652.diff
>
>
> 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] [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=15929890#comment-15929890
 ] 

Dirk Rudolph edited comment on SLING-6652 at 3/17/17 12:32 PM:
---

Its indeed explained in 
https://issues.apache.org/jira/browse/SLING-3886?focusedCommentId=14112711=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14112711.
 The only concern I have is that we implicitly expect the {{adapterType}} s 
being sorted in a certain way, which - I'm not sure - might not be clear to 
those developers using it. 

Having said that, [~sseif...@pro-vision.de] didn't had a problem making 
{{implType}} always part of the {{adapterType}}s. So +1 for that, wdyt?




was (Author: diru):
Its indeed explained in 
https://issues.apache.org/jira/browse/SLING-3886?focusedCommentId=14112711=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14112711.
 The only concern I have is that we implicitly expect the {{adapterType}}s 
being sorted in a certain way, which - I'm not sure - might not be clear to 
those developers using it. 

Having said that, [~sseif...@pro-vision.de] didn't had a problem making 
{{implType}} always part of the {{adapterType}}s. So +1 for that, wdyt?



> 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
> Attachments: SLING-6652.diff
>
>
> 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)

Re: Package Manager should be whitelisted for Composum

[Robert Munteanu]

Hi,

On Thu, 2017-03-16 at 13:31 -0700, Andreas Schaefer wrote:
> Hi
> 
> Shouldn’t the package ‘com.composum.core.pckgmgr’ being added to the
> Apache Sling Login Admin Whitelist Configuration Fragment for
> ‘composum’?
> 
> As of now packages cannot be fully handled in composum without
> whitelisting it manually.

Sounds like an oversight. Can you please file a Jira, ideally with a
patch attached ;-) ?

Robert

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

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

I'm not sure it matters which {{adapterType}} is used in the 
{{ExporterServlet}}. Under what circumstance would it make any difference?

bq. register each @Model having @Exporter set implicitly with its implType as 
adapterType, if not already present there.

I think if we are going to do this, we should do it consistently -- the 
{{implType}} should always be one of the {{adapterType}}s. That said, I believe 
there was some intentionality behind the choice originally to not always 
include the {{implType}} in the {{adapterType}}s list. Please check on the dev 
list or JIRA for the history.

> 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
> Attachments: SLING-6652.diff
>
>
> 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-6657) Support configuring the dependency checks

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6657:
--

 Summary: Support configuring the dependency checks
 Key: SLING-6657
 URL: https://issues.apache.org/jira/browse/SLING-6657
 Project: Sling
  Issue Type: Improvement
  Components: Installer
Affects Versions: Installer Packages Factory 1.0.0
Reporter: Konrad Windszus


With https://issues.apache.org/jira/browse/JCRVLT-136 a more sophisticated 
approach on how to deal with dependencies has been introduced. It would be good 
to leverage that and make it configurable through OSGi properties (globally).



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

[jira] [Updated] (SLING-6657) Support configuring the dependency checks

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6657:
---
Fix Version/s: Installer Packages Factory 1.0.0

> Support configuring the dependency checks
> -
>
> Key: SLING-6657
> URL: https://issues.apache.org/jira/browse/SLING-6657
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Packages Factory 1.0.0
>Reporter: Konrad Windszus
> Fix For: Installer Packages Factory 1.0.0
>
>
> With https://issues.apache.org/jira/browse/JCRVLT-136 a more sophisticated 
> approach on how to deal with dependencies has been introduced. It would be 
> good to leverage that and make it configurable through OSGi properties 
> (globally).



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

[jira] [Commented] (SLING-5948) Support Streaming uploads.

[ASF GitHub Bot (JIRA)]

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

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

Github user ieb closed the pull request at:

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


> Support Streaming uploads.
> --
>
> Key: SLING-5948
> URL: https://issues.apache.org/jira/browse/SLING-5948
> Project: Sling
>  Issue Type: Bug
>  Components: Engine, Servlets
>Affects Versions: Servlets Post 2.3.12, Engine 2.5.0
>Reporter: Ian Boston
>Assignee: Ian Boston
>  Labels: Sling-9-ReleaseNotes
> Fix For: Servlets Post 2.3.14, Engine 2.6.0
>
> Attachments: SLING-5948-Proposal1-illustration.patch, 
> SLING-5948-Proposal2v2.patch, SLING-5948-Proposal2v3.patch, 
> TarMKDSNotStreamed.png, TarMKDSStreamed.png, TarMKStreamed.png
>
>
> Currently multipart POST request made to sling use the commons file upload 
> component that parses the request fully before processing. If uploads are 
> small they are stored in byte[], over a configurable limit they are sent to 
> disk. This creates additional IO overhead, increases heap usage and increases 
> upload time.
> Having searched the SLing jira, and sling-dev I have failed to find an issue 
> relating to this area, although it has been discussed in the past.
> I have 2 proposals.
> The SlingMain Servlet processes all requests, identifying the request type 
> and parsing the request body. If the body is multipart the Commons File 
> Upload library is used to process the request body in full when the 
> SlingServletRequest is created or the first parameter is requested. To enable 
> streaming of a request this behaviour needs to be modified. Unfortunately, 
> processing a streamed request requires that the ultimate processor requests 
> multipar parts in a the correct order to avoid non streaming, so a streaming 
> behaviour will not be suitable for most POST requests and can only be used if 
> the ultimate Servlet has been written to process a stream rather than a map 
> of parameters.
> Both proposals need to identify requests that should be processed as a 
> stream. This identification must happen in the headers or URI as any 
> identification later than the headers may be too late. Something like a 
> custom header (x-uploadmode: stream) or a query string (?uploadmode=stream) 
> or possibly a selector (/path/to/target.stream) would work and each have 
> advantages and disadvantages.
> h1. Proposal 1
> When a POST request is identified as multipart and streaming, create a 
> LazyParameterMap that uses the Commons File Upload Streaming API 
> (https://commons.apache.org/proper/commons-fileupload/streaming.html) to 
> process the request on demand as parameters are requested. If parameters are 
> requested out of sequence, do something sensible attempting to maintain 
> streaming behaviour, but if the code really breaks streaming, throw an 
> exception to alert servlet developer early.
> h2. Pros
> * Follows a similar pattern to currently using the Servlet API.
> h2. Cons
> * [] params will be hard to support when the [] is out of order, and almost 
> impossible if the [] is an upload body.
> * May not work when a request is routed incorrectly as getParameter requests 
> will be out of streaming sequence.
> h2. Proposal 2
> When a POST request is identified as multipart and streaming, create a 
> NullParameterMap that returns null for all parameter get operations. In 
> addition set a request Attribute containing a Iterator that allows 
> access to the request stream in a similar way to the Commons File Upload 
> Streaming API.  Servlets that process uploads streams will use the 
> Iterator object retrieved from the request. Part is the Servlet 3 Part 
> https://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/Part.html.
>  IIUC This API is already used in the Sling Engine and exported by a bundle.
> h2. Pros
> * Won't get broken by existing getParameter calls, which all return null and 
> do no harm to the stream.
> * Far simpler implementation as the Servlet implementation has to get the 
> request data in streaming order.
> h2. Cons
> * Needs a custom Sling Upload Operation that understand how to process the 
> Iterator
> * Can't use the adaptTo mechanism on the request, as 
> request.adaptTo(Iterator.class) doesn't make sense being too generic. Would 
> need a new API to make this work. request.adaptTo(PartsIterator.class), which 
> PartsIterator extends Iterator.
> * Supporting the full breadth of the Sling Operation protocol in the Sling 
> Upload Operation will require wide scale duplication of code from the 
> ModifyOperation implementation as the ModifyOperation expects RequestProperty 
> maps and wont work with a streamed part.
> * Forces the Sling Post bundle to 

[GitHub] sling pull request #161: SLING-5948 Support Streaming.

[ieb]

Github user ieb closed the pull request at:

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


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

Re: [VOTE] Apache Sling Scripting JSP 2.3.0

[Ian Boston]

+1
Ian

On 17 March 2017 at 10:23, Oliver Lietz  wrote:

> Hi,
>
> we solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339340
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1667/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1667 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>
>

Re: [VOTE] Apache Sling Scripting EL API Wrapper 1.0.0

[Ian Boston]

+1
Ian

On 17 March 2017 at 10:22, Oliver Lietz  wrote:

> Hi,
>
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339659
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1666/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1666 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>
>

Re: [VOTE] Apache Sling Scripting JSP API Wrapper 1.0.0

[Ian Boston]

+1
Ian

On 17 March 2017 at 10:22, Oliver Lietz  wrote:

> Hi,
>
> we solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339658
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1665/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1665 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards,
> O.
>
>

[VOTE] Apache Sling Scripting JSP 2.3.0

[Oliver Lietz]

Hi,

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

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1667 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[VOTE] Apache Sling Scripting EL API Wrapper 1.0.0

[Oliver Lietz]

Hi,

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

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1666 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

[VOTE] Apache Sling Scripting JSP API Wrapper 1.0.0

[Oliver Lietz]

Hi,

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

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1665 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz reopened SLING-5980:
-

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



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

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-5980.
-
Resolution: Fixed

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



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

[jira] [Updated] (SLING-6549) Provide bundle wrapping Apache Tomcat 6.0.14 EL API

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6549:

Description: 
-fragment for {{javax.el}} (EL API)-

{{org.apache.sling.scripting.el-api}}: This bundle wraps the Apache Tomcat 
6.0.14 EL API used by Apache Sling Scripting JSP.

  was:fragment for {{javax.el}} (EL API)


> Provide bundle wrapping Apache Tomcat 6.0.14 EL API
> ---
>
> Key: SLING-6549
> URL: https://issues.apache.org/jira/browse/SLING-6549
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting EL API Wrapper 1.0.0
>
>
> -fragment for {{javax.el}} (EL API)-
> {{org.apache.sling.scripting.el-api}}: This bundle wraps the Apache Tomcat 
> 6.0.14 EL API used by Apache Sling Scripting JSP.



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

[jira] [Comment Edited] (SLING-6549) Provide bundle wrapping Apache Tomcat 6.0.14 EL API

[Oliver Lietz (JIRA)]

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

Oliver Lietz edited comment on SLING-6549 at 3/17/17 9:34 AM:
--

[r1786401|https://svn.apache.org/r1786401]
[r1787237|https://svn.apache.org/r1787237]
[r1787240|https://svn.apache.org/r1787240]


was (Author: olli):
[r1786401|https://svn.apache.org/r1786401]

> Provide bundle wrapping Apache Tomcat 6.0.14 EL API
> ---
>
> Key: SLING-6549
> URL: https://issues.apache.org/jira/browse/SLING-6549
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting EL API Wrapper 1.0.0
>
>
> fragment for {{javax.el}} (EL API)



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

[jira] [Updated] (SLING-6548) Provide bundle wrapping Apache Tomcat 6.0.14 JSP API

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6548:

Description: 
-fragment for {{javax.servlet.jsp}} (Servlet JSP API)-

{{org.apache.sling.scripting.jsp-api}}: This bundle wraps the Apache Tomcat 
6.0.14 JSP API used by Apache Sling Scripting JSP.

  was:fragment for {{javax.servlet.jsp}} (Servlet JSP API)


> Provide bundle wrapping Apache Tomcat 6.0.14 JSP API
> 
>
> Key: SLING-6548
> URL: https://issues.apache.org/jira/browse/SLING-6548
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JSP API Wrapper 1.0.0
>
>
> -fragment for {{javax.servlet.jsp}} (Servlet JSP API)-
> {{org.apache.sling.scripting.jsp-api}}: This bundle wraps the Apache Tomcat 
> 6.0.14 JSP API used by Apache Sling Scripting JSP.



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

[jira] [Comment Edited] (SLING-6548) Provide bundle wrapping Apache Tomcat 6.0.14 JSP API

[Oliver Lietz (JIRA)]

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

Oliver Lietz edited comment on SLING-6548 at 3/17/17 9:31 AM:
--

[r1786399|https://svn.apache.org/r1786399]
[r1787236|https://svn.apache.org/r1787236]
[r1787239|https://svn.apache.org/r1787239]


was (Author: olli):
[r1786399|https://svn.apache.org/r1786399]

> Provide bundle wrapping Apache Tomcat 6.0.14 JSP API
> 
>
> Key: SLING-6548
> URL: https://issues.apache.org/jira/browse/SLING-6548
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JSP API Wrapper 1.0.0
>
>
> fragment for {{javax.servlet.jsp}} (Servlet JSP API)



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

[VOTE] Apache Sling Karaf repoinit 0.2.0

[Oliver Lietz]

Hi,

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

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

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1664 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
O.

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

Dirk Rudolph edited comment on SLING-6655 at 3/17/17 8:08 AM:
--

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 {{Object createModel(resource, Object.class)}} if the models 
itself are registered with {{adapater = Object.class}}, or even better using a 
marker interface and having *2* in place to pick the right implementation. This 
would better fit the semantics of the ModelFactory's purpose. Wdyt? Though the 
"caching" currently done in {{AdapterImplementations}} would need to somehow be 
handled by the {{ImplementationPicker}} then. 


was (Author: diru):
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 and having *2* in place to pick the right implementation. This would 
better fit the semantics of the ModelFactory's purpose. Wdyt? Though the 
"caching" currently done in {{AdapterImplementations}} would need to somehow be 
handled by the {{ImplementationPicker}} 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=15929562#comment-15929562
 ] 

Dirk Rudolph commented on SLING-6652:
-

I applied my proposal on top of [~justinedelson]'s patch in the newly linked PR 
and I can confirm this works as expected for my project.

> 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
> Attachments: SLING-6652.diff
>
>
> 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)

[GitHub] sling pull request #205: Feature/sling 6652 justin

[Buuhuu]

GitHub user Buuhuu opened a pull request:

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

Feature/sling 6652 justin

Same as #204 but only targeting the exporter, not changing the semantics 
and interface of ModelFactory. 

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

$ git pull https://github.com/Buuhuu/sling feature/SLING-6652-justin

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

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

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

This closes #205


commit ee46f4884373c434c614ce025b40f0a826045a3c
Author: Dirk Rudolph 
Date:   2017-03-17T07:47:45Z

SLING-6652:
 - applied justin’s patch

commit 0bb6f57d1affb0807ad42e1670a966714af1a2c1
Author: Dirk Rudolph 
Date:   2017-03-17T07:51:30Z

SLING-6652:
 - implicitly register @Models having at least one @Exporter for the 
implType

commit d9ddd332886249d11174fc8e1abdd1a089ba87c2
Author: Dirk Rudolph 
Date:   2017-03-17T07:52:55Z

SLING-6652:
 - fixed formatting




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

[GitHub] sling pull request #204: Feature/sling 6652

[Buuhuu]

Github user Buuhuu closed the pull request at:

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


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

[jira] [Commented] (SLING-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=15929541#comment-15929541
 ] 

Dirk Rudolph commented on SLING-6652:
-

Thanks for the patch, that definitively make sense, but there is one point I 
want to highlight again. In 

ModelPackageBundleListener l162 and l164 you still implicitly require the first 
{{adapterType}} to be the relevant one for the {{ExportServlet}} which isn't 
always true, so

* we can either document that somewhere
* or register each {{@Model}} having {{@Exporter}} set implicitly with its 
{{implType}} as {{adapterType}}, if not already present there.

I prefer the second option because,

* users of {{@Model#adapters}} have not yet been aware of the adapter's order 
being relevant
* there is anyway a strong 1:1 relation between the {{@Exporter}} and the class 
annotated with it
* the documentation would belong to {{@Model#adapters}}, which would cross 
reference unimported {{@Exporter}} then

Maybe it also makes sense to register each {{@Model}} with its {{implType}} 
implicitly, if not explicitly given, wdyt?

> 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
> Attachments: SLING-6652.diff
>
>
> 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] [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=15929516#comment-15929516
 ] 

Dirk Rudolph edited comment on SLING-6655 at 3/17/17 7:19 AM:
--

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 and having *2* in place to pick the right implementation. This would 
better fit the semantics of the ModelFactory's purpose. Wdyt? Though the 
"caching" currently done in {{AdapterImplementations}} would need to somehow be 
handled by the {{ImplementationPicker}} then. 


was (Author: diru):
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)

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