[jira] [Resolved] (SLING-7228) JsonRendererServlet should not close but flush the response when done.

[Karl Pauls (JIRA)]

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

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

Done in 
https://github.com/apache/sling-org-apache-sling-servlets-get/commit/3fbf470683a9a53f2151e94f86e5ca4121b43bea

> JsonRendererServlet should not close but flush the response when done.
> --
>
> Key: SLING-7228
> URL: https://issues.apache.org/jira/browse/SLING-7228
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.26
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Servlets Get 2.1.30
>
>
> Looks like I added a close to the JsonRendererServlet.doGet instead of a 
> flush in SLING-6683.



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

[jira] [Assigned] (SLING-7228) JsonRendererServlet should not close but flush the response when done.

[Karl Pauls (JIRA)]

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

Karl Pauls reassigned SLING-7228:
-

Assignee: Karl Pauls

> JsonRendererServlet should not close but flush the response when done.
> --
>
> Key: SLING-7228
> URL: https://issues.apache.org/jira/browse/SLING-7228
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.26
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Servlets Get 2.1.30
>
>
> Looks like I added a close to the JsonRendererServlet.doGet instead of a 
> flush in SLING-6683.



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

Re: [VOTE] Release Apache Sling Service User Mapper 1.3.6

[Ian Boston]

+1

On 2 November 2017 at 16:15, Karl Pauls  wrote:

> I would like to call a vote on the following release,
>
> Apache Sling Service User Mapper 1.3.6
>
> We solved 2 issue in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12341841
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1804/
>
> 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 1804 /tmp/sling-staging
>
> Please vote to approve these releases:
>
>   [ ] +1 Approve the releases
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>

[VOTE] Release Apache Sling API 2.16.4, JCR Resource Resolver 3.0.6, Default GET Servlets 2.1.29

[Ian Boston]

Hi,

I would like to call a vote on the following release,

Apache Sling API 2.16.4
Apache Sling JCR Resource Resolver 3.0.6
Apache Sling Default GET Servlets 2.1.29

We solved 11 issue in this release:
*https://issues.apache.org/jira/projects/SLING/versions/12338864
*

*https://issues.apache.org/jira/projects/SLING/versions/12341120
*

*https://issues.apache.org/jira/projects/SLING/versions/12340579
*


Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1805/
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 1805 /tmp/sling-staging

Please vote to approve these releases:

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


Thanks
Ian

[jira] [Updated] (SLING-7228) JsonRendererServlet should not close but flush the response when done.

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-7228:
--
Fix Version/s: (was: Servlets Get 2.1.28)
   Servlets Get 2.1.30

> JsonRendererServlet should not close but flush the response when done.
> --
>
> Key: SLING-7228
> URL: https://issues.apache.org/jira/browse/SLING-7228
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.26
>Reporter: Karl Pauls
> Fix For: Servlets Get 2.1.30
>
>
> Looks like I added a close to the JsonRendererServlet.doGet instead of a 
> flush in SLING-6683.



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

[jira] [Created] (SLING-7228) JsonRendererServlet should not close but flush the response when done.

[Karl Pauls (JIRA)]

Karl Pauls created SLING-7228:
-

 Summary: JsonRendererServlet should not close but flush the 
response when done.
 Key: SLING-7228
 URL: https://issues.apache.org/jira/browse/SLING-7228
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Get 2.1.26
Reporter: Karl Pauls
 Fix For: Servlets Get 2.1.28


Looks like I added a close to the JsonRendererServlet.doGet instead of a flush 
in SLING-6683.



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

[VOTE] Release Apache Sling Service User Mapper 1.3.6

[Karl Pauls]

I would like to call a vote on the following release,

Apache Sling Service User Mapper 1.3.6

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

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

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 1804 /tmp/sling-staging

Please vote to approve these releases:

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

[jira] [Commented] (SLING-7225) Mapping: preserve order of principal names

[angela (JIRA)]

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

angela commented on SLING-7225:
---

[~kpauls], thanks a lot. very much appreciated!

> Mapping: preserve order of principal names 
> ---
>
> Key: SLING-7225
> URL: https://issues.apache.org/jira/browse/SLING-7225
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Service User Mapper 1.3.6
>
> Attachments: mapping.patch
>
>
> while using the new service mapping definition with principal names, I 
> noticed that it might be better to preserve the order of the principal names 
> as defined in the mapping. In particular if the repository login picks one of 
> the configured names for the the {{javax.jcr.Session.getUserID()}}.
> Therefore I would like to propose to slightly change the implementation of 
> {{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.
> [~kpauls], would you mind reviewing the atttached patch and apply it? Thanks 
> a lot!
> cc: [~chaotic]



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

[jira] [Created] (SLING-7227) Repo Init: Add ability to register custom privileges

[angela (JIRA)]

angela created SLING-7227:
-

 Summary: Repo Init: Add ability to register custom privileges
 Key: SLING-7227
 URL: https://issues.apache.org/jira/browse/SLING-7227
 Project: Sling
  Issue Type: Improvement
  Components: Repoinit
Reporter: angela
Priority: Normal


[~marett], [~bdelacretaz], looking at the repo-init source I couldn't find a 
way to register a custom privilege during repo init. I am sure this is an 
oversight and hasn't been omitted intentionally.

The corresponding API calls are:

{code}
JackrabbitWorkspace.getPrivilegeManager()
PrivilegeManager.registerPrivilege(String privilegeName, boolean isAbstract, 
String[] declaredAggregateNames)
{code}

See also
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitWorkspace.java?view=markup
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/authorization/PrivilegeManager.java?view=markup

I would be appreciate if the repo init could have this gap filled. Thanks.



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

[jira] [Created] (SLING-7226) Repo Init: allow to pass intermediate path upon creating service user

[angela (JIRA)]

angela created SLING-7226:
-

 Summary: Repo Init: allow to pass intermediate path upon creating 
service user
 Key: SLING-7226
 URL: https://issues.apache.org/jira/browse/SLING-7226
 Project: Sling
  Issue Type: Improvement
  Components: Repoinit
Reporter: angela
Priority: Normal


[~marett], [~bdelacretaz], if I am not mistaken it is currently not possible to 
pass the second parameter 'intermediatePath' when creating a service user using 
the repo-init.

In the Jackrabbit {{UserManager}} API the call looks as follows:

{code}
UserManager.createSystemUser(String userID, String intermediatePath)
{code}

I would appreciate if both params would be respected by the repo-init and I 
don't think it should be a big deal adding this.

Thanks.



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

[jira] [Resolved] (SLING-7225) Mapping: preserve order of principal names

[Karl Pauls (JIRA)]

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

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

[~anchela], I applied your patch. Thanks! I will call for a 1.3.6 release asap.

> Mapping: preserve order of principal names 
> ---
>
> Key: SLING-7225
> URL: https://issues.apache.org/jira/browse/SLING-7225
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Service User Mapper 1.3.6
>
> Attachments: mapping.patch
>
>
> while using the new service mapping definition with principal names, I 
> noticed that it might be better to preserve the order of the principal names 
> as defined in the mapping. In particular if the repository login picks one of 
> the configured names for the the {{javax.jcr.Session.getUserID()}}.
> Therefore I would like to propose to slightly change the implementation of 
> {{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.
> [~kpauls], would you mind reviewing the atttached patch and apply it? Thanks 
> a lot!
> cc: [~chaotic]



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

[jira] [Updated] (SLING-7225) Mapping: preserve order of principal names

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-7225:
--
Fix Version/s: Service User Mapper 1.3.6

> Mapping: preserve order of principal names 
> ---
>
> Key: SLING-7225
> URL: https://issues.apache.org/jira/browse/SLING-7225
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Service User Mapper 1.3.6
>
> Attachments: mapping.patch
>
>
> while using the new service mapping definition with principal names, I 
> noticed that it might be better to preserve the order of the principal names 
> as defined in the mapping. In particular if the repository login picks one of 
> the configured names for the the {{javax.jcr.Session.getUserID()}}.
> Therefore I would like to propose to slightly change the implementation of 
> {{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.
> [~kpauls], would you mind reviewing the atttached patch and apply it? Thanks 
> a lot!
> cc: [~chaotic]



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

[jira] [Updated] (SLING-7225) Mapping: preserve order of principal names

[Karl Pauls (JIRA)]

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

Karl Pauls updated SLING-7225:
--
Affects Version/s: Service User Mapper 1.3.4

> Mapping: preserve order of principal names 
> ---
>
> Key: SLING-7225
> URL: https://issues.apache.org/jira/browse/SLING-7225
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.3.4
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Service User Mapper 1.3.6
>
> Attachments: mapping.patch
>
>
> while using the new service mapping definition with principal names, I 
> noticed that it might be better to preserve the order of the principal names 
> as defined in the mapping. In particular if the repository login picks one of 
> the configured names for the the {{javax.jcr.Session.getUserID()}}.
> Therefore I would like to propose to slightly change the implementation of 
> {{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.
> [~kpauls], would you mind reviewing the atttached patch and apply it? Thanks 
> a lot!
> cc: [~chaotic]



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

[jira] [Resolved] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6609.

Resolution: Fixed

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Commented] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6609:


Fixed with 
https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-api.git;a=commit;h=b35b5d1af152f0e28d87af6da8eba84df0e72a10.
 Sorry for that mistake.

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Reopened] (SLING-6609) Fix JSR305 annotations for ValueMap.get

[Ian Boston (JIRA)]

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

Ian Boston reopened SLING-6609:
---

mvn clean javadoc:javadoc fails, due to this commit blocking releasing the 
bundle.

Could you fix please. 
The JavaDoc didn't make sense as there is no get(String) method.

{code}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 13.165 s
[INFO] Finished at: 2017-11-02T14:32:34+00:00
[INFO] Final Memory: 27M/385M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:javadoc (default-cli) on 
project org.apache.sling.api: An error has occurred in JavaDocs report 
generation:
[ERROR] Exit code: 1 - 
/Users/ieb/sling/sling-org-apache-sling-api/src/main/java/org/apache/sling/api/resource/ValueMap.java:77:
 error: reference not found
[ERROR] * Therefore all implementations should internally call {@link 
#get(String)} when the 2nd parameter
[ERROR] ^
[ERROR] 
/Users/ieb/sling/sling-org-apache-sling-api/src/main/java/org/apache/sling/api/resource/ValueMap.java:90:
 warning - Tag @link: can't find get(String) in 
org.apache.sling.api.resource.ValueMap
[ERROR] 
[ERROR] Command line was: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/../bin/javadoc
 @options @packages
[ERROR] 

{code}

> Fix JSR305 annotations for ValueMap.get
> ---
>
> Key: SLING-6609
> URL: https://issues.apache.org/jira/browse/SLING-6609
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.16.4
>
>
> Currently {{ T get(@Nonnull String name, T defaultValue);}} does neither 
> define a JSR 305 annotation for the return value nor for the 2nd parameter. 
> It makes sense to define them both as {{@Nonnull}}, because if you intend to 
> get {{null}} as return value you are supposed to take the other get method 
> ({{@CheckForNull  T get(@Nonnull String name, @Nonnull Class type)}})



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

[jira] [Assigned] (SLING-7225) Mapping: preserve order of principal names

[Karl Pauls (JIRA)]

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

Karl Pauls reassigned SLING-7225:
-

Assignee: Karl Pauls

> Mapping: preserve order of principal names 
> ---
>
> Key: SLING-7225
> URL: https://issues.apache.org/jira/browse/SLING-7225
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Reporter: angela
>Assignee: Karl Pauls
>Priority: Major
> Attachments: mapping.patch
>
>
> while using the new service mapping definition with principal names, I 
> noticed that it might be better to preserve the order of the principal names 
> as defined in the mapping. In particular if the repository login picks one of 
> the configured names for the the {{javax.jcr.Session.getUserID()}}.
> Therefore I would like to propose to slightly change the implementation of 
> {{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.
> [~kpauls], would you mind reviewing the atttached patch and apply it? Thanks 
> a lot!
> cc: [~chaotic]



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

[jira] [Commented] (SLING-7197) Completed Scheduled Jobs are not getting fetched

[ASF GitHub Bot (JIRA)]

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

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

prafulVaishnav commented on issue #1: SLING-7197 Completed Scheduled Jobs are 
not getting fetched.
URL: 
https://github.com/apache/sling-org-apache-sling-event/pull/1#issuecomment-341401438
 
 
   Thanks @cziegeler. I need to get this fix in AEM so it would require a 
release. @cziegeler @rombert Can you please release this bundle so as to 
include it in AEM QS.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Completed Scheduled Jobs are not getting fetched
> 
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Event 4.2.10
>
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Commented] (SLING-7197) Completed Scheduled Jobs are not getting fetched

[ASF GitHub Bot (JIRA)]

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

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

prafulVaishnav commented on issue #1: SLING-7197 Completed Scheduled Jobs are 
not getting fetched.
URL: 
https://github.com/apache/sling-org-apache-sling-event/pull/1#issuecomment-341401438
 
 
   Thanks @cziegeler. I need to get this fix in AEM so it would require a 
release.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Completed Scheduled Jobs are not getting fetched
> 
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Event 4.2.10
>
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Created] (SLING-7225) Mapping: preserve order of principal names

[angela (JIRA)]

angela created SLING-7225:
-

 Summary: Mapping: preserve order of principal names 
 Key: SLING-7225
 URL: https://issues.apache.org/jira/browse/SLING-7225
 Project: Sling
  Issue Type: Improvement
  Components: Service User Mapper
Reporter: angela
Priority: Major
 Attachments: mapping.patch

while using the new service mapping definition with principal names, I noticed 
that it might be better to preserve the order of the principal names as defined 
in the mapping. In particular if the repository login picks one of the 
configured names for the the {{javax.jcr.Session.getUserID()}}.

Therefore I would like to propose to slightly change the implementation of 
{{Mapping.extractPrincipalNames}} to use a {{LinkedHashSet}}.

[~kpauls], would you mind reviewing the atttached patch and apply it? Thanks a 
lot!

cc: [~chaotic]



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

[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-3049:


Thanks [~karlpauls] for the feedback

bq. Obviously, it suffers a little from not being able to get to the real 
classes - i.e., it will not report on classes that are provided from more than 
one bundle

Yes. If same package is loaded by multiple bundles then this impl would not 
provide any info. But in most cases the packages are unique so should be ok for 
Sling like setup

bq.  I guess the only question I would have is if this could be problematic for 
tools/scripts/others that rely on a certain layout of a stacktrace. Not sure 
that is important. 

I mostly use Intellij Stacktrace Analyzer and it is able to work with that

bq. I suppose you could use some bytecode magic to weave the information about 
the bundle source into the "Source" field of the class and parse it out later 
when you need it but that probably isn't a good idea

That would be really cool and nifty use of weaving hook!. But for some other 
day :)

> Make Logback Stacktrace Packaging data support OSGi aware
> -
>
> Key: SLING-3049
> URL: https://issues.apache.org/jira/browse/SLING-3049
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
>  Labels: logback
> Attachments: SLING-3049.patch, 
> buildbot-exceptions-while-stopping-jetty.txt
>
>
> Logback provides a useful feature where it dumps the Class packaging Data 
> along with the stacktrace [1]. This provides a quick view of the location 
> from where classes in a given stacktrace are coming. Its default logic does 
> not work properly in OSGi env. Hence it would be useful to patch its logic to 
> become OSGi aware
> [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData



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

[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-3049:
---

[~chetanm], I think this looks good implementation wise. 

Obviously, it suffers a little from not being able to get to the real classes - 
i.e., it will not report on classes that are provided from more than one 
bundle. Furthermore, the weaving hook approach will require this bundle to be 
started as early as possible. However, I can't think of a better way to achieve 
this from the top of my head* and fwiw, the weaving hook implementation looks 
good (i.e., it doesn't synchronize and loads all classes upfront). I guess the 
only question I would have is if this could be problematic for 
tools/scripts/others that rely on a certain layout of a stacktrace. Not sure 
that is important. 

Otherwise, I'm happy with it - nice job.

* I suppose you could use some bytecode magic to weave the information about 
the bundle source into the "Source" field of the class and parse it out later 
when you need it but that probably isn't a good idea :-)

> Make Logback Stacktrace Packaging data support OSGi aware
> -
>
> Key: SLING-3049
> URL: https://issues.apache.org/jira/browse/SLING-3049
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
>  Labels: logback
> Attachments: SLING-3049.patch, 
> buildbot-exceptions-while-stopping-jetty.txt
>
>
> Logback provides a useful feature where it dumps the Class packaging Data 
> along with the stacktrace [1]. This provides a quick view of the location 
> from where classes in a given stacktrace are coming. Its default logic does 
> not work properly in OSGi env. Hence it would be useful to patch its logic to 
> become OSGi aware
> [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData



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

[jira] [Comment Edited] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on SLING-3049 at 11/2/17 9:27 AM:


[~chetanm], I think this looks good implementation wise. 

Obviously, it suffers a little from not being able to get to the real classes - 
i.e., it will not report on classes that are provided from more than one 
bundle. Furthermore, the weaving hook approach will require this bundle to be 
started as early as possible. However, I can't think of a better way to achieve 
this from the top of my head[0] and fwiw, the weaving hook implementation looks 
good (i.e., it doesn't synchronize and loads all classes upfront). I guess the 
only question I would have is if this could be problematic for 
tools/scripts/others that rely on a certain layout of a stacktrace. Not sure 
that is important. 

Otherwise, I'm happy with it - nice job.

[0] I suppose you could use some bytecode magic to weave the information about 
the bundle source into the "Source" field of the class and parse it out later 
when you need it but that probably isn't a good idea :-)


was (Author: karlpauls):
[~chetanm], I think this looks good implementation wise. 

Obviously, it suffers a little from not being able to get to the real classes - 
i.e., it will not report on classes that are provided from more than one 
bundle. Furthermore, the weaving hook approach will require this bundle to be 
started as early as possible. However, I can't think of a better way to achieve 
this from the top of my head* and fwiw, the weaving hook implementation looks 
good (i.e., it doesn't synchronize and loads all classes upfront). I guess the 
only question I would have is if this could be problematic for 
tools/scripts/others that rely on a certain layout of a stacktrace. Not sure 
that is important. 

Otherwise, I'm happy with it - nice job.

* I suppose you could use some bytecode magic to weave the information about 
the bundle source into the "Source" field of the class and parse it out later 
when you need it but that probably isn't a good idea :-)

> Make Logback Stacktrace Packaging data support OSGi aware
> -
>
> Key: SLING-3049
> URL: https://issues.apache.org/jira/browse/SLING-3049
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
>  Labels: logback
> Attachments: SLING-3049.patch, 
> buildbot-exceptions-while-stopping-jetty.txt
>
>
> Logback provides a useful feature where it dumps the Class packaging Data 
> along with the stacktrace [1]. This provides a quick view of the location 
> from where classes in a given stacktrace are coming. Its default logic does 
> not work properly in OSGi env. Hence it would be useful to patch its logic to 
> become OSGi aware
> [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData



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

[jira] [Resolved] (SLING-7197) Completed Scheduled Jobs are not getting fetched

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-7197.
-
Resolution: Fixed

Thanks for the patch, it's applied

> Completed Scheduled Jobs are not getting fetched
> 
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Event 4.2.10
>
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Assigned] (SLING-7197) Completed Scheduled Jobs are not getting fetched

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-7197:
---

Assignee: Carsten Ziegeler

> Completed Scheduled Jobs are not getting fetched
> 
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Event 4.2.10
>
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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

[jira] [Commented] (SLING-7197) Completed Scheduled Jobs are not getting fetched

[ASF GitHub Bot (JIRA)]

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

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

cziegeler closed pull request #1: SLING-7197 Completed Scheduled Jobs are not 
getting fetched.
URL: https://github.com/apache/sling-org-apache-sling-event/pull/1
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java
 
b/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java
index 01ca010..0df2a9c 100644
--- 
a/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java
+++ 
b/src/main/java/org/apache/sling/event/impl/jobs/scheduling/ScheduledJobHandler.java
@@ -28,6 +28,7 @@
 import java.util.concurrent.atomic.AtomicBoolean;
 import java.util.concurrent.atomic.AtomicLong;
 
+import org.apache.jackrabbit.JcrConstants;
 import org.apache.sling.api.resource.ModifiableValueMap;
 import org.apache.sling.api.resource.PersistenceException;
 import org.apache.sling.api.resource.Resource;
@@ -295,6 +296,7 @@ private ScheduledJobInfoImpl addOrUpdateScheduledJob(
 properties.remove(ResourceResolver.PROPERTY_RESOURCE_TYPE);
 properties.remove(Job.PROPERTY_JOB_CREATED);
 properties.remove(Job.PROPERTY_JOB_CREATED_INSTANCE);
+properties.remove(JcrConstants.JCR_PRIMARYTYPE);
 
 final String jobTopic = (String) 
properties.remove(ResourceHelper.PROPERTY_JOB_TOPIC);
 final String schedulerName = (String) 
properties.remove(ResourceHelper.PROPERTY_SCHEDULE_NAME);


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Completed Scheduled Jobs are not getting fetched
> 
>
> Key: SLING-7197
> URL: https://issues.apache.org/jira/browse/SLING-7197
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: Event 4.2.8
>Reporter: Praful Vaishnav
>Priority: Major
> Fix For: Event 4.2.10
>
>
> Scheuled jobs are created as _slingevent:TimedEvent_ under path 
> _/var/eventing/scheduled-jobs_. When these jobs execution are complete, they 
> are moved under path `/var/eventing/jobs/finished`. Prior to completion, we 
> can get scheduled jobs using [API JobManager.getScheduledJobs|  
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#getScheduledJobs-java.lang.String-long-java.util.Map...-
>  ]. But I could not find any API to get scheduled jobs which are completed. 
> [API JobManager.findJobs| 
> https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/JobManager.html#findJobs-org.apache.sling.event.jobs.JobManager.QueryType-java.lang.String-long-java.util.Map...-]
>  returns only jobs of type _slingevent:Job_



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