[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

[Csaba Varga (JIRA)]

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

Csaba Varga commented on SLING-3524:


{quote}Unit tests covering all paths would be good, I think.
{quote}
I'll try to have a shot at it, then. With a parameterized test class covering 
all eight combinations, I could probably get rid of the current testLeakOnSudo 
and testNoSessionSharing tests. (They would be covered by the new test class, 
which would test leaks and sharing in all the relevant combinations.)
{quote}AFAICS, the cell in bold is the only new combination as part of this 
patch.
{quote}
Yes, that's the intention. If any other combination starts working differently, 
it's most likely a bug.

> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was 
> created by passing an existing session using 
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of 
> the resource resolver to pass into a new, separate thread, and use 
> {{ResourceResolver.clone(null)}}, you will actually share the session, but 
> this is not obvious. The problem is that a JCR session cannot be shared 
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to 
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I 
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource 
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return 
> a session that impersonated itself, abstracting this from the resource 
> resolver user. Additionally, it might be worth looking that clone always 
> returns a new session, unless specifically stated.



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

[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-3524:
--

Thanks, LGTM! Unit tests covering all paths would be good, I think.

For reference, I updated the table to make the differences more clear. AFAICS, 
the cell in bold is the only new combination as part of this patch.

 
||Scenario||No clone||Clone||
|Normal login, no sudo|logoutSession: true
no impersonation call
doLogoutSession: true|_same as no clone_|
|Normal login with sudo|logoutSession: true
original session impersonated then closed, USER_IMPERSONATOR set
doLogoutSession: true|_same as no clone_|
|Session login, no sudo|logoutSession: false
session used as-is
doLogoutSession: false|*logoutSession: false*
*session self-impersonated*
*doLogoutSession: true*|
|Session login with sudo|logoutSession: false
session impersonated, USER_IMPERSONATOR set
doLogoutSession: true|_same as no clone_|

> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was 
> created by passing an existing session using 
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of 
> the resource resolver to pass into a new, separate thread, and use 
> {{ResourceResolver.clone(null)}}, you will actually share the session, but 
> this is not obvious. The problem is that a JCR session cannot be shared 
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to 
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I 
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource 
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return 
> a session that impersonated itself, abstracting this from the resource 
> resolver user. Additionally, it might be worth looking that clone always 
> returns a new session, unless specifically stated.



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

Subject: [VOTE] Release Apache Sling JCR Content Parser version 1.2.6

[Jason E Bailey]

Hi,

We solved 2 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341009

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

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

- Jason

ApacheCon North America 2018 schedule is now live.

[Rich Bowen]

Dear Apache Enthusiast,

We are pleased to announce our schedule for ApacheCon North America 
2018. ApacheCon will be held September 23-27 at the Montreal Marriott 
Chateau Champlain in Montreal, Canada.


Registration is open! The early bird rate of $575 lasts until July 21, 
at which time it goes up to $800. And the room block at the Marriott 
($225 CAD per night, including wifi) closes on August 24th.


We will be featuring more than 100 sessions on Apache projects. The 
schedule is now online at https://apachecon.com/acna18/


The schedule includes full tracks of content from Cloudstack[1], 
Tomcat[2], and our GeoSpatial community[3].


We will have 4 keynote speakers, two of whom are Apache members, and two 
from the wider community.


On Tuesday, Apache member and former board member Cliff Schmidt will be 
speaking about how Amplio uses technology to educate and improve the 
quality of life of people living in very difficult parts of the 
world[4]. And Apache Fineract VP Myrle Krantz will speak about how Open 
Source banking is helping the global fight against poverty[5].


Then, on Wednesday, we’ll hear from Bridget Kromhout, Principal Cloud 
Developer Advocate from Microsoft, about the really hard problem in 
software - the people[6]. And Euan McLeod, ‎VP VIPER at ‎Comcast will 
show us the many ways that Apache software delivers your favorite shows 
to your living room[7].


ApacheCon will also feature old favorites like the Lightning Talks, the 
Hackathon (running the duration of the event), PGP key signing, and lots 
of hallway-track time to get to know your project community better.


Follow us on Twitter, @ApacheCon, and join the disc...@apachecon.com 
mailing list (send email to discuss-subscr...@apachecon.com) to stay up 
to date with developments. And if your company wants to sponsor this 
event, get in touch at h...@apachecon.com for opportunities that are 
still available.


See you in Montreal!

Rich Bowen
VP Conferences, The Apache Software Foundation
h...@apachecon.com
@ApacheCon

[1] http://cloudstackcollab.org/
[2] http://tomcat.apache.org/conference.html
[3] http://apachecon.dukecon.org/acna/2018/#/schedule?search=geospatial
[4] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/df977fd305a31b903
[5] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/22c6c30412a3828d6
[6] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/fbbb2384fa91ebc6b
[7] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/88d50c3613852c2de

Re: [Feature Model] Moving the Feature Model out of sling-whiteboard

[David Bosschaert]

0.1.0 works for me too.

I'll work on preparing the repos with this.

Best regards,

David

On 1 May 2018 at 07:55, Carsten Ziegeler  wrote:

> Good idea, we usually start with 0.1.0 for such releases. I think to
> clearly mark these as pre-versions, the package exports should be
> changed from 1.0.0 to 0.1.0. Versions below 1.0 mark them as potentially
> unstable.
>
> Once we are happy with these modules and we release a 1.0.0, the package
> exports will be changed to 1.0.0
>
> Regards
>
> Carsten
>
>
> David Bosschaert wrote
> > Hi all,
> >
> > With the Sling Feature Model now being outside of the Sling Whiteboard in
> > proper Git repositories, I'd like to do a an initial release of the
> > following components some time soon:
> >
> > sling-org-apache-sling-feature
> > sling-org-apache-sling-feature-analyser
> > sling-org-apache-sling-feature-applicationbuilder
> > sling-org-apache-sling-feature-io
> > sling-org-apache-sling-feature-karaf
> > sling-org-apache-sling-feature-launcher
> > sling-org-apache-sling-feature-modelconverter
> > sling-org-apache-sling-feature-resolver
> >
> > I think it's early days and personally I wouldn't call this release a
> 1.0.0
> > release yet, maybe we can call it 0.2.0 or 0.9.0 or something like this?
> >
> > Is there anything that we should do before starting to cut the release?
> >
> > Best regards,
> >
> > David
> >
> >
> > On 27 April 2018 at 12:31, David Bosschaert 
> > wrote:
> >
> >> Thanks Robert, I moved them there.
> >>
> >> Best regards,
> >>
> >> David
> >>
> >> On 27 April 2018 at 12:23, Robert Munteanu  wrote:
> >>
> >>> Hi David,
> >>>
> >>> On Fri, 2018-04-27 at 12:17 +0100, David Bosschaert wrote:
>  Thanks Karl!
> 
>  I have now moved the content to the new git repositories.
> 
>  There is one directory left in sling-whiteboard/featuremodel and
>  that's the
>  example directory. This would be a nice starting point for user
>  documentation etc. Maybe we should create a separate repository for
>  this?
>  sling-org-apache-sling-feature-examples? Or something else?
> >>>
> >>> There's already https://github.com/apache/sling-samples/ if you're
> >>> looking for an examples/samples reposistory.
> >>>
> >>> Robert
> >>>
> 
>  Best regards,
> 
>  David
> 
>  On 26 April 2018 at 21:56, Karl Pauls  wrote:
> 
> > I create the repositories (including the slingfeature-maven-
> > plugin).
> >
> > regards,
> >
> > Karl
> >
> > On Thu, Apr 26, 2018 at 8:34 PM, Carsten Ziegeler  > .org>
> > wrote:
> >> Sounds good to me, sling-slingfeature-maven-plugin sounds like a
> >> good
> >> name as well. As we'll need a plugin at some point, I think it
> >> makes
> >> sense to create it now already
> >>
> >> Regards
> >>
> >> Carsten
> >>
> >> David Bosschaert wrote
> >>> Hi all,
> >>>
> >>> Thanks all for supporting the idea!
> >>>
> >>> I would propose the following Git repository names:
> >>>
>  * feature - The Feature Model API
> >>>
> >>> sling-org-apache-sling-feature
> >>>
>  * feature-analyser - Analyser Module for Features
> >>>
> >>> sling-org-apache-sling-feature-analyser
> >>>
>  * feature-applicationbuilder - Command line tool for building
> >>>
> >>> Applications from Features
> >>> sling-org-apache-sling-feature-applicationbuilder
> >>>
>  * feature-io - Deals with reading and writing features to
>  disk
> >>>
> >>> sling-org-apache-sling-feature-io
> >>>
>  * feature-karaf - Turn Features into Karaf Features
> >>>
> >>> sling-org-apache-sling-feature-karaf
> >>>
>  * feature-launch - Launch a Feature-based application
> >>>
> >>> sling-org-apache-sling-feature-launcher
> >>>
>  * feature-modelconverter - Convert between Features and the
>  Sling
> >>>
> >>> Provisioning Model
> >>> sling-org-apache-sling-feature-modelconverter
> >>>
>  * feature-resolver - Resolve Features and contents, can
>  compute
> >
> > ordering
> >>> sling-org-apache-sling-feature-resolver
> >>>
>  * osgifeature-maven-plugin - Similar to slingstart-maven-
>  plugin but
> >
> > then
> >>> for features (maybe this one should be renamed, e.g.
> >>> slingfeature-maven-plugin?)
> >>> So I would suggest to go for sling-slingfeature-maven-plugin
> >>> but if
> >
> > this
> >>> needs additional discussion we can postpone this one for now I
> >>> guess.
> >>>
> >>> Since I'm not a PMC member I can't perform this task, but Karl
> >>> Pauls has
> >>> kindly offered help here. (Thanks Karl!)
> >>>
> >>> Thoughts anyone?
> >>>
> >>> Best 

Re: Assigning JIRA issues to myself

[David Bosschaert]

Thanks Radu!

David

On 1 May 2018 at 09:14, Radu Cotescu  wrote:

> Hi David,
>
> > On 1 May 2018, at 09:31, dav...@apache.org wrote:
> >
> > Although I'm now a committer, I can't yet assign Sling JIRA issues to
> > myself. I guess I don't have the right credentials yet. Could someone
> > please fix that for me?
> >
>
> I’ve added you to the Committers group on JIRA and now you have most of
> the permissions needed for day-to-day work.
>
> Cheers,
> Radu

[jira] [Assigned] (SLING-7535) Make slingstart-maven-plugin understand sling feature model files

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned SLING-7535:
---

Assignee: David Bosschaert

> Make slingstart-maven-plugin understand sling feature model files
> -
>
> Key: SLING-7535
> URL: https://issues.apache.org/jira/browse/SLING-7535
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
>
> It would be great if the slingstart-maven-plugin could support the new sling 
> feature files as being prototyped at 
> https://github.com/apache/sling-whiteboard/tree/master/featuremodel
> Various approaches could be taken, one could be to have a designated 
> directory for feature files, such as /src/main/features where the feature 
> files are stored.



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

Re: Assigning JIRA issues to myself

[Radu Cotescu]

Hi David,

> On 1 May 2018, at 09:31, dav...@apache.org wrote:
> 
> Although I'm now a committer, I can't yet assign Sling JIRA issues to
> myself. I guess I don't have the right credentials yet. Could someone
> please fix that for me?
> 

I’ve added you to the Committers group on JIRA and now you have most of the 
permissions needed for day-to-day work.

Cheers,
Radu

[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

[Csaba Varga (JIRA)]

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

Csaba Varga commented on SLING-3524:


{quote}I think the "needsCloning/needsSudo/explicitSessionUsed" might need some 
explanation in comments, it's not straightforward to follow.
{quote}
Fair point. I've added some comments now. explicitSessionUsed is already 
commented in the Javadoc of handleImpersonation(). Does it need some 
clarification?
{quote}Are all possible combinations covered correctly?
{quote}
I think so, but I've gone through them this morning to double check. I believe 
we have three independent variables to consider, giving eight cases in total:
 * Is it a normal login or is a session given in the auth info? (For this 
variable, I believe we can treat service logins and administrative logins as 
normal logins.)
 * Does the login request impersonation or not?
 * Is the login caused by a clone() call?

This is what happens in the eight cases:

 
||Scenario||No clone||Clone||
|Normal login, no sudo|logoutSession: true
no impersonation call
doLogoutSession: true|logoutSession: true
no impersonation call
doLogoutSession: true|
|Normal login with sudo|logoutSession: true
original session impersonated then closed, USER_IMPERSONATOR set
doLogoutSession: true|logoutSession: true
original session impersonated then closed, USER_IMPERSONATOR set
doLogoutSession: true|
|Session login, no sudo|logoutSession: false
session used as-is
doLogoutSession: false|logoutSession: false
session self-impersonated
doLogoutSession: true|
|Session login with sudo|logoutSession: false
session impersonated, USER_IMPERSONATOR set
doLogoutSession: true|logoutSession: false
session impersonated, USER_IMPERSONATOR set
doLogoutSession: true|

The only case when cloning behavior is different from normal behavior is when 
you pass a session but you don't want to impersonate. If you don't pass a 
session, cloning will just log you in again with your credentials, just like 
before the patch. If you pass a session and you request impersonation, 
session.impersonate() was already called before this patch, and will keep being 
called after it.

Am I missing something? If these are all the factors we need to worry about, do 
you think it's worthwhile to build a parameterized unit test that covers all 
possible combinations?

 

> ResourceResolver.clone(null) should not share the same JCR session
> --
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, ResourceResolver
>Affects Versions: Resource Resolver 1.0.6
>Reporter: Alexander Klimetschek
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was 
> created by passing an existing session using 
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of 
> the resource resolver to pass into a new, separate thread, and use 
> {{ResourceResolver.clone(null)}}, you will actually share the session, but 
> this is not obvious. The problem is that a JCR session cannot be shared 
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to 
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I 
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource 
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return 
> a session that impersonated itself, abstracting this from the resource 
> resolver user. Additionally, it might be worth looking that clone always 
> returns a new session, unless specifically stated.



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

Assigning JIRA issues to myself

[davidb]

Hi all,

Although I'm now a committer, I can't yet assign Sling JIRA issues to
myself. I guess I don't have the right credentials yet. Could someone
please fix that for me?

Many thanks,

David

Re: [Feature Model] Moving the Feature Model out of sling-whiteboard

[Carsten Ziegeler]

Good idea, we usually start with 0.1.0 for such releases. I think to
clearly mark these as pre-versions, the package exports should be
changed from 1.0.0 to 0.1.0. Versions below 1.0 mark them as potentially
unstable.

Once we are happy with these modules and we release a 1.0.0, the package
exports will be changed to 1.0.0

Regards

Carsten


David Bosschaert wrote
> Hi all,
> 
> With the Sling Feature Model now being outside of the Sling Whiteboard in
> proper Git repositories, I'd like to do a an initial release of the
> following components some time soon:
> 
> sling-org-apache-sling-feature
> sling-org-apache-sling-feature-analyser
> sling-org-apache-sling-feature-applicationbuilder
> sling-org-apache-sling-feature-io
> sling-org-apache-sling-feature-karaf
> sling-org-apache-sling-feature-launcher
> sling-org-apache-sling-feature-modelconverter
> sling-org-apache-sling-feature-resolver
> 
> I think it's early days and personally I wouldn't call this release a 1.0.0
> release yet, maybe we can call it 0.2.0 or 0.9.0 or something like this?
> 
> Is there anything that we should do before starting to cut the release?
> 
> Best regards,
> 
> David
> 
> 
> On 27 April 2018 at 12:31, David Bosschaert 
> wrote:
> 
>> Thanks Robert, I moved them there.
>>
>> Best regards,
>>
>> David
>>
>> On 27 April 2018 at 12:23, Robert Munteanu  wrote:
>>
>>> Hi David,
>>>
>>> On Fri, 2018-04-27 at 12:17 +0100, David Bosschaert wrote:
 Thanks Karl!

 I have now moved the content to the new git repositories.

 There is one directory left in sling-whiteboard/featuremodel and
 that's the
 example directory. This would be a nice starting point for user
 documentation etc. Maybe we should create a separate repository for
 this?
 sling-org-apache-sling-feature-examples? Or something else?
>>>
>>> There's already https://github.com/apache/sling-samples/ if you're
>>> looking for an examples/samples reposistory.
>>>
>>> Robert
>>>

 Best regards,

 David

 On 26 April 2018 at 21:56, Karl Pauls  wrote:

> I create the repositories (including the slingfeature-maven-
> plugin).
>
> regards,
>
> Karl
>
> On Thu, Apr 26, 2018 at 8:34 PM, Carsten Ziegeler  .org>
> wrote:
>> Sounds good to me, sling-slingfeature-maven-plugin sounds like a
>> good
>> name as well. As we'll need a plugin at some point, I think it
>> makes
>> sense to create it now already
>>
>> Regards
>>
>> Carsten
>>
>> David Bosschaert wrote
>>> Hi all,
>>>
>>> Thanks all for supporting the idea!
>>>
>>> I would propose the following Git repository names:
>>>
 * feature - The Feature Model API
>>>
>>> sling-org-apache-sling-feature
>>>
 * feature-analyser - Analyser Module for Features
>>>
>>> sling-org-apache-sling-feature-analyser
>>>
 * feature-applicationbuilder - Command line tool for building
>>>
>>> Applications from Features
>>> sling-org-apache-sling-feature-applicationbuilder
>>>
 * feature-io - Deals with reading and writing features to
 disk
>>>
>>> sling-org-apache-sling-feature-io
>>>
 * feature-karaf - Turn Features into Karaf Features
>>>
>>> sling-org-apache-sling-feature-karaf
>>>
 * feature-launch - Launch a Feature-based application
>>>
>>> sling-org-apache-sling-feature-launcher
>>>
 * feature-modelconverter - Convert between Features and the
 Sling
>>>
>>> Provisioning Model
>>> sling-org-apache-sling-feature-modelconverter
>>>
 * feature-resolver - Resolve Features and contents, can
 compute
>
> ordering
>>> sling-org-apache-sling-feature-resolver
>>>
 * osgifeature-maven-plugin - Similar to slingstart-maven-
 plugin but
>
> then
>>> for features (maybe this one should be renamed, e.g.
>>> slingfeature-maven-plugin?)
>>> So I would suggest to go for sling-slingfeature-maven-plugin
>>> but if
>
> this
>>> needs additional discussion we can postpone this one for now I
>>> guess.
>>>
>>> Since I'm not a PMC member I can't perform this task, but Karl
>>> Pauls has
>>> kindly offered help here. (Thanks Karl!)
>>>
>>> Thoughts anyone?
>>>
>>> Best regards,
>>>
>>> David
>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>
>>>
>>>
>>
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org