[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5512:
--

The use case I am concerned with is Content Distribution queues, and the 
scalability of the UI when there are a lot of packages to distribute. But I 
think we can use limits in UI not to display more than 1000 jobs.

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Deprecating the jcr resource API

[Antonio Sanso]

+1 on deprecating 
On Feb 12, 2016, at 7:50 AM, Carsten Ziegeler  wrote:

> Hi,
> 
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
> 
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
> 
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
> 
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.
> 
> If no one objects, I'll deprecated JcrResourceUtil completely.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Sling Scripting Core 2.0.36

[Radu Cotescu]

Hi,

Can one more member of the PMC please verify the staged artifacts?

Thanks,
Radu

On Thu, 11 Feb 2016 at 16:38 Robert Munteanu  wrote:

> On Tue, 2016-02-09 at 10:28 +, Radu Cotescu wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert

RE: [VOTE] Release Apache Sling Scripting Core 2.0.36

[Stefan Seifert]

+1

[jira] [Created] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

Marius Petria created SLING-5512:


 Summary: Improve JobManager.findJobs querying by supporting skip 
items
 Key: SLING-5512
 URL: https://issues.apache.org/jira/browse/SLING-5512
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Marius Petria


Currently findJobs API only accepts a limit parameter to restrict the size of 
the retrieved collection. In order to better support paged views of jobs we 
should also support a skip parameter. 

Also it would be very useful to have a countJobs API aswell.

[1] 
https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5512:
-

I'm not sure about these operations - even findJobs is already borderline. The 
problem I see is that the more functionality we add, the more we have to 
support in the future. Let's assume we move to a totally different queuing 
mechanism which doesn't provide this functionality, then having this in the API 
gets in the way.
The other problem is, right now, we neither have a way to count or skip when 
using the Sling Resource API

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Deprecating the jcr resource API

[Konrad Windszus]

+1 on deprecating this class.

> On 12 Feb 2016, at 07:50, Carsten Ziegeler  wrote:
> 
> Hi,
> 
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
> 
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
> 
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
> 
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.
> 
> If no one objects, I'll deprecated JcrResourceUtil completely.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5512:
--

The problem is that without these APIs visualization/counting of jobs becomes 
quite expensive in cases of tens of thousands of jobs. In order to still be 
efficient one needs to store a parallel collection of nodes that represent the 
jobs for visualization and keep it in sync with the job items. Is that the 
preferred alternative?

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5512:
-

I think visualization shouldn't been done with thousands of jobs. What is the 
real use case behind it here?

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5468) Resource Merger: Provide a way to completely replace the underlying resources

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5468.

Resolution: Fixed

Applied a slightly modified fix in [r1729965|http://svn.apache.org/r1729965].

> Resource Merger: Provide a way to completely replace the underlying resources
> -
>
> Key: SLING-5468
> URL: https://issues.apache.org/jira/browse/SLING-5468
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.2.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Resource Merger 1.3.2
>
> Attachments: SLING-5468-v1.patch, SLING-5468-v2.patch
>
>
> Currently whenever the mount point of the {{MergingResourcePicker}} 
> (/mnt/overlay) or {{OverridingResourcePicker}} (/mnt/override) is used, the 
> merging always takes place. It is only possible to hide/modify individual 
> resource/properties of the underlying resources but not to completely disable 
> the inheritance (and by that replace the whole overriden/overlaid resource).
> A concrete usecase for that is in a CMS (e.g. AEM) where the dialog 
> definitions are always loaded via /mnt/override/. In that case 
> it is not easily possible to completely replace the dialog of the resource 
> super type (as only individual child resources or properties can be hidden 
> but there is no special property to ignore the inherited resource 
> alltogether).
> I propose the following:
> Add a new property {{sling:disregardInheritedResource=true}} in which case 
> all the inherited resources would not be taken into account for merging.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4915) Order of sub-nodes is not maintained in case of a merge

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-4915:


Removed some no longer needed code in [r1729983|http://svn.apache.org/r1729983].

> Order of sub-nodes is not maintained in case of a merge
> ---
>
> Key: SLING-4915
> URL: https://issues.apache.org/jira/browse/SLING-4915
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Merger 1.2.10
>Reporter: Radu Cotescu
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Merger 1.3.2
>
>
> Given two content structures that should be merged by the Resource Merger, if 
> the second tree contains all the sub-nodes of the first tree, a new node 
> added in the second tree will always be added towards the end, irrespective 
> of its position in the sub-node tree.
> Example:
> {noformat}
> /libs/p1/components/c1
>   node1
>   node2
>   node3
> /libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
>   node1
>   node4
>   node2
>   node3
> {noformat}
> When iterating over the child resources of {{/libs/p2/components/c1}}, 
> {{node4}} will be the last child in the iteration instead of the second.
> The workaround is to not define the redundant nodes and add the 
> {{sling:orderBefore}} property on {{node4}}, however this should be handled 
> by default by the merger.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5513) Deprecate JcrResourceUtil

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5513.
-
Resolution: Fixed

Deprecated JcrResourceUtil

> Deprecate JcrResourceUtil
> -
>
> Key: SLING-5513
> URL: https://issues.apache.org/jira/browse/SLING-5513
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Affects Versions: JCR Resource 2.7.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.7.2
>
>
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT][VOTE] Release Apache Sling Scripting Core 2.0.36

[Radu Cotescu]

Hello,

The vote passed with 3 +1 from: Stefan Egli, Robert Munteanu and Stefan
Seifert. I'll start promoting the release ASAP.

@PMC, can you please move the artifacts to dist?

Thanks,
Radu

Re: Build failed in Jenkins: sling-contrib-1.7 #784

[Robert Munteanu]

On Fri, 2016-02-12 at 11:28 +, Apache Jenkins Server wrote:
> [ERROR] Failed to execute goal on project
> org.apache.sling.distribution.extensions: Could not resolve
> dependencies for project
> org.apache.sling:org.apache.sling.distribution.extensions:bundle:0.0.
> 9-SNAPSHOT: Could not find artifact
> org.apache.sling:org.apache.sling.distribution.core:jar:0.1.13-
> SNAPSHOT in Nexus (http://repository.apache.org/snapshots) -> [Help
> 1]

Looks like the distribution dependencies are out of sync, can someone
look into it?

Thanks,

Robert

Re: [RESULT][VOTE] Release Apache Sling Scripting Core 2.0.36

[Radu Cotescu]

All done. Thanks for the help, Stefan!

On Fri, 12 Feb 2016 at 13:34 Stefan Seifert  wrote:

>
> >@PMC, can you please move the artifacts to dist?
>
> will do.
>
> please take yourself care of site update, OBR update and maven repository
> upload.
>
> stefan
>

[jira] [Created] (SLING-5514) Remove dependency to jcr. resource bundle

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5514:
---

 Summary: Remove dependency to jcr. resource bundle
 Key: SLING-5514
 URL: https://issues.apache.org/jira/browse/SLING-5514
 Project: Sling
  Issue Type: Task
  Components: Scripting
Affects Versions: Scripting JavaScript 2.0.28
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Scripting JavaScript 2.0.30


As JcrResourceUtil is deprecated, we should remove the dependency to it



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5514) Remove dependency to jcr. resource bundle

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5514.
-
Resolution: Fixed

Done in rev 1729986

> Remove dependency to jcr. resource bundle
> -
>
> Key: SLING-5514
> URL: https://issues.apache.org/jira/browse/SLING-5514
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.28
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Scripting JavaScript 2.0.30
>
>
> As JcrResourceUtil is deprecated, we should remove the dependency to it



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [RESULT][VOTE] Release Apache Sling Scripting Core 2.0.36

[Stefan Seifert]

dist updated

Completed: At revision: 12369  


>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Friday, February 12, 2016 1:35 PM
>To: dev@sling.apache.org
>Subject: RE: [RESULT][VOTE] Release Apache Sling Scripting Core 2.0.36
>
>
>>@PMC, can you please move the artifacts to dist?
>
>will do.
>
>please take yourself care of site update, OBR update and maven repository
>upload.
>
>stefan

[jira] [Resolved] (SLING-5512) Improve JobManager.findJobs querying by supporting skip items

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5512.
--
Resolution: Won't Fix

OK, I will close it as won't fix and display only some items from the queue.

> Improve JobManager.findJobs querying by supporting skip items
> -
>
> Key: SLING-5512
> URL: https://issues.apache.org/jira/browse/SLING-5512
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Marius Petria
>
> Currently findJobs API only accepts a limit parameter to restrict the size of 
> the retrieved collection. In order to better support paged views of jobs we 
> should also support a skip parameter. 
> Also it would be very useful to have a countJobs API aswell.
> [1] 
> https://sling.apache.org/apidocs/sling8/org/apache/sling/event/jobs/JobManager.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4915) Order of sub-nodes is not maintained in case of a merge

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-4915.

Resolution: Fixed

Fixed by [r1729981|http://svn.apache.org/r1729981].

> Order of sub-nodes is not maintained in case of a merge
> ---
>
> Key: SLING-4915
> URL: https://issues.apache.org/jira/browse/SLING-4915
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Merger 1.2.10
>Reporter: Radu Cotescu
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Merger 1.3.2
>
>
> Given two content structures that should be merged by the Resource Merger, if 
> the second tree contains all the sub-nodes of the first tree, a new node 
> added in the second tree will always be added towards the end, irrespective 
> of its position in the sub-node tree.
> Example:
> {noformat}
> /libs/p1/components/c1
>   node1
>   node2
>   node3
> /libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
>   node1
>   node4
>   node2
>   node3
> {noformat}
> When iterating over the child resources of {{/libs/p2/components/c1}}, 
> {{node4}} will be the last child in the iteration instead of the second.
> The workaround is to not define the redundant nodes and add the 
> {{sling:orderBefore}} property on {{node4}}, however this should be handled 
> by default by the merger.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5513) Deprecate JcrResourceUtil

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5513:
---

 Summary: Deprecate JcrResourceUtil
 Key: SLING-5513
 URL: https://issues.apache.org/jira/browse/SLING-5513
 Project: Sling
  Issue Type: Task
  Components: JCR
Affects Versions: JCR Resource 2.7.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.7.2


I think we should deprecate the jcr resource API completely, most of it
is already deprecated. Deprecating will allow us to get rid of it in the
future and reduce the parts we have to maintain.

Most of that API is very old and was created in a time where we didn't
have CRUD support for resources. Now that we have this for some time,
there shouldn't be a need for any of this API. And if so, jackrabbit
would be a much better place.

Right now, we still have not deprecated:
JcrResourceUtil#query - Resource Resolver should be used instead.
JcrResourceUtil#toJavaObject - Value Map should be used instead.
JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
used instead

This leaves us with some constants in JcrResourceConstants. Although I
would love to get rid of them to not have any API at all in the jcr
resource bundle, some of them are really related to the jcr resource
provider.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [RESULT][VOTE] Release Apache Sling Scripting Core 2.0.36

[Stefan Seifert]

>@PMC, can you please move the artifacts to dist?

will do.

please take yourself care of site update, OBR update and maven repository 
upload.

stefan

[jira] [Created] (SLING-5515) Configurable validation of log filenames

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-5515:
--

 Summary: Configurable validation of log filenames
 Key: SLING-5515
 URL: https://issues.apache.org/jira/browse/SLING-5515
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor


For consistency it can be useful to enforce some validation on the names of the 
log files that can be configured in Sling.

By default (overridable by configuration) we might require log filenames to end 
in {{.log}} and restrict their character set to ASCII chars, underscore, slash, 
dash and single dot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Clarification on Sling Parameter Handlling

[Konrad Windszus]

I added that information about Servlet Spec 3.0 to 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#servlet-api.
Also I extended the information on not calling Servlet Spec parameter methods 
from within Sling in 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#effects-of-sling-on-servlet-api-parameter-methods.

> On 12 Feb 2016, at 17:22, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> Hi,
>> I would like to clarify few things on 
>> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html
>>  but quickly wanted to check here first if no one opposes.
>> 
>> 1. Since Servlet Spec 3.0 there was support for multipart requests being 
>> added (through HttpServletRequest.getParts()), therefore the arguments in 
>> the section 
>> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#servlet-api
>>  should be clarified.
>> 
>> 2. From within Sling Servlets/Scripts you can no longer rely on the original 
>> Servlet API handling of parameters, because all servlet spec methods dealing 
>> with parameters like getParameter(String), getParameterNames(), 
>> getParameterValues(), getParameterMap() are now internally relying on the 
>> Sling Parameter Support (instead of relying on the underlying servlet engine 
>> for that matter). I would like to add that information to the section 
>> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#sling-api.
>> 
>> 3. Also I would like to clarify that relying on 
>> HttpServletRequest#getInputStream() within Sling and also on third party 
>> libs internally using it (like Apache Commons Fileupload) is in most of the 
>> cases not working, since the parameter support of Sling exclusively needs 
>> access to that input stream (it either has consumed it already or is 
>> probably trying to do that afterwards to extract the parameters).
>> 
>> Is everyone fine, if I add that information to 
>> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html
>> 
> Lgtm, thanks Konrad
> 
> Carsten
> 
>> Konrad
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2][3]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
> [3] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2][3]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
[3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2][3]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127
> [3]http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupportHttpServletRequestWrapper.java?view=markup#l59



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Clarification on Sling Parameter Handlling

[Carsten Ziegeler]

Konrad Windszus wrote
> Hi,
> I would like to clarify few things on 
> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html
>  but quickly wanted to check here first if no one opposes.
> 
> 1. Since Servlet Spec 3.0 there was support for multipart requests being 
> added (through HttpServletRequest.getParts()), therefore the arguments in the 
> section 
> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#servlet-api
>  should be clarified.
> 
> 2. From within Sling Servlets/Scripts you can no longer rely on the original 
> Servlet API handling of parameters, because all servlet spec methods dealing 
> with parameters like getParameter(String), getParameterNames(), 
> getParameterValues(), getParameterMap() are now internally relying on the 
> Sling Parameter Support (instead of relying on the underlying servlet engine 
> for that matter). I would like to add that information to the section 
> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#sling-api.
> 
> 3. Also I would like to clarify that relying on 
> HttpServletRequest#getInputStream() within Sling and also on third party libs 
> internally using it (like Apache Commons Fileupload) is in most of the cases 
> not working, since the parameter support of Sling exclusively needs access to 
> that input stream (it either has consumed it already or is probably trying to 
> do that afterwards to extract the parameters).
> 
> Is everyone fine, if I add that information to 
> https://sling.apache.org/documentation/the-sling-engine/request-parameters.html
> 
Lgtm, thanks Konrad

Carsten

> Konrad
> 


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

[jira] [Created] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-5516:
---

 Summary: ParameterSupportHttpServletRequestWrapper is not conform 
to Servlet API 3.0
 Key: SLING-5516
 URL: https://issues.apache.org/jira/browse/SLING-5516
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Engine 2.4.6
Reporter: Dirk Rudolph
Priority: Minor


According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2].

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5516) ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-5516:

Description: 
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2]. Not 
completely sure if this applies to the other exception types as well but i 
think so.

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127

  was:
According to \[1\] HttpServletRequest#getParts() and 
HttpServletRequest#getPart(String) throw ServletExceptions in case the request 
ist not a {{multpart/}} request.

In the Sling Engine implementation this seems not to be the case [2].

\[1\] 
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
\[2\] 
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127


> ParameterSupportHttpServletRequestWrapper is not conform to Servlet API 3.0
> ---
>
> Key: SLING-5516
> URL: https://issues.apache.org/jira/browse/SLING-5516
> Project: Sling
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: Engine 2.4.6
>Reporter: Dirk Rudolph
>Priority: Minor
>
> According to \[1\] HttpServletRequest#getParts() and 
> HttpServletRequest#getPart(String) throw ServletExceptions in case the 
> request ist not a {{multpart/}} request.
> In the Sling Engine implementation this seems not to be the case [2]. Not 
> completely sure if this applies to the other exception types as well but i 
> think so.
> \[1\] 
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getParts--
> \[2\] 
> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterMap.java?view=markup#l127



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Build failed in Jenkins: sling-contrib-1.7 #784

[Tommaso Teofili]

it should be fixed in r1730042, thanks Robert for the heads up.

Regards,
Tommaso

Il giorno ven 12 feb 2016 alle ore 13:52 Robert Munteanu 
ha scritto:

> On Fri, 2016-02-12 at 11:28 +, Apache Jenkins Server wrote:
> > [ERROR] Failed to execute goal on project
> > org.apache.sling.distribution.extensions: Could not resolve
> > dependencies for project
> > org.apache.sling:org.apache.sling.distribution.extensions:bundle:0.0.
> > 9-SNAPSHOT: Could not find artifact
> > org.apache.sling:org.apache.sling.distribution.core:jar:0.1.13-
> > SNAPSHOT in Nexus (http://repository.apache.org/snapshots) -> [Help
> > 1]
>
> Looks like the distribution dependencies are out of sync, can someone
> look into it?
>
> Thanks,
>
> Robert
>

Clarification on Sling Parameter Handlling

[Konrad Windszus]

Hi,
I would like to clarify few things on 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html 
but quickly wanted to check here first if no one opposes.

1. Since Servlet Spec 3.0 there was support for multipart requests being added 
(through HttpServletRequest.getParts()), therefore the arguments in the section 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#servlet-api
 should be clarified.

2. From within Sling Servlets/Scripts you can no longer rely on the original 
Servlet API handling of parameters, because all servlet spec methods dealing 
with parameters like getParameter(String), getParameterNames(), 
getParameterValues(), getParameterMap() are now internally relying on the Sling 
Parameter Support (instead of relying on the underlying servlet engine for that 
matter). I would like to add that information to the section 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#sling-api.

3. Also I would like to clarify that relying on 
HttpServletRequest#getInputStream() within Sling and also on third party libs 
internally using it (like Apache Commons Fileupload) is in most of the cases 
not working, since the parameter support of Sling exclusively needs access to 
that input stream (it either has consumed it already or is probably trying to 
do that afterwards to extract the parameters).

Is everyone fine, if I add that information to 
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html

Konrad

[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-5274 at 2/13/16 1:55 AM:
---

Thanks Bertrand for SLING-5489 
([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]),
 it's a good start.

For the record, here are the other features in my patch that aren't covered and 
that might be useful:
* include requests with authentication failures in the request history console
** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of 
handleSecurity() when it returns false; also required some changes in 
RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and 
getPathInfo(), plus appropriate logging in handleSecurity()
* more detailed logging inside SlingAuthenticator for the individual 
authentication steps

AFAICS, these changes shouldn't depend on the switch to the OSGi http 
whiteboard implementation, but I don't know for sure.


was (Author: alexander.klimetschek):
Thanks Bertrand for SLING-5489, it's a good start.

For the record, here are the other features in my patch that aren't covered and 
that might be useful:
* include requests with authentication failures in the request history console
** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of 
handleSecurity() when it returns false; also required some changes in 
RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and 
getPathInfo(), plus appropriate logging in handleSecurity()
* more detailed logging inside SlingAuthenticator for the individual 
authentication steps

AFAICS, these changes shouldn't depend on the switch to the OSGi http 
whiteboard implementation, but I don't know for sure.

> Include authentication in RequestProgressTracker
> 
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5274-bertrand.patch, SLING-5274.patch
>
>
> The request progress tracker only starts with the sling filters, after the 
> sling authentication ran through. Since authentication steps can be complex 
> with multiple handlers (just like filters) and can have a major performance 
> impact (custom auth handlers, slow resource resolver login) it would be very 
> useful to include it with detailed information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5274) Include authentication in RequestProgressTracker

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-5274 at 2/13/16 1:55 AM:
---

Thanks Bertrand for SLING-5489 
([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]),
 it's a good start.

For the record, here are the other features in my patch that might be useful:
* include requests with authentication failures in the request history console
** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of 
handleSecurity() when it returns false; also required some changes in 
RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and 
getPathInfo(), plus appropriate logging in handleSecurity()
* more detailed logging inside SlingAuthenticator for the individual 
authentication steps

AFAICS, these changes shouldn't depend on the switch to the OSGi http 
whiteboard implementation, but I don't know for sure.


was (Author: alexander.klimetschek):
Thanks Bertrand for SLING-5489 
([331ff05a|https://github.com/apache/sling/commit/331ff05a157455c8a030b5afe3fa2299ef8539ce]),
 it's a good start.

For the record, here are the other features in my patch that aren't covered and 
that might be useful:
* include requests with authentication failures in the request history console
** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of 
handleSecurity() when it returns false; also required some changes in 
RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and 
getPathInfo(), plus appropriate logging in handleSecurity()
* more detailed logging inside SlingAuthenticator for the individual 
authentication steps

AFAICS, these changes shouldn't depend on the switch to the OSGi http 
whiteboard implementation, but I don't know for sure.

> Include authentication in RequestProgressTracker
> 
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5274-bertrand.patch, SLING-5274.patch
>
>
> The request progress tracker only starts with the sling filters, after the 
> sling authentication ran through. Since authentication steps can be complex 
> with multiple handlers (just like filters) and can have a major performance 
> impact (custom auth handlers, slow resource resolver login) it would be very 
> useful to include it with detailed information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5274) Include authentication in RequestProgressTracker

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-5274:
--

Thanks Bertrand for SLING-5489, it's a good start.

For the record, here are the other features in my patch that aren't covered and 
that might be useful:
* include requests with authentication failures in the request history console
** done using RequestHistoryConsolePlugin.recordRequest(request) at the end of 
handleSecurity() when it returns false; also required some changes in 
RequestHistoryConsolePlugin to not rely on SlingHttpServletRequest and 
getPathInfo(), plus appropriate logging in handleSecurity()
* more detailed logging inside SlingAuthenticator for the individual 
authentication steps

AFAICS, these changes shouldn't depend on the switch to the OSGi http 
whiteboard implementation, but I don't know for sure.

> Include authentication in RequestProgressTracker
> 
>
> Key: SLING-5274
> URL: https://issues.apache.org/jira/browse/SLING-5274
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Reporter: Alexander Klimetschek
> Attachments: SLING-5274-bertrand.patch, SLING-5274.patch
>
>
> The request progress tracker only starts with the sling filters, after the 
> sling authentication ran through. Since authentication steps can be complex 
> with multiple handlers (just like filters) and can have a major performance 
> impact (custom auth handlers, slow resource resolver login) it would be very 
> useful to include it with detailed information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)