[jira] [Resolved] (SLING-6948) HttpServletResponse.getOutput() and getOutputAsString() return different information

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6948.
---
   Resolution: Fixed
 Assignee: Stefan Seifert
Fix Version/s: Servlet Helpers 1.0.2
   Servlet Helpers 1.1.2

Completed: At revision: 1798871  (1.1.x)
Completed: At revision: 1798872  (1.0.x)

> HttpServletResponse.getOutput() and getOutputAsString() return different 
> information
> 
>
> Key: SLING-6948
> URL: https://issues.apache.org/jira/browse/SLING-6948
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Servlet Helpers 1.1.0
>Reporter: Robert Munteanu
>Assignee: Stefan Seifert
> Fix For: Servlet Helpers 1.1.2, Servlet Helpers 1.0.2
>
>
> HttpServletResponse.getOutput and getOutputAsString are backed by 
> ResponseBodySupport. That class holds both a ServletOutputStream and a 
> PrintWriter, which are not kept in sync. getOutput uses the 
> ServletOutputStream and getOutputAsString uses the PrintWriter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6948) HttpServletResponse.getOutput() and getOutputAsString() return different information

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6948:
--
Summary: HttpServletResponse.getOutput() and getOutputAsString() return 
different information  (was: HttpServletResponse.getOutput() and 
getOutputAsStream() return different information)

> HttpServletResponse.getOutput() and getOutputAsString() return different 
> information
> 
>
> Key: SLING-6948
> URL: https://issues.apache.org/jira/browse/SLING-6948
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Servlet Helpers 1.1.0
>Reporter: Robert Munteanu
>
> HttpServletResponse.getOutput and getOutputAsString are backed by 
> ResponseBodySupport. That class holds both a ServletOutputStream and a 
> PrintWriter, which are not kept in sync. getOutput uses the 
> ServletOutputStream and getOutputAsString uses the PrintWriter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: FYI, working on moving to JBake for the Sling website

[Bertrand Delacretaz]

On Thu, Jun 15, 2017 at 7:07 AM, Carsten Ziegeler  wrote:
> ...what are the problems this will solve and what
> are the benefits? So far I've not heard of JBake at all

Some of that has been discussed at SLING-6955.

The main problem is the Apache CMS not being developed anymore,
INFRA-13644 for example took a long time to solve.

A publishing process that runs locally is much more convenient to use,
and can help getting more website contributions - also because we'd be
using a more usual publishing process.

There are many website generators similar to JBake, I selected it as
several other Apache projects are using it and it's written in Java,
so more hackable/fixable by us if needed.

-Bertrand

Re: [VOTE] Release Apache Sling Testing Clients 1.1.4, Apache Sling Testing Email Support 1.0.0

[Robert Munteanu]

On Thu, 2017-06-15 at 19:21 +0300, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[VOTE] Release Apache Sling Testing Clients 1.1.4, Apache Sling Testing Email Support 1.0.0

[Robert Munteanu]

Hi,

We solved 2 issues in these release:
https://issues.apache.org/jira/projects/SLING/versions/12340947
https://issues.apache.org/jira/projects/SLING/versions/12340957

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

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 1744 /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] [Updated] (SLING-6954) Add client support for the org.apache.sling.testing.email bundle

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6954:
---
Fix Version/s: (was: Apache Sling Testing Clients 1.1.2)
   Apache Sling Testing Clients 1.1.4

> Add client support for the org.apache.sling.testing.email bundle
> 
>
> Key: SLING-6954
> URL: https://issues.apache.org/jira/browse/SLING-6954
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Apache Sling Testing Clients 1.1.4
>
>
> With the features added in SLING-6949 it makes sense to add a thin 
> client-side layer to make this simpler to use.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6964) SlingEmailClient does not allow accessing email headers

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6964.

Resolution: Fixed

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

> SlingEmailClient does not allow accessing email headers
> ---
>
> Key: SLING-6964
> URL: https://issues.apache.org/jira/browse/SLING-6964
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Apache Sling Testing Clients 1.1.4
>
>
> Due to a major oversight, only the email bodies are available, not the email 
> headers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6963) Service user declaration based on principal names

[angela (JIRA)]

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

angela commented on SLING-6963:
---

[~fmeschbe]: addressed the guava and the return value finding the 
https://github.com/anchela/sling/commit/a06b53733098ed1ab966be5a44e3429fded982cc
regarding the third: there were 2 minor version bumps in the 
service-user-mapper bundle before already (and i am not familiar with those 
changes)... i leave that up to the sling team to deal with those changes and 
how they want to incorporate the new extensions in the jcr.base bundle.

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6963) Service user declaration based on principal names

[angela (JIRA)]

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

angela commented on SLING-6963:
---

[~cziegeler], already got rid of it at  
https://github.com/anchela/sling/commit/a06b53733098ed1ab966be5a44e3429fded982cc

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6963) Service user declaration based on principal names

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6963:
--

Thanks, [~anchela]. I quickly reviewed the patch. Basically I like this idea 
very much.

There are a few comments, though:

* As [~cziegeler] indicated, please refrain from adding the Guava library as a 
dependency to the ServiceUserMapper (unfortunately, this seems to already have 
been made in the jcr.base bundle :-(
* There is a change in semantics in an internal/private method. While it has no 
consequences, I would prefer to not have it (see respective two comments on the 
isValidUser and areValidPrincipals methods)
* I would prefer to not enforce an increased version dependency on the 
ServiceUserMapper service in the jcr.base bundle. Rather I would suggest to 
keep the dependency low and check whether the getServicePrincipalNames method 
is available on the ServiceUserMapper service bound.

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6940) JSPC plugin violates Maven naming convention

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on SLING-6940:
-

new maven coordinates:

{noformat}
org.apache.sling
jspc-maven-plugin
2.1.0
{noformat}


> JSPC plugin violates Maven naming convention
> 
>
> Key: SLING-6940
> URL: https://issues.apache.org/jira/browse/SLING-6940
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
> Fix For: Maven JSPC Plugin 2.1.0
>
>
> the current plugin name {{maven-jspc-plugin}} violates the maven plugin 
> convention, as it starts with "maven-":
> {noformat}
> [INFO] --- maven-plugin-plugin:3.4:helpmojo (help-goal) @ maven-jspc-plugin 
> ---
> [ERROR]
> Artifact Ids of the format maven-___-plugin are reserved for
> plugins in the Group Id org.apache.maven.plugins
> Please change your artifactId to the format ___-maven-plugin
> In the future this error will break the build.
> {noformat}
> Suggest to rename it to: {{sling-jspc-maven-plugin}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6964) SlingEmailClient does not allow accessing email headers

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6964:
--

 Summary: SlingEmailClient does not allow accessing email headers
 Key: SLING-6964
 URL: https://issues.apache.org/jira/browse/SLING-6964
 Project: Sling
  Issue Type: Bug
  Components: Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Apache Sling Testing Clients 1.1.4


Due to a major oversight, only the email bodies are available, not the email 
headers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE] [CANCELLED] Release Apache Sling Testing Clients 1.1.2, Apache Sling Testing Email Support 1.0.0

[Robert Munteanu]

I realized I left out some important functionality in testing clients
1.1.2 and rather than wait 72 hours for a new release I'm cancelling
this one and will re-roll a new release shortly.

Robert

Re: Use only releases on the launchpad

[Carsten Ziegeler]

+1 for switching now and don't allow snapshots in launchpad anymore.

Carsten

Robert Munteanu wrote
> Hi,
> 
> Right after the release is a good time to restart the discussion about
> only using releases in the Sling launchpad.
> 
> https://cwiki.apache.org/confluence/display/SLING/Moving+the+Sling+Laun
> chpad+to+use+released+artifacts+only
> 
> At the moment we're minimally missing some tooling to make sure that we
> can switch to the latest SNAPSHOTS in an existing launchpad so we can
> run the tests against unreleased bundles. We have [1] but it's not
> reliable yet.
> 
> So 
> 
> 1) does anyone think this is not a good time to start the switch?
> 2) who would like to try their hand and updating the tooling to switch
> the launchpad to SNAPSHOT versions?
> 
> Thanks,
> 
> Robert
> 
> 
> [1]:
> https://svn.apache.org/repos/asf/sling/trunk/launchpad/builder/set-
> sling-snapshots.sh
> 


 

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

Use only releases on the launchpad

[Robert Munteanu]

Hi,

Right after the release is a good time to restart the discussion about
only using releases in the Sling launchpad.

https://cwiki.apache.org/confluence/display/SLING/Moving+the+Sling+Laun
chpad+to+use+released+artifacts+only

At the moment we're minimally missing some tooling to make sure that we
can switch to the latest SNAPSHOTS in an existing launchpad so we can
run the tests against unreleased bundles. We have [1] but it's not
reliable yet.

So 

1) does anyone think this is not a good time to start the switch?
2) who would like to try their hand and updating the tooling to switch
the launchpad to SNAPSHOT versions?

Thanks,

Robert


[1]:
https://svn.apache.org/repos/asf/sling/trunk/launchpad/builder/set-
sling-snapshots.sh

[jira] [Commented] (SLING-6963) Service user declaration based on principal names

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6963:
-

Thanks [~anchela] , I didn't have time for looking into the issue itself, but I 
noticed that you're introducing the guava library. We should avoid using this 
in Sling, especially as only some utility functions are used from it. So 
instead of adding a dependency to a rather huge library, either adding some 
lines of code doing the same or looking into commons collections 4 which we 
introduce is better.

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Testing Clients 1.1.2, Apache Sling Testing Email Support 1.0.0

[Robert Munteanu]

On Thu, 2017-06-15 at 16:27 +0300, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[VOTE] Release Apache Sling Testing Clients 1.1.2, Apache Sling Testing Email Support 1.0.0

[Robert Munteanu]

Hi,

We solved 2 issues in these release:
https://issues.apache.org/jira/projects/SLING/versions/12340947
https://issues.apache.org/jira/projects/SLING/versions/12340955

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

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 1743 /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] [Updated] (SLING-6954) Add client support for the org.apache.sling.testing.email bundle

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6954:
---
Fix Version/s: (was: Apache Sling Testing Clients 1.1.0)
   Apache Sling Testing Clients 1.1.2

> Add client support for the org.apache.sling.testing.email bundle
> 
>
> Key: SLING-6954
> URL: https://issues.apache.org/jira/browse/SLING-6954
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Apache Sling Testing Clients 1.1.2
>
>
> With the features added in SLING-6949 it makes sense to add a thin 
> client-side layer to make this simpler to use.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6940) JSPC plugin violates Maven naming convention

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-6940.
---

> JSPC plugin violates Maven naming convention
> 
>
> Key: SLING-6940
> URL: https://issues.apache.org/jira/browse/SLING-6940
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
> Fix For: Maven JSPC Plugin 2.1.0
>
>
> the current plugin name {{maven-jspc-plugin}} violates the maven plugin 
> convention, as it starts with "maven-":
> {noformat}
> [INFO] --- maven-plugin-plugin:3.4:helpmojo (help-goal) @ maven-jspc-plugin 
> ---
> [ERROR]
> Artifact Ids of the format maven-___-plugin are reserved for
> plugins in the Group Id org.apache.maven.plugins
> Please change your artifactId to the format ___-maven-plugin
> In the future this error will break the build.
> {noformat}
> Suggest to rename it to: {{sling-jspc-maven-plugin}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6923) Update JSPC plugin to support java 1.8

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-6923.
---

> Update JSPC plugin to support java 1.8
> --
>
> Key: SLING-6923
> URL: https://issues.apache.org/jira/browse/SLING-6923
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
> Fix For: Maven JSPC Plugin 2.1.0
>
>
> The current 2.0.8 version of the JSPC plugin only supports java version 1.6.
> task:
> - update code of JSPC plugin to also support 1.7 and 1.8
> - use latest org.apache.sling.scripting.jsp:2.3.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE RESULT] Release JSPC Maven Plugin 2.1.0

[Carsten Ziegeler]

The vote passes with four binding +1 votes

Thanks

Carsten

 

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

[jira] [Closed] (SLING-6925) Make JSPC plugin useful to validation and analysis

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-6925.
---

> Make JSPC plugin useful to validation and analysis
> --
>
> Key: SLING-6925
> URL: https://issues.apache.org/jira/browse/SLING-6925
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Maven JSPC Plugin 2.1.0
>
>
> the JSPs plugin is very useful to validate the JSPs before they get packaged 
> into the artifact. --but the deployment unit might not need to class files 
> but there is currently no way to disable their attachment--. further it might 
> be valuable to know which dependencies in the project are really used by the 
> JSPs. this helps developers to optimize the runtime dependencies of their 
> code.
> suggest:
> - --add new flag: {{attachClasses}} (default true)--
> - analyze the java packages of the class path used to compile the JSPs and 
> report which dependencies are not used.
> - add new flag: {{reportUnusedDependencies}} (default true)
> - add new flag: {{dumpClassPathUsage}} (default false)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[RESULT][VOTE] Release Apache Sling Slingstart Archetype version 1.0.2

[Robert Munteanu]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Daniel Klco, Robert Munteanu, Carsten
Ziegeler

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

[jira] [Updated] (SLING-6963) Service user declaration based on principal names

[angela (JIRA)]

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

angela updated SLING-6963:
--
Summary: Service user declaration based on principal names  (was: Service 
user declaration based on a set of principal names)

> Service user declaration based on principal names
> -
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6963) Service user declaration based on a set of principal names

[angela (JIRA)]

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

angela commented on SLING-6963:
---

[~asanso], [~cziegeler], [~fmeschbe], [~rombert] may I kindly ask you to review 
the initial proposal at 
https://github.com/anchela/sling/commit/2fda606c89ad735507599d8d8926a58ae3178ea7
 
? I didn't invest a lot of time writing full test coverage but will do as soon 
as I know if the overall direction of the improvement has a chance to make it 
into Sling.

Please also note that building _org.apache.sling.jcr.base_ fails when updating 
to a more recent version of the serviceusermapper bundle. But as far as I could 
see this is not related to my changes (see also SLING-6957).

> Service user declaration based on a set of principal names
> --
>
> Key: SLING-6963
> URL: https://issues.apache.org/jira/browse/SLING-6963
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Service User Mapper
>Reporter: angela
>
> Currently {{SlingRepository.loginService}} relies on a configuration that 
> maps services/subservices to a single service user by it's name/ID. Heavy 
> usage of this concept over the last years has reveal a couple of findings, we 
> missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for 
> individual service users that often share common needs while at the same time 
> being responsible for completing distinct special operations (e.g. 
> _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by 
> existing groups and we ended up having service users being put into groups in 
> order to avoid permission duplication (ultimately leaving us with somewhat 
> intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of 
> registering service users that would allow for specifying a set of principal 
> names, effectively declaring all tasks a given service is designed to 
> complete. this would allow to re-use existing service users and thus avoid 
> duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the 
> double repository login as it is currently present within 
> {{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
> impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-5085) Create a Dockerfile for the Sling Launchpad

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-5085.

   Resolution: Fixed
Fix Version/s: Launchpad Builder 8

> Create a Dockerfile for the Sling Launchpad
> ---
>
> Key: SLING-5085
> URL: https://issues.apache.org/jira/browse/SLING-5085
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Builder 8
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6963) Service user declaration based on a set of principal names

[angela (JIRA)]

angela created SLING-6963:
-

 Summary: Service user declaration based on a set of principal names
 Key: SLING-6963
 URL: https://issues.apache.org/jira/browse/SLING-6963
 Project: Sling
  Issue Type: Improvement
  Components: JCR, Service User Mapper
Reporter: angela


Currently {{SlingRepository.loginService}} relies on a configuration that maps 
services/subservices to a single service user by it's name/ID. Heavy usage of 
this concept over the last years has reveal a couple of findings, we missed 
when inventing the service user concept:

- it is prone to redundant of permission setup when defining permissions for 
individual service users that often share common needs while at the same time 
being responsible for completing distinct special operations (e.g. 
_read-content_ (common) and _write-special-subtree_ (special operation)
- some services require a combination of different operations reflected by 
existing groups and we ended up having service users being put into groups in 
order to avoid permission duplication (ultimately leaving us with somewhat 
intransparent permission setup for a given service).

Learning from these findings I like would proposed an alternative way of 
registering service users that would allow for specifying a set of principal 
names, effectively declaring all tasks a given service is designed to complete. 
this would allow to re-use existing service users and thus avoid duplication of 
permission setup for both cases mentioned above.

Also, implementing this alternative mapping would allow to get rid of the 
double repository login as it is currently present within 
{{AbstractSlingRepository2#createServiceSession}} and as such have a positive 
impact on performance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6955:


bq. Is there anywhere an official statement from Apache about the CMS no longer 
being maintained? 

I don't have references right now but the Apache CMS being deprecated and not 
maintained anymore has been mentioned several times by our infra team, 
including the example that Robert mentions

bq. Is there a replacement recommendation from Apache INFRA maybe?

The recommendation is to use whatever we want to generate the website, and 
gitpubsub to sync the generated pages, which matches this effort.

> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6948) HttpServletResponse.getOutput() and getOutputAsStream() return different information

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6948:


{code}diff --git 
a/bundles/extensions/servlet-helpers/src/test/java/org/apache/sling/servlethelpers/MockSlingHttpServletResponseTest.java
 
b/bundles/extensions/servlet-helpers/src/test/java/org/apache/sling/servlethelpers/MockSlingHttpServletResponseTest.java
index 3f72e15f0d..4e1ab73f6e 100644
--- 
a/bundles/extensions/servlet-helpers/src/test/java/org/apache/sling/servlethelpers/MockSlingHttpServletResponseTest.java
+++ 
b/bundles/extensions/servlet-helpers/src/test/java/org/apache/sling/servlethelpers/MockSlingHttpServletResponseTest.java
@@ -133,6 +133,7 @@ public class MockSlingHttpServletResponseTest {
 final String TEST_CONTENT = "Der Jodelkaiser äöü߀ ᚠᛇᚻ";
 response.setCharacterEncoding(CharEncoding.UTF_8);
 response.getWriter().write(TEST_CONTENT);
+assertEquals(TEST_CONTENT, new String(response.getOutput(), 
CharEncoding.UTF_8));
 assertEquals(TEST_CONTENT, response.getOutputAsString());
 
 response.resetBuffer();
{code}

Note that ordering is important, adding the line after the existing 
{{assertEquals}} call does not trigger the error.

> HttpServletResponse.getOutput() and getOutputAsStream() return different 
> information
> 
>
> Key: SLING-6948
> URL: https://issues.apache.org/jira/browse/SLING-6948
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Servlet Helpers 1.1.0
>Reporter: Robert Munteanu
>
> HttpServletResponse.getOutput and getOutputAsString are backed by 
> ResponseBodySupport. That class holds both a ServletOutputStream and a 
> PrintWriter, which are not kept in sync. getOutput uses the 
> ServletOutputStream and getOutputAsString uses the PrintWriter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6955:


The closest that I found was 
https://issues.apache.org/jira/browse/INFRA-13644?focusedCommentId=16035309=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16035309
 

> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: FYI, working on moving to JBake for the Sling website

[Carsten Ziegeler]

Sorry, but I have to ask, what are the problems this will solve and what
are the benefits? So far I've not heard of JBake at all.

Thanks
Carsten

Bertrand Delacretaz wrote
> Hi,
> 
> FYI in case you haven't noticed I started working on this in the last
> few days with some discussions at
> https://issues.apache.org/jira/browse/SLING-6955
> 
> I'll update that ticket when I have more concrete progress, just
> wanted to make sure this list knows about it in case someone wants to
> comment or contribute.
> 
> The conversion looks pretty good now, see the TODO list at
> https://github.com/bdelacretaz/sling-jbake
> 
> Site build instructions are also there if someone wants to have a look,
> 
> -Bertrand
> 


 

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

[jira] [Resolved] (SLING-6947) MockHttpServletRequest incorrectly calculates pathInfo for path-bound servlets

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6947.
---
   Resolution: Fixed
 Assignee: Stefan Seifert
Fix Version/s: Servlet Helpers 1.0.2
   Servlet Helpers 1.1.2

Completed: At revision: 1798814   (1.1.x)
Completed: At revision: 1798816  (1.0.x)

i've added a setPathInfo to MockSlingHttpServletRequest.
in case that is set to a non-null value in the unit test this value is 
returned, instead of the calculated value (which still makes sense for 
resourcetype-based servlets).

it's a bit difficult to automatically detect the type of registration or way of 
calling the servlet, because the whole sling engine is not involved in the unit 
test - the servlet's methods are usually called directly bypassing everything 
else.

> MockHttpServletRequest incorrectly calculates pathInfo for path-bound servlets
> --
>
> Key: SLING-6947
> URL: https://issues.apache.org/jira/browse/SLING-6947
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Servlet Helpers 1.1.0
>Reporter: Robert Munteanu
>Assignee: Stefan Seifert
> Fix For: Servlet Helpers 1.1.2, Servlet Helpers 1.0.2
>
>
> I have a servlet bound at /foo/bar . When invoked with the path /foor/bar/baz 
> the path info is expected to be /baz.
> Instead, 
> {{org.apache.sling.servlethelpers.MockSlingHttpServletRequest#getPathInfo()}} 
> seems to construct the full request path, including:
> - the resource path
> - the selector string
> - the extension
> - the suffix



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

FYI, working on moving to JBake for the Sling website

[Bertrand Delacretaz]

Hi,

FYI in case you haven't noticed I started working on this in the last
few days with some discussions at
https://issues.apache.org/jira/browse/SLING-6955

I'll update that ticket when I have more concrete progress, just
wanted to make sure this list knows about it in case someone wants to
comment or contribute.

The conversion looks pretty good now, see the TODO list at
https://github.com/bdelacretaz/sling-jbake

Site build instructions are also there if someone wants to have a look,

-Bertrand

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6955:


Is there anywhere an official statement from Apache about the CMS no longer 
being maintained? Is there a replacement recommendation from Apache INFRA maybe?

> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6955:


[~kwin] I agree with your list. I think making local builds + staging easier is 
a big plus, and the fact that the Apache CMS development stopped is a major 
problem going forward.

bq. ...even the last migration is not 100% finished yet...

Do you see concrete points which we wouldn't be able to solve with JBake? I 
agree that a new migration will probably bring a few new differences with 
existing content, and that's not ideal, but breaking things earlier than later 
(i.e. when the Apache CMS is eventually retired) is probably better.

I have categorized the TODOs at https://github.com/bdelacretaz/sling-jbake and 
it doesn't look dramatic.

I'm traveling these days and this is a good project to work on in the 
intervals, so I'm hoping to make more progress in the next few days. 



> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6959) XssProtection changes html semantic caused by formatting

[Lukas Kummer (JIRA)]

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

Lukas Kummer commented on SLING-6959:
-

might be a duplicate of SLING-5050

> XssProtection changes html semantic caused by formatting
> 
>
> Key: SLING-6959
> URL: https://issues.apache.org/jira/browse/SLING-6959
> Project: Sling
>  Issue Type: Bug
>Affects Versions: XSS Protection API 1.0.2, Scripting Sightly Engine 1.0.2
> Environment: AEM
>Reporter: Lukas Kummer
>Priority: Minor
> Attachments: space.png
>
>
> When using sightly the following html:
> {code:html}
>  ${component.infoline @ context='html'} 
> {code}
> it will be compiled to:
> {code:java}
> String var_28 = ((" "+renderContext.toString(renderContext.call("xss", 
> renderContext.resolveProperty(_global_component, "infoline"), "html")))+" ");
> {code}
> which calls 
> org.apache.sling.scripting.sightly.impl.engine.extension.XSSRuntimeExtension.call(RenderContext,
>  Object...)
> and later:
> org.apache.sling.xss.impl.XSSAPIImpl.filterHTML(String)
> When this method is called with this String:
> {code:html}
> Is it a threat or an  style="color:#e6">opportunity?
> Is it a threat or an opportunity?
> {code}
> will be turned into
> {code:html}
> Is it a threat
>  or an opportunity
> ?
> Is it a threat or an opportunity?
> {code}
> which leads to the problem, that there will be a space between the word 
> opportunity and the question mark.
> However, the formatting could be configured by changing the 
> SLING-INF/content/config.xml
> (from  to  name="formatOutput" value="false"/>)
> But anyway the formatting shouldn't change the semantics, which why the 
> formatting directive should be always false



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5947:
--
Fix Version/s: Servlet Helpers 1.0.2

backporting this ticket to 1.0.x version range of servlet helpers (in this 
case: 1.0.2) - which is compatible with sling mocks 1.x without updating to 
Servlet API 3.1 (which is part of servlet helpers 1.1.0).

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6948) HttpServletResponse.getOutput() and getOutputAsStream() return different information

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6948:
---

do you have a unit test to prove this problem?

the print writer is backed by the same ByteArrayOutputStream ad used by 
getOutputStream, and both methods getOutput and getOutputAsString use the same 
source of information for it's output.

> HttpServletResponse.getOutput() and getOutputAsStream() return different 
> information
> 
>
> Key: SLING-6948
> URL: https://issues.apache.org/jira/browse/SLING-6948
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Servlet Helpers 1.1.0
>Reporter: Robert Munteanu
>
> HttpServletResponse.getOutput and getOutputAsString are backed by 
> ResponseBodySupport. That class holds both a ServletOutputStream and a 
> PrintWriter, which are not kept in sync. getOutput uses the 
> ServletOutputStream and getOutputAsString uses the PrintWriter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6962) Sling Mock 1.x: Add support for further SlingHttpServletRequestMethods

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1798812  


> Sling Mock 1.x: Add support for further SlingHttpServletRequestMethods
> --
>
> Key: SLING-6962
> URL: https://issues.apache.org/jira/browse/SLING-6962
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Testing Sling Mock 1.9.8
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: Testing Sling Mock 1.9.10
>
>
> SLING-5947 extended servlet-helpers with support for getServletPath(), 
> getPathInfo(), getRequestURI(), getRequestURL() and getAuthType() in 
> MockSlingHttpServletRequest.
> this is part of servlet-helpers 1.1.0 which is not compatible with 
> sling-mocks because it also update to latest http serlvet API.
> so wie update to a backport of servlet-helpers 1.0.2 which includes only the 
> changes from SLING-5947.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6962) Sling Mock 1.x: Add support for further SlingHttpServletRequestMethods

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6962:
-

 Summary: Sling Mock 1.x: Add support for further 
SlingHttpServletRequestMethods
 Key: SLING-6962
 URL: https://issues.apache.org/jira/browse/SLING-6962
 Project: Sling
  Issue Type: Improvement
Affects Versions: Testing Sling Mock 1.9.8
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Testing Sling Mock 1.9.10


SLING-5947 extended servlet-helpers with support for getServletPath(), 
getPathInfo(), getRequestURI(), getRequestURL() and getAuthType() in 
MockSlingHttpServletRequest.

this is part of servlet-helpers 1.1.0 which is not compatible with sling-mocks 
because it also update to latest http serlvet API.

so wie update to a backport of servlet-helpers 1.0.2 which includes only the 
changes from SLING-5947.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6955:


Those seem to be the drawbacks that I see. The first 2 are also factors in 
discouraging external contributors. If we move to a more standard stack it 
should be simpler for casual contributors.

> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6955:


Could someone list here quickly the drawbacks of the Apache CMS 
(https://www.apache.org/dev/cms.html)? Currently I am not clearly seeing what 
problems we try to solve with the new website. Let me start the list here with 
things I see
# Local builds are hard to achieve
# Based in SVN instead of Git
# It seems that the Apache CMS is basically no longer maintained/developed

But migrating the website again seems quite some effort, given the fact that 
even the last migration is not 100% finished yet...


> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6955) Convert Sling website to JBake and gitpubsub

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6955:


Being able to build the website locally for various tests would be great. Also, 
moving it to git would be an interesting first step in our git transition.

> Convert Sling website to JBake and gitpubsub
> 
>
> Key: SLING-6955
> URL: https://issues.apache.org/jira/browse/SLING-6955
> Project: Sling
>  Issue Type: Bug
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I've started experimenting with JBake to generate the Sling website. If that 
> works well we might switch to that + gitpubsub to have a more flexible way to 
> generate the site.
> My current experiment is at https://github.com/bdelacretaz/sling-jbake, at 
> this point the site starts looking like the current one and many pages work 
> well. 
> Internal links will need to be converted, all *.md files need a more complete 
> "front matter" section, currently I have a stub for that, and I think images 
> need to move under the assets folder.
> To play with that, generate the site with the bake.sh script (setup 
> shamelessly copied from https://github.com/apache/incubator-tamaya-site)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)