[jira] [Resolved] (SLING-5831) Support different thread pools for scheduled tasks

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5831.
-
Resolution: Fixed

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: docs-impacting
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



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

[jira] [Resolved] (SLING-5873) Update commons compiler to 2.3.0

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5873.
-
Resolution: Fixed

Updated in 1753446

> Update commons compiler to 2.3.0
> 
>
> Key: SLING-5873
> URL: https://issues.apache.org/jira/browse/SLING-5873
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> We should update the outdated compiler version from 2.0 to 2.3 as 2.3 is the 
> first version which is able to handle java 8 compilation correctly



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

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5831:


Fine with me!

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: docs-impacting
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



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

[jira] [Created] (SLING-5873) Update commons compiler to 2.3.0

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5873:
---

 Summary: Update commons compiler to 2.3.0
 Key: SLING-5873
 URL: https://issues.apache.org/jira/browse/SLING-5873
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Scripting Sightly Engine 1.0.20


We should update the outdated compiler version from 2.0 to 2.3 as 2.3 is the 
first version which is able to handle java 8 compilation correctly



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

Re: [VOTE] Release Apache Sling Parent POM 27

[Carsten Ziegeler]

+1

 

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

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5831:
-

If removeJob did not throw in previous versions, this was clearly a bug. I know 
that it did so in the early versions and the API clearly states that removeJob 
throws. So I think we're totaly fine and callers of removeJob must except that 
exception.

Can we consider this issue done?

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: docs-impacting
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



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

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5831:


bq. For removeJob(), the API states that a NoSuchElementException is thrown if 
the job can't be found, so I think the behaviour is correct now. To avoid the 
exception, you can replace removeJob() with unschedule() (removeJob is 
deprecated)

Ack. However this is a behaviour change and bit unrelated to current issue. So 
may be addressed in different issue. Problem is this would cause such exception 
when new Scheduler bundle is used in older setup where other bundles are not 
updated

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: docs-impacting
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



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

[VOTE] Release Apache Sling Parent POM 27

[Carsten Ziegeler]

Hi,

We solved 21 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12334592

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

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

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

Re: [DISCUSS] Path filtering support for ResourceChangeListeners

[Carsten Ziegeler]

> what about option 2 + 4 together (but only implementiong 'glob' currently)?
> 
> then it would be:
> - easy to detect if the user wishs to use a pattern instead of a fixed path 
> by looking for a prefix (currently this is done by magically looking for 
> special characters)
> - possible to add regex or other pattern support later without breaking 
> compatibility
> - gives us a quick start with only supporting glob currently
> 
Sounds good to me

Carsten

 

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

[jira] [Comment Edited] (SLING-5742) Do not allow registration of agents/exporters/importers with duplicate names

[Timothee Maret (JIRA)]

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

Timothee Maret edited comment on SLING-5742 at 7/19/16 9:17 PM:


This issue relates to SLING-5872, however its scope could/should cover 
configurations created via OSGI consoles.


was (Author: marett):
This issue relates to SLING-5872, however its scope could/should cover 
configurations created via OSGI configurations.

> Do not allow registration of agents/exporters/importers with duplicate names
> 
>
> Key: SLING-5742
> URL: https://issues.apache.org/jira/browse/SLING-5742
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Marius Petria
>




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

[jira] [Commented] (SLING-5742) Do not allow registration of agents/exporters/importers with duplicate names

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5742:
---

This issue relates to SLING-5872, however its scope could/should cover 
configurations created via OSGI configurations.

> Do not allow registration of agents/exporters/importers with duplicate names
> 
>
> Key: SLING-5742
> URL: https://issues.apache.org/jira/browse/SLING-5742
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Marius Petria
>




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

[jira] [Updated] (SLING-5742) Do not allow registration of agents/exporters/importers with duplicate names

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5742:
--
Assignee: (was: Timothee Maret)

> Do not allow registration of agents/exporters/importers with duplicate names
> 
>
> Key: SLING-5742
> URL: https://issues.apache.org/jira/browse/SLING-5742
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Marius Petria
>




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

[jira] [Created] (SLING-5872) Management of agent configurations must identify configurations by name

[Timothee Maret (JIRA)]

Timothee Maret created SLING-5872:
-

 Summary: Management of agent configurations must identify 
configurations by name 
 Key: SLING-5872
 URL: https://issues.apache.org/jira/browse/SLING-5872
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Affects Versions: Content Distribution Core 0.1.18
Reporter: Timothee Maret
Assignee: Timothee Maret


Currently, the configurations are identified by the tuple {{(name,kind)}}.
As a consequence, it is possible to create two configurations with the same 
name but different kind, using the Sling POST servlet on path

{code}
/libs/sling/distribution/settings/agents/
{code}

This breaks the concept of having a single resource type (and thus a single 
agent) for a given type.

This is somewhat related to SLING-5742, however it does not cover creation of 
agents via the OSGI consoles (only via the Sling POST servlet).





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

Re: [DISCUSS] Path filtering support for ResourceChangeListeners

[Michael Dürig]

On 16.7.16 5:56 , Carsten Ziegeler wrote:

I wouldn't go with more powerful matching as the idea of the RCLs is
that the filter matching is done by the underlying storage provider,
e.g. Oak. This allows to delegate the heavy work to the storage and
reduce the number of events send by the storage to Sling.


And Oak already supports some form of globbing [1].

Michael

[1] 
https://github.com/mduerig/jackrabbit-oak/blob/875d538a4e023fa31aa1c5b90574b6d35bb1569c/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.java#L60-L60

[jira] [Resolved] (SLING-5871) osgi-mock: Update to org.apache.felix.scr 2.0.4

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1753418  


> osgi-mock: Update to org.apache.felix.scr 2.0.4
> ---
>
> Key: SLING-5871
> URL: https://issues.apache.org/jira/browse/SLING-5871
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing OSGi Mock 2.0.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: mocks
> Fix For: Testing OSGi Mock 2.0.6
>
>
> we should update to latest version 2.0.4 because some classes where moved and 
> some improvements on the coercion code.



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

[jira] [Updated] (SLING-5871) osgi-mock: Update to org.apache.felix.scr 2.0.4

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-5871:
--
Affects Version/s: Testing OSGi Mock 2.0.4
Fix Version/s: Testing OSGi Mock 2.0.6

> osgi-mock: Update to org.apache.felix.scr 2.0.4
> ---
>
> Key: SLING-5871
> URL: https://issues.apache.org/jira/browse/SLING-5871
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing OSGi Mock 2.0.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: mocks
> Fix For: Testing OSGi Mock 2.0.6
>
>
> we should update to latest version 2.0.4 because some classes where moved and 
> some improvements on the coercion code.



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

[jira] [Created] (SLING-5871) osgi-mock: Update to org.apache.felix.scr 2.0.4

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-5871:
-

 Summary: osgi-mock: Update to org.apache.felix.scr 2.0.4
 Key: SLING-5871
 URL: https://issues.apache.org/jira/browse/SLING-5871
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor


we should update to latest version 2.0.4 because some classes where moved and 
some improvements on the coercion code.



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

[jira] [Assigned] (SLING-5742) Do not allow registration of agents/exporters/importers with duplicate names

[Timothee Maret (JIRA)]

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

Timothee Maret reassigned SLING-5742:
-

Assignee: Timothee Maret

> Do not allow registration of agents/exporters/importers with duplicate names
> 
>
> Key: SLING-5742
> URL: https://issues.apache.org/jira/browse/SLING-5742
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Marius Petria
>Assignee: Timothee Maret
>




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

RE: [DISCUSS] Path filtering support for ResourceChangeListeners

[Oliver Lietz]

On Tuesday 19 July 2016 17:05:09 Stefan Seifert wrote:
> what about option 2 + 4 together (but only implementiong 'glob' currently)?
> 
> then it would be:
> - easy to detect if the user wishs to use a pattern instead of a fixed path
> by looking for a prefix (currently this is done by magically looking for
> special characters)
 - possible to add regex or other pattern support later
> without breaking compatibility - gives us a quick start with only
> supporting glob currently

+1

O.

> stefan
[...]

RE: [DISCUSS] Path filtering support for ResourceChangeListeners

[Stefan Seifert]

what about option 2 + 4 together (but only implementiong 'glob' currently)?

then it would be:
- easy to detect if the user wishs to use a pattern instead of a fixed path by 
looking for a prefix (currently this is done by magically looking for special 
characters)
- possible to add regex or other pattern support later without breaking 
compatibility
- gives us a quick start with only supporting glob currently

stefan

>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Tuesday, July 19, 2016 6:26 PM
>To: Sling Dev
>Subject: Re: [DISCUSS] Path filtering support for ResourceChangeListeners
>
>Hello again,
>
>I'd like to reach to a conclusion for this feature and we currently have
>the following options:
>
>1. use RegEx for these filters, as proposed by Stefan Seifert - we're
>already using RegEx for Sling Mapping
>2. use a limited glob pattern matching, allowing just '**', '*', as
>proposed by Carsten
>3. use the full glob pattern matching syntax defined at [4]
>4. support both regex and glob, but then force consumers to use the 'glob:'
>/ 'regex:' prefixes for their patterns
>
>I'm still not a big supporter of RegEx usage in this case, due to their
>complexity and potential to match more changes than needed due to simple
>mistakes in the syntax: compare '/apps/**/*.html' with
>'^\/apps\/[a-zA-Z0-9:_\-\.]*\/?[a-zA-Z0-9:_\-]+\.html$'. However if we
>really need to support RegEx I'd prefer option 4, where at least consumers
>can write simpler matching patterns if needed.
>
>Thanks,
>Radu
>
>On Mon, 18 Jul 2016 at 15:37 Radu Cotescu  wrote:
>
>> Hi,
>>
>> I'm also a supporter of the glob pattern matching, since those filters
>are
>> easier to write than RegEx [3] (and not just because we'd have to escape
>> every '/'). We could try to support the full syntax described at [4],
>> though, if we need more flexibility.
>>
>> Regards,
>> Radu
>>
>> [3] - https://xkcd.com/1171/
>> [4] -
>>
>https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#get
>PathMatcher(java.lang.String
>> )
>>
>> On Sat, 16 Jul 2016 at 17:56 Carsten Ziegeler 
>> wrote:
>>
>>> I think we should keep it simple and model it based on existing use
>cases.
>>> So far, the only pattern matching which comes to my mind is matching
>>> based on the extension. Basically everything that is caching something
>>> requires this, like the jsp engine being interested in changes of *.jsp
>>> files etc.
>>> Apart from that listeners are usually interested in changes in a
>>> specific sub tree, but without any additional filtering.
>>>
>>> Therefore I think the **, * matching similar to what we know from Ant or
>>> Maven or other tools should be enough.
>>>
>>> I wouldn't go with more powerful matching as the idea of the RCLs is
>>> that the filter matching is done by the underlying storage provider,
>>> e.g. Oak. This allows to delegate the heavy work to the storage and
>>> reduce the number of events send by the storage to Sling. Of course, if
>>> the storage can't filter itself, the Sling provider implementation can
>>> still do an additional filtering, but that might be rather expensive.
>>>
>>> Regards
>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>>>
>>>

New module Sling Testing PaxExam

[Oliver Lietz]

hi all,

I've added a new module org.apache.sling.testing.paxexam in trunk/testing 
recently. It provides Sling's Launchpad Karaf Features as Options for Pax 
Exam (without Karaf) to setup a Sling instance with less boilerplate code:

* allows to run ITs in the same module (with the build artifact under test)
* allows using different versions in build and tests
* allows overriding of versions
 
Setting up a Sling Launchpad with some additional "Features":

protected static Option launchpad(final String workingDirectory) {
final int httpPort = findFreePort();
final String slingHome = String.format("%s/sling", workingDirectory);
final String repositoryHome = String.format("%s/repository", slingHome);
final String localIndexDir = String.format("%s/index", repositoryHome);
return composite(
slingJcrOak(),
slingLaunchpadOak(),
slingExtensionI18n(),
slingExtensionModels(),
slingScriptingJsp(),
newConfiguration("org.apache.felix.http")
.put("org.osgi.service.http.port", httpPort)
.asOption(),

newConfiguration("org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService")
.put("repository.home", repositoryHome)
.put("name", "Default NodeStore")
.asOption(),

newConfiguration("org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService")
.put("localIndexDir", localIndexDir)
.asOption(),
mavenBundle().groupId("org.apache.jackrabbit").artifactId("oak-
segment").version(SlingOptions.versionResolver)
);
}

For a complete example see tests in Scripting Thymeleaf. I will cut a first 
release when Sling Oak Server 1.1 is available. Any feedback is welcome.

Regards,
O.

Re: [DISCUSS] Path filtering support for ResourceChangeListeners

[Radu Cotescu]

Hello again,

I'd like to reach to a conclusion for this feature and we currently have
the following options:

1. use RegEx for these filters, as proposed by Stefan Seifert - we're
already using RegEx for Sling Mapping
2. use a limited glob pattern matching, allowing just '**', '*', as
proposed by Carsten
3. use the full glob pattern matching syntax defined at [4]
4. support both regex and glob, but then force consumers to use the 'glob:'
/ 'regex:' prefixes for their patterns

I'm still not a big supporter of RegEx usage in this case, due to their
complexity and potential to match more changes than needed due to simple
mistakes in the syntax: compare '/apps/**/*.html' with
'^\/apps\/[a-zA-Z0-9:_\-\.]*\/?[a-zA-Z0-9:_\-]+\.html$'. However if we
really need to support RegEx I'd prefer option 4, where at least consumers
can write simpler matching patterns if needed.

Thanks,
Radu

On Mon, 18 Jul 2016 at 15:37 Radu Cotescu  wrote:

> Hi,
>
> I'm also a supporter of the glob pattern matching, since those filters are
> easier to write than RegEx [3] (and not just because we'd have to escape
> every '/'). We could try to support the full syntax described at [4],
> though, if we need more flexibility.
>
> Regards,
> Radu
>
> [3] - https://xkcd.com/1171/
> [4] -
> https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher(java.lang.String
> )
>
> On Sat, 16 Jul 2016 at 17:56 Carsten Ziegeler 
> wrote:
>
>> I think we should keep it simple and model it based on existing use cases.
>> So far, the only pattern matching which comes to my mind is matching
>> based on the extension. Basically everything that is caching something
>> requires this, like the jsp engine being interested in changes of *.jsp
>> files etc.
>> Apart from that listeners are usually interested in changes in a
>> specific sub tree, but without any additional filtering.
>>
>> Therefore I think the **, * matching similar to what we know from Ant or
>> Maven or other tools should be enough.
>>
>> I wouldn't go with more powerful matching as the idea of the RCLs is
>> that the filter matching is done by the underlying storage provider,
>> e.g. Oak. This allows to delegate the heavy work to the storage and
>> reduce the number of events send by the storage to Sling. Of course, if
>> the storage can't filter itself, the Sling provider implementation can
>> still do an additional filtering, but that might be rather expensive.
>>
>> Regards
>> Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
>>

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

see SLING-5792 for pull request

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



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

[jira] [Commented] (SLING-5795) Allow for adding/removing individual AuthenticationRequirementHolder entries

[angela (JIRA)]

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

angela commented on SLING-5795:
---

see SLING-5792 for pull request

> Allow for adding/removing individual AuthenticationRequirementHolder entries
> 
>
> Key: SLING-5795
> URL: https://issues.apache.org/jira/browse/SLING-5795
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> Today the {{SlingAuthenticator}} comes with a 
> {{SlingAuthenticatorServiceListener}}, that listens for all services that are 
> registered with an {{AuthConstants.AUTH_REQUIREMENTS}} property. This allows 
> for arbitrary services to extend the list of authentication requirements 
> originally intended to be configured with the {{SlingAuthenticatior}}.
> The implementation consequently requires those services to provide their full 
> list of auth-requirements: this not only forces the services to recompute 
> that information but also forces the {{SlingAuthenticatorServiceListener}} to 
> process the whole information upon every single change (see 
> {{SlingAuthenticatorServiceListener.addService}} and 
> {{SlingAuthenticatorServiceListener.removeService}}, which also includes an 
> update of the {{PathBasedHolderCache}}.
> At a Adobe we make use of this ability in a service that may contain several 
> thousand requirement entries which in addition are prone to frequent changes, 
> which IMO is not super-optimal with the implementation at hand.
> This assessment is not yet backed with decent performance testing, but based 
> on what I found while trying to rewrite that particular service to address 
> known issues.
> To summarize: What I have been looking for was the ability to inform the 
> listener about a single entry that would need to be added or removed from the 
> list of auth-requirements collected (and registered) by my service, without 
> having to compute (or cache) the complete list and without having all items 
> associated with my service being processed over and over again.
> Maybe envisioning SLING-5792 would offer the opportunity to also reconsider 
> this wish.



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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5870:
-

A release of Oak Server is overdue but I would like to wait now for parent 27 
and do some further cleanup. The one in {{trunk}} _should_ become 1.1.0 with 
Oak 1.5 and the one in {{branches/oak-server-1.0}} _could_ become 1.0.2 with 
Oak 1.4.

> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5870:


Is that {{org.apache.sling/org.apache.sling.jcr.oak.server/1.0.1-SNAPSHOT}}  ?

We need to release that soon, I have the same issue in the repoinit/it module.

> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

[jira] [Commented] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5253:
-

Pushed a potential fix in [r1752382|https://svn.apache.org/r1753389] that 
relies on [r1752382|https://svn.apache.org/r1752382].

> Remove getAdministrativeResourceResolver() from the Sightly engine
> --
>
> Key: SLING-5253
> URL: https://issues.apache.org/jira/browse/SLING-5253
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.20
>
>
> 3 occurrences in 
> {{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.



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

[jira] [Commented] (SLING-5863) Make the sightly-maven-plugin m2e compatible

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5863:


Applied in https://svn.apache.org/r1753398

> Make the sightly-maven-plugin m2e compatible
> 
>
> Key: SLING-5863
> URL: https://issues.apache.org/jira/browse/SLING-5863
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sightly Maven Plugin 1.0.0
>
> Attachments: 
> 0001-SLING-5863-Make-the-sightly-maven-plugin-m2e-compati.patch
>
>
> Maven plug-ins can easily be made compatible with m2e for transparent 
> integration with Eclipse.
> We should add this to the sightly-maven-plugin and make the compilation 
> results available in Eclipse.



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

[jira] [Commented] (SLING-5863) Make the sightly-maven-plugin m2e compatible

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5863:


IIUC the pom errors are reported whenever a mojo fails. What I can do is try 
and detect when the plugin is running in Eclipse and don't fail the mojo 
execution.

> Make the sightly-maven-plugin m2e compatible
> 
>
> Key: SLING-5863
> URL: https://issues.apache.org/jira/browse/SLING-5863
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sightly Maven Plugin 1.0.0
>
> Attachments: 
> 0001-SLING-5863-Make-the-sightly-maven-plugin-m2e-compati.patch
>
>
> Maven plug-ins can easily be made compatible with m2e for transparent 
> integration with Eclipse.
> We should add this to the sightly-maven-plugin and make the compilation 
> results available in Eclipse.



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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5870:


I've taken a look at both approaches, and I'm still trying to find the right 
incantation to make Pax-Exam happy. I think I've found one, but that 
unfortunately uses SNAPSHOT versions, so still needs a bit more digging.

> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

[jira] [Resolved] (SLING-3471) Add Sling Replication IT for commands

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-3471.

Resolution: Fixed

> Add Sling Replication IT for commands
> -
>
> Key: SLING-3471
> URL: https://issues.apache.org/jira/browse/SLING-3471
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> Replication commands (ADD, DELETE, POLL) need to be properly checked with 
> integration tests, at least to check the expected default behavior (HTTP 
> status, etc.)



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

[jira] [Resolved] (SLING-3470) Add Sling Replication ITs for all the exposed resources

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-3470.

Resolution: Fixed

> Add Sling Replication ITs for all the exposed resources
> ---
>
> Key: SLING-3470
> URL: https://issues.apache.org/jira/browse/SLING-3470
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>
> Provide integration tests for all the resources exposed by Sling Replication 
> to check which ones are exposed given a certain runMode and possibly how to 
> restrict access to them.



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

[jira] [Commented] (SLING-5863) Make the sightly-maven-plugin m2e compatible

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-5863:
-

I've played with the plugin and really like the way it works in Eclipse. 

There are some cases though when the Sightly Compiler cannot yet report the 
line in the script where a certain class of errors happened (e.g. the usage of 
a non-existing block element - {{data-sly-whatever}}. In this case it seems 
that line of the reported error refers to the execution tag from the plugin's 
configuration in the pom. Could we improve this somehow such that we don't 
report a POM error?


> Make the sightly-maven-plugin m2e compatible
> 
>
> Key: SLING-5863
> URL: https://issues.apache.org/jira/browse/SLING-5863
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sightly Maven Plugin 1.0.0
>
> Attachments: 
> 0001-SLING-5863-Make-the-sightly-maven-plugin-m2e-compati.patch
>
>
> Maven plug-ins can easily be made compatible with m2e for transparent 
> integration with Eclipse.
> We should add this to the sightly-maven-plugin and make the compilation 
> results available in Eclipse.



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

Re: [sightly] Updating the commons compiler dependency?

[Carsten Ziegeler]

> If all the Sightly tests pass I have no problem with this change.
>

The unit tests pass and the integration tests are run with launchpad 9
which anyway contains the latest compiler.

Carsten

> Thanks,
> Radu
> 
> On Tue, 19 Jul 2016 at 15:42 Bertrand Delacretaz 
> wrote:
> 
>> On Tue, Jul 19, 2016 at 3:30 PM, Carsten Ziegeler 
>> wrote:
>>> ...updating the dependency of
>>> commons.compiler from 2.0.0 to 2.3.0 solves the problem...
>>
>> I think the Sightly test suite is pretty solid, so if the tests pass
>> after that update I'm +1 on it.
>>
>> -Bertrand
>>
> 


 

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

Re: [sightly] Updating the commons compiler dependency?

[Radu Cotescu]

If all the Sightly tests pass I have no problem with this change.

Thanks,
Radu

On Tue, 19 Jul 2016 at 15:42 Bertrand Delacretaz 
wrote:

> On Tue, Jul 19, 2016 at 3:30 PM, Carsten Ziegeler 
> wrote:
> > ...updating the dependency of
> > commons.compiler from 2.0.0 to 2.3.0 solves the problem...
>
> I think the Sightly test suite is pretty solid, so if the tests pass
> after that update I'm +1 on it.
>
> -Bertrand
>

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-5866:
--

The most important uses IIRC for a HEAD request is getting at the Content-Type 
and Content-Length properties. As long as we can ensure these are still set, it 
seems a good idea to do that, indeed.

For implementation: Maybe you can find a solution to share the response header 
setting between doGet and doHead (IOW only the actual transmission of the 
content is special to doGet).

Thanks [~anagarwa]

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5870:


FWIW, {{bundles/jcr/it-jackrabbit-oak}} is another example which runs test with 
Pax Exam using both Jackrabbit and Oak.

> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

Re: [sightly] Updating the commons compiler dependency?

[Bertrand Delacretaz]

On Tue, Jul 19, 2016 at 3:30 PM, Carsten Ziegeler  wrote:
> ...updating the dependency of
> commons.compiler from 2.0.0 to 2.3.0 solves the problem...

I think the Sightly test suite is pretty solid, so if the tests pass
after that update I'm +1 on it.

-Bertrand

[jira] [Commented] (SLING-920) Sling Jenkins setup

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-920:
---

Applied same change to sling-tooling-trunk-1.7

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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

Re: [sightly] Updating the commons compiler dependency?

[Carsten Ziegeler]

Forgot to mention that another good reason to update the dependency is
to use a compiler which is able to handle java 8 compilation correctly.

Carsten

> Hi,
> 
> currently Sightly core depends on commons.compiler 2.0.0, however this
> has some strange dependencies to Eclipse projects and I can't get past
> these. In particular it seems these dependencies can't be downloaded:
> 
> org.eclipse:osgi:jar:3.4.3.R34x_v20081215-1030
> org.eclipse.core:resources:jar:3.3.1
> org.eclipse.core:resources:jar:3.4.0
> org.eclipse.core:commands:jar:3.3.0
> 
> No idea what is happening there. However, updating the dependency of
> commons.compiler from 2.0.0 to 2.3.0 solves the problem.
> As that version is out for a long time, what about - in this case -
> simply updating the dependency and making the build pass?
> 
> Carsten
> 


 

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

[sightly] Updating the commons compiler dependency?

[Carsten Ziegeler]

Hi,

currently Sightly core depends on commons.compiler 2.0.0, however this
has some strange dependencies to Eclipse projects and I can't get past
these. In particular it seems these dependencies can't be downloaded:

org.eclipse:osgi:jar:3.4.3.R34x_v20081215-1030
org.eclipse.core:resources:jar:3.3.1
org.eclipse.core:resources:jar:3.4.0
org.eclipse.core:commands:jar:3.3.0

No idea what is happening there. However, updating the dependency of
commons.compiler from 2.0.0 to 2.3.0 solves the problem.
As that version is out for a long time, what about - in this case -
simply updating the dependency and making the build pass?

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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5870:
-

Scripting Thymeleaf runs tests on Oak: 
https://github.com/apache/sling/blob/trunk/contrib/scripting/org.apache.sling.scripting.thymeleaf/src/test/java/org/apache/sling/scripting/thymeleaf/it/tests/ThymeleafTestSupport.java


> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

[jira] [Commented] (SLING-5870) Switch event ITs to use Oak

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5870:
-

+1 to move to Oak - I tried it some time ago but failed as I couldn't get Oak 
running within PAX

> Switch event ITs to use Oak
> ---
>
> Key: SLING-5870
> URL: https://issues.apache.org/jira/browse/SLING-5870
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Event 4.1.0
>
>
> The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
> inconsistencies in the repository, e.g.
> {code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
> Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
> processOsgiEventQueue: Unexpected problem processing event 
> {path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
>  resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
> resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
> org.apache.sling.api.SlingException: Problem retrieving node based resource 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
>   at 
> org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
>   at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
>   at java.lang.Thread.run(Thread.java:744)
> Caused by: javax.jcr.PathNotFoundException: 
> /var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
>   at 
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
>   at 
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
>   at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
>   at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
>   ... 11 common frames omitted{code}
> Moving to Oak might help with these issues, and it's anyway a good idea since 
> the default Launchpad only includes Sling ATM.



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

[jira] [Commented] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5867:


bq... in case of a non-returning response ... the health check will just 
timeout but never actually really fail (even after a very long time).

bq. This should not be true: 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L432
 should make it fail eventually after 5 minutes (configurable via 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L88)

Actually the underlying thread is never killed deliberately, please also 
compare with 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L422,
 therefore the HC times out but the underlying thread is still running 
indefinitely.

> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



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

[jira] [Created] (SLING-5870) Switch event ITs to use Oak

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-5870:
--

 Summary: Switch event ITs to use Oak
 Key: SLING-5870
 URL: https://issues.apache.org/jira/browse/SLING-5870
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Event 4.1.0


The Event ITs sometimes fail on Jenkins, and the errors seem to indicate 
inconsistencies in the repository, e.g.

{code}19.07.2016 09:57:31.489 *WARN* [Apache Sling JCR Resource Event Queue 
Processor] org.apache.sling.jcr.resource.internal.JcrResourceListener 
processOsgiEventQueue: Unexpected problem processing event 
{path=/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931,
 resourceChangedAttributes=[Ljava.lang.String;@51e6a8e1, 
resourceAddedAttributes=[Ljava.lang.String;@1447afb0, userid=admin}
org.apache.sling.api.SlingException: Problem retrieving node based resource 
/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:156)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:143)
at 
org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:113)
at 
org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:401)
at 
org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:356)
at 
org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:138)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getAbsoluteResourceInternal(ResourceResolverImpl.java:988)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:635)
at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:590)
at 
org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:340)
at 
org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run(JcrResourceListener.java:107)
at java.lang.Thread.run(Thread.java:744)
Caused by: javax.jcr.PathNotFoundException: 
/var/eventing/jobs/assigned/f96f5677-4d3b-454d-9dc1-c2ee9270b35c/sling.chaos.round.4/2016/7/19/9/53/f96f5677-4d3b-454d-9dc1-c2ee9270b35c_2931
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:552)
at 
org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:97)
at 
org.apache.jackrabbit.core.session.SessionItemOperation$4.perform(SessionItemOperation.java:93)
at 
org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:786)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:211)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:154)
... 11 common frames omitted{code}

Moving to Oak might help with these issues, and it's anyway a good idea since 
the default Launchpad only includes Sling ATM.



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

[jira] [Comment Edited] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-5867 at 7/19/16 12:25 PM:
--

bq. This should not be true: 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L432
 should make it fail eventually after 5 minutes (configurable via 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L88)

Actually the underlying thread is never killed deliberately, please also 
compare with 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L422,
 therefore the HC times out but the underlying thread is still running 
indefinitely.


was (Author: kwin):
bq... in case of a non-returning response ... the health check will just 
timeout but never actually really fail (even after a very long time).

bq. This should not be true: 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L432
 should make it fail eventually after 5 minutes (configurable via 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L88)

Actually the underlying thread is never killed deliberately, please also 
compare with 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L422,
 therefore the HC times out but the underlying thread is still running 
indefinitely.

> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



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

[jira] [Commented] (SLING-5863) Make the sightly-maven-plugin m2e compatible

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5863:


Ugh, I accidentally pushed my changes ( https://svn.apache.org/r1753372 ). Feel 
free to revert/change if something isn't right ( or resolve if things look ok ).

> Make the sightly-maven-plugin m2e compatible
> 
>
> Key: SLING-5863
> URL: https://issues.apache.org/jira/browse/SLING-5863
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sightly Maven Plugin 1.0.0
>
> Attachments: 
> 0001-SLING-5863-Make-the-sightly-maven-plugin-m2e-compati.patch
>
>
> Maven plug-ins can easily be made compatible with m2e for transparent 
> integration with Eclipse.
> We should add this to the sightly-maven-plugin and make the compilation 
> results available in Eclipse.



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

[jira] [Comment Edited] (SLING-5803) FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-5803 at 7/19/16 12:14 PM:
--

I've excluded FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists 
as it consistently fails on Jenkins - https://svn.apache.org/r1753373


was (Author: rombert):
I've {{@Ignore}}d 
FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists as it 
consistently fails on Jenkins - https://svn.apache.org/r1753373

> FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins
> --
>
> Key: SLING-5803
> URL: https://issues.apache.org/jira/browse/SLING-5803
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Andrei Dulvac
>Priority: Minor
>  Labels: sling-IT
>
> These tests are consistently failing on Jenkins as in [1] for example:
> * FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists
> * FilterRuleExcludeCategoryTest.testExcludedCategoryExists
> both with "java.lang.AssertionError: Test should be Ignored"
> Andrei, as you wrote those tests, could you have a look?
> [1] https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/4145/



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

[jira] [Commented] (SLING-5803) FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-5803:


I've {{@Ignore}}d 
FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists as it 
consistently fails on Jenkins - https://svn.apache.org/r1753373

> FilterRuleExcludeCategoryIgnoreIfTest fails on Jenkins
> --
>
> Key: SLING-5803
> URL: https://issues.apache.org/jira/browse/SLING-5803
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Andrei Dulvac
>Priority: Minor
>  Labels: sling-IT
>
> These tests are consistently failing on Jenkins as in [1] for example:
> * FilterRuleExcludeCategoryIgnoreIfTest.testExcludedCategoryExists
> * FilterRuleExcludeCategoryTest.testExcludedCategoryExists
> both with "java.lang.AssertionError: Test should be Ignored"
> Andrei, as you wrote those tests, could you have a look?
> [1] https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/4145/



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

[jira] [Commented] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5867:
--

bq. ... in case of a non-returning response ... the health check will just 
timeout but never actually really fail (even after a very long time).

This should not be true: 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L432
 should make it fail eventually after 5 minutes (configurable via 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L88)

bq. ... create a dedicated timeout handling within the 
SlingRequestStatusHealthCheck (separate from the timeout in 
HealthCheckExecutorImpl) because for each individual request health check 
configuration you might want to set different timeouts.

I think the maximum time you can wait for a response depends a lot more on from 
where you are calling (e.g. load balancer or human for a dashboard) than to a 
fixed set of tags or a particular check (hence configuring this per check or 
tag does not make much sense IMHO). So at the moment, timeout handling is done 
by using
* a global default
* a per call setting when using the HC Executor (e.g. the request param 
"timeout" of the HC servlet that set the HC executor option at 
https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/api/execution/HealthCheckExecutionOptions.java#L26)



> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



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

[jira] [Updated] (SLING-5869) htl doesn't escape '%' character in uri context

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier updated SLING-5869:
---
Description: 
% char in an href will not be escaped by sightly. This will cause an issue in 
case a space is immediately after it, e.g.
"?message=5% fat only" will be escaped like "5%%20fat%20only", and %%20 will 
crash some servers' request processing, at least it crashes sling's with 
something like:
{noformat}
org.apache.sling.engine.impl.parameters.ParameterSupport 
getRequestParameterMapInternal: Error parsing request
java.lang.IllegalArgumentException: Bad escape sequence: %=l
at org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
at org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
{noformat}


  was:
% char in an href will not be escaped by sightly. This will cause an issue in 
case a space is immediately after it, e.g.
"5% fat only" will be escaped like "5%%20fat%20only", and %%20 will crash some 
servers' request processing, at least it crashes sling's with something like:
{noformat}
org.apache.sling.engine.impl.parameters.ParameterSupport 
getRequestParameterMapInternal: Error parsing request
java.lang.IllegalArgumentException: Bad escape sequence: %=l
at org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
at org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
{noformat}



> htl doesn't escape '%' character in uri context
> ---
>
> Key: SLING-5869
> URL: https://issues.apache.org/jira/browse/SLING-5869
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Nicolas Peltier
>
> % char in an href will not be escaped by sightly. This will cause an issue in 
> case a space is immediately after it, e.g.
> "?message=5% fat only" will be escaped like "5%%20fat%20only", and %%20 will 
> crash some servers' request processing, at least it crashes sling's with 
> something like:
> {noformat}
> org.apache.sling.engine.impl.parameters.ParameterSupport 
> getRequestParameterMapInternal: Error parsing request
> java.lang.IllegalArgumentException: Bad escape sequence: %=l
> at 
> org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
> at 
> org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
> at 
> org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
> {noformat}



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

[jira] [Created] (SLING-5869) htl doesn't escape '%' character in uri context

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-5869:
--

 Summary: htl doesn't escape '%' character in uri context
 Key: SLING-5869
 URL: https://issues.apache.org/jira/browse/SLING-5869
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Nicolas Peltier


% char in an href will not be escaped by sightly. This will cause an issue in 
case a space is immediately after it, e.g.
"5% fat only" will be escaped like "5%%20fat%20only", and %%20 will crash some 
servers' request processing, at least it crashes sling's with something like:
{noformat}
org.apache.sling.engine.impl.parameters.ParameterSupport 
getRequestParameterMapInternal: Error parsing request
java.lang.IllegalArgumentException: Bad escape sequence: %=l
at org.apache.sling.engine.impl.parameters.Util.parseNVPairString(Util.java:330)
at org.apache.sling.engine.impl.parameters.Util.parseQueryString(Util.java:215)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:247)
at 
org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:
{noformat}




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

[jira] [Assigned] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-5867:
--

Assignee: Konrad Windszus

> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



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

[jira] [Updated] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5867:
---
Description: 
Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
synchronously calls {{SlingRequestProcessor.processResponse}}.
That means in case of a non-returning response (e.g. caused by a deadlock like 
SLING-5847) the health check will just timeout but never actually really fail 
(even after a very long time).

In this case it is good to create a dedicated timeout handling within the 
{{SlingRequestStatusHealthCheck}} (separate from the timeout in 
{{HealthCheckExecutorImpl}}) because for each individual request health check 
configuration you might want to set different timeouts.


  was:
Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
synchronously calls {{SlingRequestProcessor.processResponse}}.
That means in case of a non-returning response (e.g. caused by a deadlock like 
SLING-5847) the health check will just timeout but never actually really fail 
(even after a very long time).

In this case it is good to create a dedicated timeout handling within the 
{{SlingRequestStatusHealthCheck}} (separate from the timeout in 
{{HealthCheckExecutorImpl}}) because for each individual request configuration 
you might want to set different timeouts.



> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request health check 
> configuration you might want to set different timeouts.



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

[jira] [Commented] (SLING-5792) API to manage Authentication Requirement

[ASF GitHub Bot (JIRA)]

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

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

GitHub user anchela opened a pull request:

https://github.com/apache/sling/pull/153

SLING-5792, SLING-5868, SLING-5795

## SLING-5792: API to manage Authentication Requirement

### Changes
- new interface 'AuthenticationRequirement'
- implemented by SlingAuthenticator
- additionally: annotations with helper classes in the impl package to 
improve readability

### Notes
with the implementation in SlingAuthenticator the values in the 'props' map 
change from array of AuthenticationRequirementHolder to a Set, which IMO 
corresponds better to the PathBasedHolderCache, which at some point has changed 
from ArrayList to SortedSet... but that for sure requires a careful review 
(also from a performance PoV)

### TODO
- the original code synchronized on 'props' before updating the 
PathBasedHolderCache, which itself was synchronized. That looks troublesome to 
me and with the patch this is separated.
- I would like to write some benchmarks to be able to compare performance 
of AuthenticationRequirement vs. the ServiceListener approach as well as the 
effect of moving from array to Set in the props-map. But: I couldn't find the 
right way of doing this in Apache Sling (see also SLING-5791 for a specific 
issue).

## SLING-5795 and SLING-5868

### Changes
- new module 'org.apache.sling.auth.requirement' in the contrib/auth space
- new public API 'LoginPathProvider'
- implementation based on Jackrabbit Oak that allows to mark subtrees with 
the set of configured supported paths to require authentication including an 
optional login path.

### TODO
- currently snapshot dependency to 'org.apache.sling.auth.core' due to 
usage of 'AuthenticationRequirement'
- repo-init that defines the service-user required for the default 
implementation
- Oak index definition that prevents traversal for initial query 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anchela/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/153.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #153


commit b11eaaa043a406ccac16a07edec0c7815d1cba5a
Author: angela 
Date:   2016-07-19T08:23:44Z

SLING-5792 : API to manage Authentication Requirement

commit 28c147c387b997e3d2106e1ad82d2b35e50388a3
Author: angela 
Date:   2016-07-19T09:14:24Z

SLING-5868 : API to define and retrieve login path with along with 
authentication requirements
SLING-5795: Allow for adding/removing individual 
AuthenticationRequirementHolder entries




> API to manage Authentication Requirement
> 
>
> Key: SLING-5792
> URL: https://issues.apache.org/jira/browse/SLING-5792
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> Apart from the constant {{AuthConstants.AUTH_REQUIREMENTS}} there is no 
> public API available that allowed applications to change the list of 
> authentication requirement entries.
> Instead, applications need to know and rely on implementation details, which 
> not only includes registering services with the  
> {{AuthConstants.AUTH_REQUIREMENTS}} property included but also know about the 
> required format of the property, which from my point of view should be and 
> remain an implementation detail of 
> {{org.apache.sling.auth.core.impl.SlingAuthenticator}}, which IMO should not 
> be considered public API.
> To me it would feel more natural if there existed a 
> {{AuthenticationRequirement}} interface defining methods to 
> extend/update/clear the auth-requirements bound to a particular service 
> reference and having {{org.apache.sling.auth.core.impl.SlingAuthenticator}} 
> implementing that interface.
> Doing so, might also be beneficial from a performance/scalability POV but I 
> would like to cover that in a separate sub-task.
> Proposal for this sub-tasks will follow as I am moving forward.



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

[GitHub] sling pull request #153: SLING-5792, SLING-5868, SLING-5795

[anchela]

GitHub user anchela opened a pull request:

https://github.com/apache/sling/pull/153

SLING-5792, SLING-5868, SLING-5795

## SLING-5792: API to manage Authentication Requirement

### Changes
- new interface 'AuthenticationRequirement'
- implemented by SlingAuthenticator
- additionally: annotations with helper classes in the impl package to 
improve readability

### Notes
with the implementation in SlingAuthenticator the values in the 'props' map 
change from array of AuthenticationRequirementHolder to a Set, which IMO 
corresponds better to the PathBasedHolderCache, which at some point has changed 
from ArrayList to SortedSet... but that for sure requires a careful review 
(also from a performance PoV)

### TODO
- the original code synchronized on 'props' before updating the 
PathBasedHolderCache, which itself was synchronized. That looks troublesome to 
me and with the patch this is separated.
- I would like to write some benchmarks to be able to compare performance 
of AuthenticationRequirement vs. the ServiceListener approach as well as the 
effect of moving from array to Set in the props-map. But: I couldn't find the 
right way of doing this in Apache Sling (see also SLING-5791 for a specific 
issue).

## SLING-5795 and SLING-5868

### Changes
- new module 'org.apache.sling.auth.requirement' in the contrib/auth space
- new public API 'LoginPathProvider'
- implementation based on Jackrabbit Oak that allows to mark subtrees with 
the set of configured supported paths to require authentication including an 
optional login path.

### TODO
- currently snapshot dependency to 'org.apache.sling.auth.core' due to 
usage of 'AuthenticationRequirement'
- repo-init that defines the service-user required for the default 
implementation
- Oak index definition that prevents traversal for initial query 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anchela/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/153.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #153


commit b11eaaa043a406ccac16a07edec0c7815d1cba5a
Author: angela 
Date:   2016-07-19T08:23:44Z

SLING-5792 : API to manage Authentication Requirement

commit 28c147c387b997e3d2106e1ad82d2b35e50388a3
Author: angela 
Date:   2016-07-19T09:14:24Z

SLING-5868 : API to define and retrieve login path with along with 
authentication requirements
SLING-5795: Allow for adding/removing individual 
AuthenticationRequirementHolder entries




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

angela created SLING-5868:
-

 Summary: API to define and retrieve login path with along with 
authentication requirements
 Key: SLING-5868
 URL: https://issues.apache.org/jira/browse/SLING-5868
 Project: Sling
  Issue Type: Sub-task
  Components: Authentication
Reporter: angela


When defining parts of the hierarchy that require authentication it would be 
handy to also be able to defined an optional, individual login path for that 
particular subtree.

This functionality could additionally come with an API that would allow to 
identify the login path that corresponds to a given sling request.



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

Re: [VOTE] Release Apache Sling HApi - Sling Hypermedia API client-side tools version 1.0.0

[Andrei Dulvac]

Hi Oliver,

OK, it makes sense. So I'll drop the release and make it into an OSGi
bundle.

- Andrei

On Sun, Jul 17, 2016 at 9:04 PM Oliver Lietz  wrote:

> On Friday 15 July 2016 17:36:31 Andrei Dulvac wrote:
> > Hi Oliver,
>
> Hi Andrei,
>
> > Because it's a client-side tool, meant to be used outside the Sling
> > instance, like it HTTP tests. I guess it could become a bundle, but I
> don't
> > really see the point right now.
>
> making it a bundle later becomes difficult when you want to stick to OSGi
> conventions, namely packages impl and internal being private (not
> exported).
> MicrodataHtmlClient extends AbstractHtmlClientImpl – a class which is meant
> for extensions but lives in a "private" package.
>
> Personally I do prefer in-container test even when doing HTTP calls,
> because
> they can depend on services being available and then do their work instead
> of
> doing awkward HTTP calls from outside to find out about "readiness", see
> e.g.
> tests for Scripting Thymeleaf (where btw I would like to play with HApi
> also).
>
> IMHO releasing HApi Client not as OSGi bundle is an unnecessary limitation.
>
> Regards,
> O.
>
> > -Andrei
> >
> > On Fri, Jul 15, 2016 at 18:54 Oliver Lietz 
> wrote:
> > > On Wednesday 13 July 2016 15:59:35 Andrei Dulvac wrote:
> > > > Hi,
> > >
> > > Hi Andrei,
> > >
> > > > We solved 2 issues in this release:
> > > > *https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
> > > >  >*
> > > > 
> > > > Staging repository:
> > > >
> https://repository.apache.org/content/repositories/orgapachesling-1479/
> > >
> > > most of our releases are bundles. Is there a reason why this release is
> > > built
> > > without OSGi metadata?
> > >
> > > Regards,
> > > O.
>
>

[jira] [Updated] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5867:
---
Description: 
Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
synchronously calls {{SlingRequestProcessor.processResponse}}.
That means in case of a non-returning response (e.g. caused by a deadlock like 
SLING-5847) the health check will just timeout but never actually really fail 
(even after a very long time).

In this case it is good to create a dedicated timeout handling within the 
{{SlingRequestStatusHealthCheck}} (separate from the timeout in 
{{HealthCheckExecutorImpl}}) because for each individual request configuration 
you might want to set different timeouts.


  was:
Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
synchronously calls {{SlingRequestProcessor.processResponse}}.
That means in case of a non-returning response (e.g. caused by a deadlock like 
SLING-5847) the health check will just timeout but never actually really fail 
(even after a very long time).

In this case it is good to create a dedicated timeout handling (separate from 
the timeout in {{HealthCheckExecutorImpl}}) because for each individual request 
configuration you might want to set different timeouts.



> SlingRequestStatusHealthCheck should add timeout support
> 
>
> Key: SLING-5867
> URL: https://issues.apache.org/jira/browse/SLING-5867
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.4
>Reporter: Konrad Windszus
>
> Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
> synchronously calls {{SlingRequestProcessor.processResponse}}.
> That means in case of a non-returning response (e.g. caused by a deadlock 
> like SLING-5847) the health check will just timeout but never actually really 
> fail (even after a very long time).
> In this case it is good to create a dedicated timeout handling within the 
> {{SlingRequestStatusHealthCheck}} (separate from the timeout in 
> {{HealthCheckExecutorImpl}}) because for each individual request 
> configuration you might want to set different timeouts.



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

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5866:
-

[~anagarwa] I think we can implement the HEAD logic in the GET Servlet. Right 
now the doHead method calls doGet, so we need to implement doHead in the GET 
servlet. I assume that doHead will do most of doGet except for getting the 
input stream and maybe setting additional headers

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Ankit Agarwal (JIRA)]

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

Ankit Agarwal commented on SLING-5866:
--

[~cziegeler] in case on HEAD request, instead of sending it to GET Servlet is 
there any harm if we just set headers in response based on resource and return 
the response ?

thanks,

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Resolved] (SLING-5849) Inconsistent event handling between local package importer and its factory

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-5849.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

applied Timothee's patch in r1753341

> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



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

[GitHub] sling pull request #152: SLING-5849 - Inconsistent event handling between lo...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/sling/pull/152


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-5849) Inconsistent event handling between local package importer and its factory

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/sling/pull/152


> Inconsistent event handling between local package importer and its factory
> --
>
> Key: SLING-5849
> URL: https://issues.apache.org/jira/browse/SLING-5849
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution, Extensions
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5849.diff
>
>
> {{LocalDistributionPackageImporterFactory}} factory sends events [0] which 
> are not sent by the {{LocalDistributionPackageImporter}}. As the two classes 
> are used (depending on the configuration) this creates an inconsistent 
> handling of events.
> [0] 
> https://github.com/apache/sling/blob/006f9d1601c7b3dec1cd3ab303bc34e26a4870a3/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/packaging/impl/importer/LocalDistributionPackageImporterFactory.java#L94



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

[jira] [Created] (SLING-5867) SlingRequestStatusHealthCheck should add timeout support

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5867:
--

 Summary: SlingRequestStatusHealthCheck should add timeout support
 Key: SLING-5867
 URL: https://issues.apache.org/jira/browse/SLING-5867
 Project: Sling
  Issue Type: Bug
  Components: Health Check
Affects Versions: Health Check Support 1.0.4
Reporter: Konrad Windszus


Currently {{o.a.s.hc.support.impl.SlingRequestStatusHealthCheck}} just 
synchronously calls {{SlingRequestProcessor.processResponse}}.
That means in case of a non-returning response (e.g. caused by a deadlock like 
SLING-5847) the health check will just timeout but never actually really fail 
(even after a very long time).

In this case it is good to create a dedicated timeout handling (separate from 
the timeout in {{HealthCheckExecutorImpl}}) because for each individual request 
configuration you might want to set different timeouts.




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

[jira] [Commented] (SLING-5831) Support different thread pools for scheduled tasks

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5831:
-

Thanks for reporting [~chetanm]
I've added a null check in activate().
For removeJob(), the API states that a NoSuchElementException is thrown if the 
job can't be found, so I think the behaviour is correct now. To avoid the 
exception, you can replace removeJob() with unschedule() (removeJob is 
deprecated)

> Support different thread pools for scheduled tasks
> --
>
> Key: SLING-5831
> URL: https://issues.apache.org/jira/browse/SLING-5831
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>  Labels: docs-impacting
> Fix For: Commons Scheduler 2.4.16
>
>
> Right now the scheduler uses a single thread pool. While this thread pool can 
> be configured, it means that all scheduled tasks share this pool. In order to 
> prioratize different tasks over others and avoid blocking important jobs 
> through unimportant once, we could maybe add a configuration property to 
> select a thread pool name.
> If a pool with that name exists, it's used - if not the default is used.



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

[jira] [Commented] (SLING-5685) Upgrade Commons IO to 2.5

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5685:


Ok, I understand. Since this a a test scope dependency only I am fine with that.

> Upgrade Commons IO to 2.5
> -
>
> Key: SLING-5685
> URL: https://issues.apache.org/jira/browse/SLING-5685
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
> Fix For: File System ClassLoader 1.0.4, Launchpad Karaf Features 
> 0.2.0, Scripting Thymeleaf 1.0.0, Health Check Core 1.2.6
>
> Attachments: commons-io.java.txt, commons-io.pom.txt
>
>




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

[jira] [Updated] (SLING-5603) Upgrade Commons Lang to 3.4

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5603:
---
Fix Version/s: (was: Health Check Core 1.2.6)

> Upgrade Commons Lang to 3.4
> ---
>
> Key: SLING-5603
> URL: https://issues.apache.org/jira/browse/SLING-5603
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Oliver Lietz
> Fix For: File System ClassLoader 1.0.4, Validation 1.0.0, 
> Launchpad Builder 9
>
> Attachments: commons-lang.java.txt, commons-lang.pom.txt
>
>
> use Commons Lang {{3.4}} and phase out older versions e.g. {{2.0}}, {{2.2}}, 
> {{2.4}}, {{2.5}}, {{2.6}}, {{3.0}}, {{3.0.1}}, {{3.3.2}}



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

[jira] [Commented] (SLING-5603) Upgrade Commons Lang to 3.4

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5603:


According to http://www.mail-archive.com/dev@sling.apache.org/msg56352.html I 
reverted the upgrade to commons-lang3 for hc.core in 
[r1753338|https://svn.apache.org/r1753338].

> Upgrade Commons Lang to 3.4
> ---
>
> Key: SLING-5603
> URL: https://issues.apache.org/jira/browse/SLING-5603
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Oliver Lietz
> Fix For: File System ClassLoader 1.0.4, Validation 1.0.0, 
> Launchpad Builder 9, Health Check Core 1.2.6
>
> Attachments: commons-lang.java.txt, commons-lang.pom.txt
>
>
> use Commons Lang {{3.4}} and phase out older versions e.g. {{2.0}}, {{2.2}}, 
> {{2.4}}, {{2.5}}, {{2.6}}, {{3.0}}, {{3.0.1}}, {{3.3.2}}



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

[jira] [Updated] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Ankit Agarwal (JIRA)]

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

Ankit Agarwal updated SLING-5866:
-
Issue Type: Improvement  (was: Bug)

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Amit Gupta (JIRA)]

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

Amit Gupta commented on SLING-5866:
---

[~anagarwa] can you propose a patch as well

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Commented] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Ankit Agarwal (JIRA)]

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

Ankit Agarwal commented on SLING-5866:
--

cc: [~cziegeler] [~fmeschbe] [~amitgupt]

> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Updated] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Ankit Agarwal (JIRA)]

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

Ankit Agarwal updated SLING-5866:
-
Description: 
As per current implementation any HEAD request will be handled by 
defaultHeadServlet which majorly does two changes

1.) coverts response output stream to be null so that there should be no 
message body in response
2.)  coverts HEAD request to GET request. 
Now this request is dispatched and served by defaultGetServlet.

With this approach, we get the desired output but response is delayed as it 
reads the complete binary data of a resource. and also it increases data 
transfer which is not needed.

So IMO this approach should be improved.

thanks,


  was:
As per current implementation any HEAD request will be handled by 
defaultHeadServlet which majorly does two changes

1.) coverts response output stream to be null so that there should be no 
message body in response
2.)  coverts head request to get request. 
Now this request is dispatched and served by defaultGetServlet.

With this approach, we get the desired output but response is delayed as it 
reads the complete binary data of a resource. and also it increases data 
transfer which is not needed.

So IMO this approach should be improved.

thanks,



> DefaultGetServlet obtains input stream for binary even if request is a HEAD
> ---
>
> Key: SLING-5866
> URL: https://issues.apache.org/jira/browse/SLING-5866
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.14
>Reporter: Ankit Agarwal
>
> As per current implementation any HEAD request will be handled by 
> defaultHeadServlet which majorly does two changes
> 1.) coverts response output stream to be null so that there should be no 
> message body in response
> 2.)  coverts HEAD request to GET request. 
> Now this request is dispatched and served by defaultGetServlet.
> With this approach, we get the desired output but response is delayed as it 
> reads the complete binary data of a resource. and also it increases data 
> transfer which is not needed.
> So IMO this approach should be improved.
> thanks,



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

[jira] [Created] (SLING-5866) DefaultGetServlet obtains input stream for binary even if request is a HEAD

[Ankit Agarwal (JIRA)]

Ankit Agarwal created SLING-5866:


 Summary: DefaultGetServlet obtains input stream for binary even if 
request is a HEAD
 Key: SLING-5866
 URL: https://issues.apache.org/jira/browse/SLING-5866
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Get 2.1.14
Reporter: Ankit Agarwal


As per current implementation any HEAD request will be handled by 
defaultHeadServlet which majorly does two changes

1.) coverts response output stream to be null so that there should be no 
message body in response
2.)  coverts head request to get request. 
Now this request is dispatched and served by defaultGetServlet.

With this approach, we get the desired output but response is delayed as it 
reads the complete binary data of a resource. and also it increases data 
transfer which is not needed.

So IMO this approach should be improved.

thanks,




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