Release Management doc question

[Henry Saginor]

Hi,

Does anyone know if the following documentation is up to date?
https://sling.apache.org/documentation/development/release-management.html#appendix-a-create-and-add-your-key-to-peopleapacheorg-and-https--downloadsapacheorg-sling-keys
 


It looks like key server sks-keyservers.net  has 
been deprecated and is no longer maintained. See http://sks-keyservers.net 


Henry

Re: [VOTE] Release Apache Sling JUnit Core 1.1.2

[Henry Saginor]

+1 (non-binding)

> On Apr 12, 2021, at 3:52 PM, Andreas Schaefer  
> wrote:
> 
> +1 (non-binding)
> 
> - Andy
> 
>> On Apr 9, 2021, at 9:12 AM, Cris Rockwell  wrote:
>> 
>> We solved 4 issues in sling-org-apache-sling-junit-core 1.1.2 
>> https://issues.apache.org/jira/projects/SLING/versions/12349294 
>>  
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-2426 
>> 
>> 
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>>  
>> 
>> 
>> Usage:
>> sh check_staged_release.sh 2426 /tmp/sling-staging
>> 
>> Please vote to approve these releases:
>> 
>> [ ] +1 Approve the releases
>> [ ]  0 Don't care
>> [ ] -1 Don't release, because ...
> 

Re: [VOTE] Release Apache Sling Resource Resolver 1.7.4

[Henry Saginor]

+1

> On Apr 12, 2021, at 1:22 PM, Stefan Seifert 
>  wrote:
> 
> Hi,
> 
> Resource Resolver 1.7.4  (3 issues)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12349581
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2428/
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> 
> Usage:
> sh check_staged_release.sh 2428 /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.
> 
> stefan

Re: sling npm release process

[Henry Saginor]

Sorry for a delay but I finally had some time to work on this. So, what is the 
process for uploading a release to dist.apache.org <http://dist.apache.org/>? 
According to release policy only PMC members can upload a release.

Also, I have committed my work related to packaging and release process for 
slingpackager to this branch for now
https://github.com/apache/sling-slingpackager/tree/travisBuild   
if anyone has time and is interested in review and feedback that’s always 
welcome 

Thank You.
Happy New Year!

Henry

> On Aug 14, 2020, at 6:21 AM, Robert Munteanu  wrote:
> 
> Hi Henry,
> 
> On Thu, 2020-08-13 at 22:51 -0700, Henry Saginor wrote:
>> Hi,
>> 
>> The slingpackager [1] is a nodejs based tool for managing content
>> packages. I would like to start publishing it on npmjs.org <
>> http://npmjs.org/>;. 
>> I understand that there is apache-sling org on npmjs.org. But since
>> slingpackager the first Sling nodejs module we don’t really have a
>> process for this.
>> I want to start a discussion here to define it.
> 
> I guess the first step would be to check how others at the ASF do it.
> Betrand has found some references and pasted them at 
> 
>  
> https://issues.apache.org/jira/browse/SLING-8747?focusedCommentId=16942825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16942825
> 
> Openwhisk also releases to npm, at least judging from
> 
>  https://github.com/apache/openwhisk-client-js
> 
> As for the release requiements, the entry point is
> 
>  http://www.apache.org/legal/release-policy.html#artifacts
> 
> . Briefly, that says:
> 
> - include a source package that can be used to build and test the
> release
> - cryptographically sign the artifacts
> - include LICENSE (and NOTICE if needed)
> - include license headers
> 
> A release must be published to dist.apache.org and _can_ be published
> to other channels like npmjs.org .
> 
> Hopefully that is enough to start with, but let me know if you have any
> other questions.
> 
> Oh, and I tried to add you to the npmjs org, but the site keeps
> erroring out today. I'll try again later.
> 
> Thanks,
> Robert
> 

Re: sling npm release process

[Henry Saginor]

Hi Robert,

Yes, I got. I have this org now. Thanks.

I think following ASF process should sufficient to start. I will try to get 
familiar with how other projects do this over the weekend as well.

Henry  

> On Aug 14, 2020, at 9:07 AM, Robert Munteanu  wrote:
> 
> On Fri, 2020-08-14 at 15:21 +0200, Robert Munteanu wrote:
>> Oh, and I tried to add you to the npmjs org, but the site keeps
>> erroring out today. I'll try again later.
> 
> Henry: you should've gotten an invite to the apache-sling org.
> Robert
> 

sling npm release process

[Henry Saginor]

Hi,

The slingpackager [1] is a nodejs based tool for managing content packages. I 
would like to start publishing it on npmjs.org . 
I understand that there is apache-sling org on npmjs.org. But since 
slingpackager the first Sling nodejs module we don’t really have a process for 
this.
I want to start a discussion here to define it.

Please feel free to respond with any thoughts you may have. I know this is 
really open ended. :)

Henry 

1. https://github.com/apache/sling-slingpackager

Re: Please welcome Henry Saginor, Sling committer

[Henry Saginor]

Hi 

Thank you all for welcoming me to this Sling contributor community. I am based 
out of Southern California. I have worked with Sling (and it’s entire stack) 
from it’s early days. 
But I am excited and looking forward to contributing to this project in a more 
direct way going forward. 
I hope others will find my resent contribution of slingpackager (NodeJS based 
packaging and deployment tool) useful.

Henry Saginor 
 

> On Aug 5, 2020, at 1:33 AM, Robert Munteanu  wrote:
> 
> Hi Sling community,
> 
> Based on his ongoing and valuable contributions to the project, the
> Sling PMC has elected Henry Saginor as a Sling committer, and he
> has accepted the invitation.
> 
> Please join me in welcoming Henry!
> 
> Henry - if you want to honor the old tradition of new committers
> briefly introducing themselves to the list, feel free.
> 
> Welcome!
> 
> Robert
> 
> 
> 
> 
> 

[jira] [Commented] (SLING-9558) slingpackager - the --install command does not work with upload command on Composum

[Henry Saginor (Jira)]

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

Henry Saginor commented on SLING-9558:
--

This is fixed here -
https://github.com/apache/sling-slingpackager/pull/1

> slingpackager - the --install command does not work with upload command on 
> Composum
> ---
>
> Key: SLING-9558
> URL: https://issues.apache.org/jira/browse/SLING-9558
> Project: Sling
>  Issue Type: Bug
>Reporter: Henry Saginor
>Priority: Major
>
> The slingpackage tool upload command has --install option to automatically 
> install the package after it's uploaded. It only works with AEM Package 
> manager. It breaks with basic Sling + Composum due to a missing method 
> implementation.
> This results in the following error -
> lingpackager upload --install headwire-full-package-1.0-SNAPSHOT.zip
> Uploading package 
> /home/rr/ws/peregrinesamples/samplesites/headwire-full-package-1.0-SNAPSHOT.zip
>  on http://localhost:8080
> successful
> /home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:64
>  installPackage(url, username, password, json.path, maxRetry);
>  ^
> ReferenceError: installPackage is not defined
>  at callPostService 
> (/home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:64:17)
>  at Request.request [as _callback] 
> (/home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:295:21)
>  at Request.self.callback 
> (/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:185:22)
>  at Request.emit (events.js:198:13)
>  at Request. 
> (/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:1161:10)
>  at Request.emit (events.js:198:13)
>  at IncomingMessage. 
> (/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:1083:12)
>  at Object.onceWrapper (events.js:286:20)
>  at IncomingMessage.emit (events.js:203:15)
>  at endReadableNT (_stream_readable.js:1145:12) 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-9558) slingpackager - the --install command does not work with upload command on Composum

[Henry Saginor (Jira)]

Henry Saginor created SLING-9558:


 Summary: slingpackager - the --install command does not work with 
upload command on Composum
 Key: SLING-9558
 URL: https://issues.apache.org/jira/browse/SLING-9558
 Project: Sling
  Issue Type: Bug
Reporter: Henry Saginor


The slingpackage tool upload command has --install option to automatically 
install the package after it's uploaded. It only works with AEM Package 
manager. It breaks with basic Sling + Composum due to a missing method 
implementation.

This results in the following error -
lingpackager upload --install headwire-full-package-1.0-SNAPSHOT.zip
Uploading package 
/home/rr/ws/peregrinesamples/samplesites/headwire-full-package-1.0-SNAPSHOT.zip 
on http://localhost:8080
successful
/home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:64
 installPackage(url, username, password, json.path, maxRetry);
 ^
ReferenceError: installPackage is not defined
 at callPostService 
(/home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:64:17)
 at Request.request [as _callback] 
(/home/rr/ws/peregrinesamples/sling-slingpackager/utils/composumpackager.js:295:21)
 at Request.self.callback 
(/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:185:22)
 at Request.emit (events.js:198:13)
 at Request. 
(/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:1161:10)
 at Request.emit (events.js:198:13)
 at IncomingMessage. 
(/home/rr/ws/peregrinesamples/sling-slingpackager/node_modules/request/request.js:1083:12)
 at Object.onceWrapper (events.js:286:20)
 at IncomingMessage.emit (events.js:203:15)
 at endReadableNT (_stream_readable.js:1145:12) 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: slingpackager in it's own git repo

[Henry Saginor]

+1 for /apache/sling-slingpackager

> On Apr 28, 2020, at 5:26 AM, Ruben Reusser  wrote:
> 
> I think the problem with the naming of the packager has to be looked at from 
> the npmjs registry [1]
> Ideally we use a similar name for the repo as we would use for publishing to 
> npm and how we would like people to use it from the command line.
> 
> sling-packager is unfortunately already taken and seems to be part of a sling 
> in node implementation [2].
> 
> Installation would happen through the command
> 
> > npm install *@apache-sling/slingpackager* --global
> 
> and one would use the command with
> 
> > *slingpackager* --help
> 
> while github.com/*apache/sling-slingpackager* has a repetition of sling in 
> the name it would map nicely to npm and the command line execution of the 
> tool. If we use github.com/apache/sling-packager we run the risk that people 
> will try to use the sling-packager module that already exists at [3]
> 
> [1] https://www.npmjs.com/
> [2] https://www.npmjs.com/package/sling-server
> [3] https://www.npmjs.com/package/sling-packager
> 
> On 4/27/2020 9:37 AM, Henry Saginor wrote:
>> I like js in the name because it lets me know it's not a Java project. Most
>> Sling projects are java and maven. So, repo naming is derived from maven
>> artifact id and "java" does not need to be advertised. I am not sure about
>> cli. I imagine exposing slingpackage operations as API so it can be used by
>> other tools as a library as well.
>> 
>> On Mon, Apr 27, 2020 at 1:35 AM Robert Munteanu  wrote:
>> 
>>> On Fri, 2020-04-24 at 11:39 -0700, Henry Saginor wrote:
>>>> I am happy to put up the repository name to a vote. Here are the
>>>> choices
>>>> and reasoning as I see it..
>>>> 1) github.com/apache/sling-slingpackager - short and filterable by
>>>> sling-
>>>> as project
>>>> 2) github.com/apache/sling-js-slingpackager - the same as 1) but
>>>> includes
>>>> js to id it as a js project
>>>> 3) github.com/apache/apache-sling-js-slingpackager - maps to npm org.
>>>> I
>>>> think this is better for compliance. But I am not sure.
>>>> 4) github.com/apache/sling-apache-sling-js-slingpackager - also maps
>>>> to npm
>>>> org but starts with sling- to follow sling project conventions.
>>> Well, first - ASF Infra requires that we start the repo name with
>>> 'sling-'.
>>> 
>>> Personally, I think any repetition of 'sling' and 'apache' is
>>> confusing, so I would go with either 'sling-packager' or 'sling-js-
>>> packager'.
>>> 
>>> I am not sure whether we need the 'js' part, since we don't advertise
>>> 'java' for our packages ... Maybe include 'cli' somewhere, since it's a
>>> CLI tool and would make it clear what the scope is? Just throwing out
>>> ideas...
>>> 
>>>> Also, can we move it to a new repo 1st and then figure out npm
>>>> release?
>>> +1
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> 

Re: slingpackager in it's own git repo

[Henry Saginor]

I like js in the name because it lets me know it's not a Java project. Most
Sling projects are java and maven. So, repo naming is derived from maven
artifact id and "java" does not need to be advertised. I am not sure about
cli. I imagine exposing slingpackage operations as API so it can be used by
other tools as a library as well.

On Mon, Apr 27, 2020 at 1:35 AM Robert Munteanu  wrote:

> On Fri, 2020-04-24 at 11:39 -0700, Henry Saginor wrote:
> > I am happy to put up the repository name to a vote. Here are the
> > choices
> > and reasoning as I see it..
> > 1) github.com/apache/sling-slingpackager - short and filterable by
> > sling-
> > as project
> > 2) github.com/apache/sling-js-slingpackager - the same as 1) but
> > includes
> > js to id it as a js project
> > 3) github.com/apache/apache-sling-js-slingpackager - maps to npm org.
> > I
> > think this is better for compliance. But I am not sure.
> > 4) github.com/apache/sling-apache-sling-js-slingpackager - also maps
> > to npm
> > org but starts with sling- to follow sling project conventions.
>
> Well, first - ASF Infra requires that we start the repo name with
> 'sling-'.
>
> Personally, I think any repetition of 'sling' and 'apache' is
> confusing, so I would go with either 'sling-packager' or 'sling-js-
> packager'.
>
> I am not sure whether we need the 'js' part, since we don't advertise
> 'java' for our packages ... Maybe include 'cli' somewhere, since it's a
> CLI tool and would make it clear what the scope is? Just throwing out
> ideas...
>
> >
> > Also, can we move it to a new repo 1st and then figure out npm
> > release?
>
> +1
>
> Thanks,
> Robert
>
>

Re: slingpackager in it's own git repo

[Henry Saginor]

I am happy to put up the repository name to a vote. Here are the choices
and reasoning as I see it..
1) github.com/apache/sling-slingpackager - short and filterable by sling-
as project
2) github.com/apache/sling-js-slingpackager - the same as 1) but includes
js to id it as a js project
3) github.com/apache/apache-sling-js-slingpackager - maps to npm org. I
think this is better for compliance. But I am not sure.
4) github.com/apache/sling-apache-sling-js-slingpackager - also maps to npm
org but starts with sling- to follow sling project conventions.

Also, can we move it to a new repo 1st and then figure out npm release?
These are 2 separate issues I think (unless compliance effects repository
name). I can work on any other changes required to ensure release
compliance once we figure it out.

slingpackager in it's own git repo

[Henry Saginor]

Hi All,

The slingpackage [1] is a nodejs based command line tool for managing content 
packages. 

Does it make sense to now move it out of whiteboard and into its own 
repository? What does everyone think about that?  

I also was hoping  to discuss how we can publish it to npm. I understand that 
this is an open issue right now. What can I do to help?

[1] https://github.com/apache/sling-whiteboard/tree/master/slingpackager 


Henry

[jira] [Comment Edited] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor edited comment on SLING-8584 at 7/19/19 6:18 AM:
---

[~rombert]

Here is some additional info to test this quickliy

1) After you download the file and extract it cd into extracted folder and run
{code:java}
npm install
{code}
to install node dependencies.

 

2) Then
{code:java}
npm test
{code}
to run some basic test cases.

The tests at the moment assume Sling running at localhost:8080. You can also 
run these tests against AEM if you uncomment relevant lines in 
test/serverInfo.js.

>From our e-mail thread here is also the sample project that can be packaged 
>with this
 [https://github.com/peregrine-cms/simple-sling-vue-example]

 


was (Author: hsagi...@gmail.com):
[~rombert]

Here is some additional info to test this quickliy

1) After you download the file and extract it cd into extracted folder and run
{code:java}
npm install
{code}
to install node dependencies.

 

2) Then
{code:java}
npm test
{code}
to run some basic test cases.

The tests at the moment assume Sling running at localhost:8080. You also run 
tests against AEM if you uncomment relevant lines in test/serverInfo.js.

>From our e-mail thread here is also the sample project that can be packaged 
>with this
https://github.com/peregrine-cms/simple-sling-vue-example

 

> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz] 
> (shasum ee91c707070f81d9516c8fedbab0aec30605c225)|A nodejs based command line 
> tool alternative to the maven plugin.
>  This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor commented on SLING-8584:
--

[~rombert]

Here is some additional info to test this quickliy

1) After you download the file and extract it cd into extracted folder and run
{code:java}
npm install
{code}
to install node dependencies.

 

2) Then
{code:java}
npm test
{code}
to run some basic test cases.

The tests at the moment assume Sling running at localhost:8080. You also run 
tests against AEM if you uncomment relevant lines in test/serverInfo.js.

>From our e-mail thread here is also the sample project that can be packaged 
>with this
https://github.com/peregrine-cms/simple-sling-vue-example

 

> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>    Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz] 
> (shasum ee91c707070f81d9516c8fedbab0aec30605c225)|A nodejs based command line 
> tool alternative to the maven plugin.
>  This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor commented on SLING-8584:
--

[~rombert]

I updated the attachment with some changes and added shasum.

Let me know if you need anything else.

> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>    Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz] 
> (shasum ee91c707070f81d9516c8fedbab0aec30605c225)|A nodejs based command line 
> tool alternative to the maven plugin.
>  This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8584:
-
Description: 
h1. Modules

This donation proposal covers one module.
||Module||Source||Description||
|slingpackager|on 
[GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
 or [^slingpackager.tar.gz] 
(shasum ee91c707070f81d9516c8fedbab0aec30605c225)|A nodejs based command line 
tool alternative to the maven plugin.
 This tool covers the following use cases.
 * build a content package form a local folder
 * upload a content package onto a server
 * install a content package on a server
 * list all installed packages on the server
 * uninstall a content package from the server
 * delete a content package on the server|

  was:
h1. Modules

This donation proposal covers one module.
||Module||Source||Description||
|slingpackager|on 
[GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
 or [^slingpackager.tar.gz]|A nodejs based command line tool alternative to the 
maven plugin.
This tool covers the following use cases.
 * build a content package form a local folder
 * upload a content package onto a server
 * install a content package on a server
 * list all installed packages on the server
 * uninstall a content package from the server
 * delete a content package on the server|


> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>        Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz] 
> (shasum ee91c707070f81d9516c8fedbab0aec30605c225)|A nodejs based command line 
> tool alternative to the maven plugin.
>  This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8584:
-
Attachment: slingpackager.tar.gz

> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>        Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz]|A nodejs based command line tool alternative to 
> the maven plugin.
> This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8584:
-
Attachment: (was: slingpackager.tar.gz)

> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>        Reporter: Henry Saginor
>Assignee: Robert Munteanu
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz]|A nodejs based command line tool alternative to 
> the maven plugin.
> This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8585) The acl page in Sling displays Apache License header

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8585:
-
Description: 
Start Sling and go to [http://localhost:8080/content.acl.html]

Note Apache License comment rendered at the top of the page.

PR with a fix: 
[https://github.com/apache/sling-org-apache-sling-starter-content/pull/2]

  was:
Start Sling and go to [http://localhost:8080/content.acl.html]

Note Apache License comment rendered at the top of the page.

PR to fix this 
https://github.com/apache/sling-org-apache-sling-starter-content/pull/2


> The acl page in Sling displays Apache License header
> 
>
> Key: SLING-8585
> URL: https://issues.apache.org/jira/browse/SLING-8585
> Project: Sling
>  Issue Type: Bug
>        Reporter: Henry Saginor
>Priority: Minor
>
> Start Sling and go to [http://localhost:8080/content.acl.html]
> Note Apache License comment rendered at the top of the page.
> PR with a fix: 
> [https://github.com/apache/sling-org-apache-sling-starter-content/pull/2]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8585) The acl page in Sling displays Apache License header

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8585:
-
Description: 
Start Sling and go to [http://localhost:8080/content.acl.html]

Note Apache License comment rendered at the top of the page.

PR to fix this 
https://github.com/apache/sling-org-apache-sling-starter-content/pull/2

  was:
Start Sling and go to [http://localhost:8080/content.acl.html]

Note Apache License comment rendered at the top of the page.


> The acl page in Sling displays Apache License header
> 
>
> Key: SLING-8585
> URL: https://issues.apache.org/jira/browse/SLING-8585
> Project: Sling
>  Issue Type: Bug
>        Reporter: Henry Saginor
>Priority: Minor
>
> Start Sling and go to [http://localhost:8080/content.acl.html]
> Note Apache License comment rendered at the top of the page.
> PR to fix this 
> https://github.com/apache/sling-org-apache-sling-starter-content/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SLING-8585) The acl page in Sling displays Apache License header

[Henry Saginor (JIRA)]

Henry Saginor created SLING-8585:


 Summary: The acl page in Sling displays Apache License header
 Key: SLING-8585
 URL: https://issues.apache.org/jira/browse/SLING-8585
 Project: Sling
  Issue Type: Bug
Reporter: Henry Saginor


Start Sling and go to [http://localhost:8080/content.acl.html]

Note Apache License comment rendered at the top of the page.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: nodejs based sling packager

[Henry Saginor]

Hi Robert,

I created the following proposal JIRA
https://issues.apache.org/jira/browse/SLING-8584

Please let Ruben and me know if anything else is needed.

Henry

> On Jul 16, 2019, at 4:18 AM, Robert Munteanu  wrote:
> 
> Hi Ruben,
> 
> On Sun, 2019-07-14 at 08:44 -0700, Ruben Reusser wrote:
>> Dear Sling Developers,
>> 
>> in an effort to help 'front end developers' embrace Apache Sling and
>> in 
>> order to make simple front-end Sling projects maven independent we 
>> created a node only slingpackager [1] and a sample VueJs based Slnig 
>> Content Browser [2] as a showcase project.
>> 
>> We'd like to see the slingpackager (and potentially the showcase 
>> example) be part of Apache Sling and maybe live on npmjs in an
>> Apache 
>> Sling organization (@apachesling for example).
>> 
>> We'd love to hear what you think about this!
>> 
> 
> This sounds great! I think these would be very good additions to Apache
> Sling.
> 
> I think that we probably need to go through a code donation unless you
> have developed these especially for the ASF.
> 
> There is some information at [3] related to this, feel free to ask if
> you need additional information.
> 
> Thanks,
> 
> Robert
> 
> 
>> Ruben Reusser
>> 
>> [1] https://github.com/peregrine-cms/slingpackager
>> [2] https://github.com/peregrine-cms/simple-sling-vue-example
> 
> [3]: 
> https://cwiki.apache.org/confluence/display/SLING/Using+Git+with+Sling#UsingGitwithSling-Codedonations
> 

[jira] [Updated] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

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

Henry Saginor updated SLING-8584:
-
Description: 
h1. Modules

This donation proposal covers one module.
||Module||Source||Description||
|slingpackager|on 
[GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
 or [^slingpackager.tar.gz]|A nodejs based command line tool alternative to the 
maven plugin.
This tool covers the following use cases.
 * build a content package form a local folder
 * upload a content package onto a server
 * install a content package on a server
 * list all installed packages on the server
 * uninstall a content package from the server
 * delete a content package on the server|

  was:
h1. Modules

This donation proposal covers one module.
||Module||Source||Description||
|slingpackager|on 
[GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
or [^slingpackager.tar.gz]|This is a nodejs based command line tool alternative 
to the maven plugin.|


> Donation proposal of nodejs slingpackager
> -
>
> Key: SLING-8584
> URL: https://issues.apache.org/jira/browse/SLING-8584
> Project: Sling
>  Issue Type: New Feature
>        Reporter: Henry Saginor
>Priority: Minor
> Attachments: slingpackager.tar.gz
>
>
> h1. Modules
> This donation proposal covers one module.
> ||Module||Source||Description||
> |slingpackager|on 
> [GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
>  or [^slingpackager.tar.gz]|A nodejs based command line tool alternative to 
> the maven plugin.
> This tool covers the following use cases.
>  * build a content package form a local folder
>  * upload a content package onto a server
>  * install a content package on a server
>  * list all installed packages on the server
>  * uninstall a content package from the server
>  * delete a content package on the server|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SLING-8584) Donation proposal of nodejs slingpackager

[Henry Saginor (JIRA)]

Henry Saginor created SLING-8584:


 Summary: Donation proposal of nodejs slingpackager
 Key: SLING-8584
 URL: https://issues.apache.org/jira/browse/SLING-8584
 Project: Sling
  Issue Type: New Feature
Reporter: Henry Saginor
 Attachments: slingpackager.tar.gz

h1. Modules

This donation proposal covers one module.
||Module||Source||Description||
|slingpackager|on 
[GitHub|https://github.com/peregrine-cms/slingpackager/tree/apacheContrib]
or [^slingpackager.tar.gz]|This is a nodejs based command line tool alternative 
to the maven plugin.|



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-8430) Use java.util.zip.ZipFile in Feature Model Analyser

[Henry Saginor (JIRA)]

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

Henry Saginor commented on SLING-8430:
--

[~karlpauls]
I made the changes you suggested in the PR. Thank you for reviewing this.

> Use java.util.zip.ZipFile in Feature Model Analyser
> ---
>
> Key: SLING-8430
> URL: https://issues.apache.org/jira/browse/SLING-8430
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Reporter: Henry Saginor
>Assignee: Karl Pauls
>Priority: Minor
>
> The ContentPackageScanner and FelixFrameworkScanner could use 
> java.util.zip.ZipFile API. In my estimation this should improve performance 
> over the current use of ZipInputStream.
> Here is a pull request with suggested changes including a unit test for 
> ContentPackageScanner:
> https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/14



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Replacing ZipInputStream with ZipFile in Feature Model Analyser

[Henry Saginor]

Hi Sling Devs,

The code in Feature Model Analyser has direct file access to zip files. So, it 
could use ZipFile api instead of ZipInputStream. I did some experimentation and 
ZipFile should perform better in my estimation. I created a ticket and pr 
bellow with the suggested changes.  
https://issues.apache.org/jira/browse/SLING-8430 

https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/14 


Can this small change accepted?

Henry

[jira] [Created] (SLING-8430) Use java.util.zip.ZipFile in Feature Model Analyser

[Henry Saginor (JIRA)]

Henry Saginor created SLING-8430:


 Summary: Use java.util.zip.ZipFile in Feature Model Analyser
 Key: SLING-8430
 URL: https://issues.apache.org/jira/browse/SLING-8430
 Project: Sling
  Issue Type: Improvement
  Components: Feature Model
Reporter: Henry Saginor


The ContentPackageScanner and FelixFrameworkScanner could use 
java.util.zip.ZipFile API. In my estimation this should improve performance 
over the current use of ZipInputStream.

Here is a pull request with suggested changes including a unit test for 
ContentPackageScanner:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/14



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

esx ScriptEngine + react.js

[Henry Saginor]

Hi,

I would like to run some server side react.js components in Sling. I was 
experimenting with the esx engine [1]  which works like a NodeJs loader and 
allows you to load any valid Node module.
I am able to run the demo examples that come with that bundle. So, I installed 
react npm module and it’s dependencies under /libs/esx/node_modules. But when I 
try to load react based script in sling I get an exception at [2].
I see “process” properties declared in SlingBabel.js and when I debug I see 
that the transpile step works for my initial script (one sling:resourceType 
points to).

I know this esx engine is considered experimental according to JIRA ticket [3]. 
But I was still curious if anyone else has tried this or can help out.

If I can successfully load react I would like to work on some tests suggested 
in JIRA and see if I can contribute to this module. Therefor I thought it 
appropriate to send this to dev list. 
I apologize in advance for spam if that’s not correct.  

Regards, 

Henry

[1] https://github.com/apache/sling/tree/trunk/contrib/scripting/esx 


[2] jdk.nashorn.internal.runtime.ECMAException: ReferenceError: "process" is 
not defined
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
at 
jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:319)
at 
jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:291)
at 
jdk.nashorn.internal.objects.Global.__noSuchProperty__(Global.java:1441)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39714$173AA$warning.L:2(/libs/esx/node_modules/fbjs/lib/warning.js:25)
at 
java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
at 
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:651)
at 
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at 
jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at 
jdk.nashorn.api.scripting.ScriptObjectMirror.call(ScriptObjectMirror.java:117)
at org.apache.sling.scripting.esx.Module.runScript(Module.java:249)
at org.apache.sling.scripting.esx.Module.require(Module.java:670)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39711$349A$ReactNoopUpdateQueue.L:2#require(/libs/esx/node_modules/react/lib/ReactNoopUpdateQueue.js:2)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39710$187AA$ReactNoopUpdateQueue.L:2(/libs/esx/node_modules/react/lib/ReactNoopUpdateQueue.js:14)
at 
java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
at 
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:651)
at 
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at 
jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at 
jdk.nashorn.api.scripting.ScriptObjectMirror.call(ScriptObjectMirror.java:117)
at org.apache.sling.scripting.esx.Module.runScript(Module.java:249)
at org.apache.sling.scripting.esx.Module.require(Module.java:670)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39704$345A$ReactBaseClasses.L:2#require(/libs/esx/node_modules/react/lib/ReactBaseClasses.js:2)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39703$183AA$ReactBaseClasses.L:2(/libs/esx/node_modules/react/lib/ReactBaseClasses.js:17)
at 
java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
at 
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:651)
at 
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at 
jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at 
jdk.nashorn.api.scripting.ScriptObjectMirror.call(ScriptObjectMirror.java:117)
at org.apache.sling.scripting.esx.Module.runScript(Module.java:249)
at org.apache.sling.scripting.esx.Module.require(Module.java:670)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39696$334A$React.L:2#require(/libs/esx/node_modules/react/lib/React.js:2)
at 
jdk.nashorn.internal.scripts.Script$Recompilation$39695$172AA$React.L:2(/libs/esx/node_modules/react/lib/React.js:16)

[3] https://issues.apache.org/jira/browse/SLING-6680 

Re: searchPath based on content path + multitenancy

[Henry Saginor]

Thanks Bertrand,
I see that at Sling engine level ServletResolver is pluggable already. So, this 
is something I could do at the project level as well. 
Project level ServletResolver could still delegate to default 
SlingServletResolver, I suppose, after resolving script name to absolute path 
or wrapping SlingHttpServletRequest (depending on the method called). 
Since true multitanancy has much bigger scope than what I need and is still 
experimental I think I will investigate this route.

What do you think of exposing a more general purpose extension point in default 
SlingServletResolver so it can delegate actual script path resolution to a 
service interface? Technically multetenancy could be plugged in using the same 
general purpose interface.

Henry

> On Mar 2, 2016, at 1:33 AM, Bertrand Delacretaz  
> wrote:
> 
> Hi,
> 
> On Tue, Mar 1, 2016 at 11:06 PM, Henry Saginor
>  wrote:
>> ...Currently my application has a customized Servlet Resolver that does 
>> this...
> 
> If you're adventurous you could have a look at my content-based
> dynamic search path prototype at [1], that does something similar
> IIUC.
> 
> At the Sling engine level this requires a fairly small change to the
> SlingServletResolver to use a MultitenantServletResolver - it might be
> possible to add an extension point to make such things pluggable, if
> there are solid use cases behind that.
> 
> Note that I haven't run that code in a while, not sure if it still
> works in its current form.
> 
> -Bertrand
> 
> [1] 
> https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model
> 
> [2] 
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/multisling2015/

Re: searchPath based on content path + multitenancy

[Henry Saginor]

Hi Jorg,

Thank you for your input. I have considered using different resource types. 
This would work.
But my use case is a bit different from true multi-tenancy. This is one 
company/tenant hosting their own Sling (CQ just upgraded to AEM 6.1) instances. 
They have been working on reimplementing components to be “responsive”. As 
requirements changed the new responsive content also had to be re-authored. 
But while not all pages exist yet under responsive tree we have to be able to 
render old content using legacy components. 
And yes we could still run some scripts to change resource types under 
responsive tree. 
But eventually we will throw away old components and would like to keep the 
project structure the same (main reason for the same resource types). So, we 
would need to run scripts again to change resource types back.
I just found patching servlet resolver easer. It has worked well for us and we 
can just throw it away later. The only issue like I said is upgrading. This was 
intended as temp solution until we migrate the site completely. 
But content re-authoring is taking longer than originally assumed and we have 
to keep supporting both responsive and legacy content. 

I can still re-patch newer servlet resolver when we need to upgrade. It’s not a 
huge problem. But I wanted to look into implementing something more general 
that I could give back open source community and Tenant API seemed ideal.

Henry

> On Mar 2, 2016, at 12:53 AM, Jörg Hoh  wrote:
> 
> Hi Henry,
> 
> we had the same challenge, and instead of changing/patching the resource
> resolver we change the resource types. So each tenant has its own
> resourcetype namespace; for example
> /apps/tenannts/components/page/homepage. So we can use the "defaults" here,
> and just provide different renderings.
> 
> Jörg
> 
> 
> 2016-03-01 23:06 GMT+01:00 Henry Saginor :
> 
>> Hi,
>> 
>> I have a need to execute different scripts for my resource types based on
>> content resource path.
>> For example resources under /content/abc and /content/xyz have the same
>> resource types but should be rendered differently.
>> I was reading [1] and [2] which seem to describe how this can be
>> implemented via multi tenancy.
>> But I don’t think this has been integrated into script resolution process
>> yet. What is the current state of this and what’s the plan?
>> 
>> I can work on a patch. But I would need some guidance to make sure it is
>> constant with the Sling vision for multitenancy.
>> 
>> Are there any other ideas on how to do this? Currently my application has
>> a customized Servlet Resolver that does this.
>> But this makes upgrades more difficult because application code is coupled
>> with a specific version of servlet resolver. So, we have to port our code
>> every time we need to upgrade Servlet Resolver.
>> 
>> [1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
>> [2]
>> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
>> <
>> https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
>>> 
>> 
>> Regards,
>> 
>> Henry
> 
> 
> 
> 
> -- 
> Cheers,
> Jörg Hoh,
> 
> http://cqdump.wordpress.com
> Twitter: @joerghoh

searchPath based on content path + multitenancy

[Henry Saginor]

Hi,

I have a need to execute different scripts for my resource types based on 
content resource path.
For example resources under /content/abc and /content/xyz have the same 
resource types but should be rendered differently.  
I was reading [1] and [2] which seem to describe how this can be implemented 
via multi tenancy.
But I don’t think this has been integrated into script resolution process yet. 
What is the current state of this and what’s the plan? 

I can work on a patch. But I would need some guidance to make sure it is 
constant with the Sling vision for multitenancy.

Are there any other ideas on how to do this? Currently my application has a 
customized Servlet Resolver that does this. 
But this makes upgrades more difficult because application code is coupled with 
a specific version of servlet resolver. So, we have to port our code every time 
we need to upgrade Servlet Resolver.

[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] 
https://cwiki.apache.org/confluence/display/SLING/Multitenancy+scenarios+and+use+cases
 


Regards,

Henry

broken documentation URLs returned by google

[Henry Saginor]

I am not sure if anyone else has reported this. But some sling documentation 
URLs return 500 errors. See some examples bellow.

http://sling.apache.org/site/maven-archetypes.html
http://sling.apache.org/site/output-rewriting-pipelines-orgapacheslingrewriter.html
http://sling.apache.org/site/rewriting-the-output-through-pipelines.html

These are all returned by google. This 
http://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
 works fine for example.
But if you goole any common sling term like “sling rewriter” you might get 
broken URLs.  

Re: Tenant Implementation in Sling

[Henry Saginor]

Hi Andy,

Thank you for bringing this up. I have a similar requirement. 
I don’t see any way of integrating Tenants other than patching Servlet 
Resolver. This is what I had done for my customer but for a really specific 
case (they are not truly multi-tenant).  
I also had to use ThreadLocal. I didn’t really see a better approach because a 
request is not always available in servlet resolver. So, if you have to map 
your tenant id to any information in the request you have to. Please let me 
know if you can think of something better.

Also, for 1) I think beyond an interface you can provide some generic 
implementation and configuration factory. With configuration factory you can 
create and configure multiple instances with different configurations 
(sub-domain/path/cookies/parameters). With this I would say 3) is not a 
requirement unless I miss-undertood what you meant.

Maybe you could open a JIRA ticket and post a patch there. 

Henry

On Feb 17, 2014, at 6:58 PM, Andreas Schaefer Sr.  wrote:

> Hi
> 
> I am working for a client which needs support for tenants and because the 
> current implementation of the Tenants in Sling is just that but no 
> integration I started to code a workaround. For now I have a patch that does 
> the trick but it is not clean because I use a Servlet Filter to place the 
> tenant id on a thread local instance. Afterwards I started to look into how 
> to implemented this cleanly into the current version of Sling.
> 
> There are a few areas that need to be changed in order to implement tenant 
> support. For now I am only looking into how to implement a “per-call overlays 
> of servlets / JSPs” in order to give tenants the chance to change aspects of 
> their presentation.
> 
> 1) Tenant Identification: Sling must be able to identify a tenant. This can 
> be a sub domain, path, cookies or even parameters. This means the client 
> needs to provide a service which is then used by Sling in order to retrieve 
> the tenant and provide it to whomever wants to use it.
> 
> 2) Servlet Resolver needs to be changed twofolds
>   a) Being able to extend the search path for Servlets / JSPs based on 
> the tenant’s data
>   b) Caching the Servlets / JPSs separated for different tenants
> 
> 3) Change the Felix OSGi Web Plugin to allow the clients to add properties 
> (single and multi values)
> 
> 
> For 1) I would suggest just to define an interface the client can implement 
> as an OSGi service which is used to identify a tenant. Then somewhere in the 
> SlingMainServlet or the Request Data the Tenant is retrieved set on the Sling 
> Http Servlet Request and if applicable the Search Path of the Resource 
> Resolver is “enhanced/extended”.
> 
> For 2) I would suggest to add a new property to the Resource Resolver which 
> contains the Search Path Extension. Because the Servlet Resolver uses the 
> Administrative Resource Resolver we need a way to “Enhance the Search Path” 
> for that particular call. This could be done with a one-off wrapper. Based on 
> the Extended Search Path we can determine which Servlet is an overlay and 
> cache the overlays separately.
> 
> 3) should be straight forward.
> 
> Carsten was suggesting something like a TenantProvider like the 
> ServletProvider but in the current code the ServletProvider is called with 
> either the Sling Servlet Request, the Resource or a Resource Resolver and 
> path. This means the tenant id must be available to any of these calls which 
> would require to put the tenant id inside the Resource Resolver.
> 
> Let me know what you think.
> 
> - Andy Schaefer
> 

Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Henry Saginor]

This is what I derive from your Roy's comments. 

It is not possible to predict all of the changes that might be conditioned via 
a flag. The context is really up to the application developers and their 
requirements. 
Applying feature flags at the resource level would only cover a particular set 
of changes. 
So, fundamentally all that the framework can do is provide a way to define 
flags, provide a switch panel and a way to extend it, and API to check flags in 
condition statements. 
How and where each flag is used is up to the developer of a specific 
application feature. 

Also, API for flag checking needs to be made available on both client and 
server without them calling each other. This can get tricky when we consider 
caching.

On Nov 15, 2013, at 6:00 PM, "Roy T. Fielding"  wrote:

> On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
>> On 15.11.2013, at 07:13, Amit.. Gupta.  wrote:
>> 
>>> You are right, we can temporarily enable feature. But, as we advocate more 
>>> and more use of ResourceResolver api instead of underlying content storage. 
>>> There could be cases where even editors/tools used in 
>>> development/installers are using the resourceResolver api and never see the 
>>> resource.
>>> Like exporting some content package to be deployed to another sling 
>>> instance, but package exporter use resouceResolver api and never see the 
>>> resource.
>> 
>> Ack. IMO feature flags are clearly a high-level application, not 
>> infrastructure, aspect.
> 
> Feature flags are a mechanism for isolating changes within a deployed
> system.  Any part of that system.
> 
> That means a feature flag needs to be able to condition any change
> that might be made to a system, including any change to the configuration
> files/data, any change to code monitoring the system, any change to the
> selection of data sources, any change to content (including everything
> as content), any change to a layout within any page or component, any
> change to the order in which things are done, any change to a report
> about what was done, and any change I haven't mentioned yet short of
> physically walking up to the server rack and unplugging the power
> by hand.
> 
> In short, if it is content, it can be made conditional on the basis
> of a feature flag.  That is the granularity of feature flag use.
> 
> Separate from that is the feature flag flip switch (i.e., the set
> of ways that a given feature can be turned on) and the extent to
> which a feature becomes sticky per user once enabled for that user.
> 
> You should expect a typical deployed site to have on the order of
> 1024 active feature flags.  Hence, think carefully before choosing
> a verbose (or linear) mechanism for checking or remembering flags.
> Likewise, you should expect to have both a global setting for each
> flag and a per-user mask, and the person running the flip switch
> control panel needs to be able to choose from
> 
>  a) off for all users
>  b) off for unassigned users
>  c) proportional assignment to on (X out of N users, max M)
>  d) logical (custom code) assignment to on
>  e) on for unassigned users
>  f) on for all users
> 
> and be able to remember assignments per user, without requiring
> the user to login, and without assigning more than one cookie.
> 
> Oh, and a flag check should be available for both server-side
> and client-side code, without calling the other side.
> 
> Finally, for the ultimate effect, it ought to be possible to burn
> a flag by automating the removal of all conditionals within managed
> content that require that flag (change the content to permanently on)
> or the removal of all such conditions (permanently off).
> 
> Cheers,
> 
> Roy
> 

[jira] [Commented] (SLING-3148) Implement support for Feature Flags/Toggles in Sling

[Henry Saginor (JIRA)]

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

Henry Saginor commented on SLING-3148:
--

Thanks for looking into this. I agree with Bernard that this should be 
something more than turning OSGi services on and off. I would just add that the 
provider interface should have a method (or methods) for toggling a flag and 
there needs to be some admin UI managed by Sling to toggle them. Also it would 
be nice to have a hook in resource rendering (sling:include and sling servlets) 
to check flags once support for them is implemented. Flags should work in a 
clustered scenario btw. 

> Implement support for Feature Flags/Toggles in Sling
> 
>
> Key: SLING-3148
> URL: https://issues.apache.org/jira/browse/SLING-3148
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Henry Saginor
>Priority: Minor
>
> It would be nice if sling provide support for feature flags (also called 
> toggles) pattern [1].
> I am thinking the implementation could provide the following.
> 1) Integrate an existing framework such as togglz [2] or implement something 
> similar with UI/Configuration to toggle features.
> 2) Create a jcr property (sling:Feature) which can be added to resource type 
> nodes. Then some conditional logic in , and get and post 
> servlets determines if the resource should be rendered if its resource type 
> contains such property.
> [1] http://en.wikipedia.org/wiki/Feature_toggle
> [2] http://www.togglz.org/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3148) Implement support for Feature Flags/Toggles in Sling

[Henry Saginor (JIRA)]

Henry Saginor created SLING-3148:


 Summary: Implement support for Feature Flags/Toggles in Sling
 Key: SLING-3148
 URL: https://issues.apache.org/jira/browse/SLING-3148
 Project: Sling
  Issue Type: New Feature
  Components: General
Reporter: Henry Saginor
Priority: Minor


It would be nice if sling provide support for feature flags (also called 
toggles) pattern [1].

I am thinking the implementation could provide the following.
1) Integrate an existing framework such as togglz [2] or implement something 
similar with UI/Configuration to toggle features.
2) Create a jcr property (sling:Feature) which can be added to resource type 
nodes. Then some conditional logic in , and get and post 
servlets determines if the resource should be rendered if its resource type 
contains such property.

[1] http://en.wikipedia.org/wiki/Feature_toggle
[2] http://www.togglz.org/



--
This message was sent by Atlassian JIRA
(v6.1#6144)