Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #2057

[Apache Jenkins Server]

See 


--
[INFO] Deleting 

 (includes = [derby.log, cachedir, sling, jackrabbit], excludes = [])
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] Using bundle list file from 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.6/trunk/launchpad/builder/target/bundleList.xml
[INFO] Merging partial bundle list 
org.apache.sling:org.apache.sling.launchpad.test-bundles:0.0.1-SNAPSHOT
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/org.apache.sling.launchpad.test-bundles-0.0.1-SNAPSHOT-bundlelistconfig.zip
[INFO] Copying base artifact from 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.6/trunk/launchpad/base/target/org.apache.sling.launchpad.base-2.5.1-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.commons.log/3.0.3-SNAPSHOT/org.apache.sling.commons.log-3.0.3-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.commons.logservice/1.0.2/org.apache.sling.commons.logservice-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/jcl-over-slf4j/1.7.5/jcl-over-slf4j-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/log4j-over-slf4j/1.7.5/log4j-over-slf4j-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.settings/1.3.0/org.apache.sling.settings-1.3.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.fragment.xml/1.0.2/org.apache.sling.fragment.xml-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.fragment.transaction/1.0.0/org.apache.sling.fragment.transaction-1.0.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.javax.activation/0.1.0/org.apache.sling.javax.activation-0.1.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.fragment.ws/1.0.2/org.apache.sling.fragment.ws-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.launchpad.installer/1.2.0/org.apache.sling.launchpad.installer-1.2.0.jar
 to 

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2057

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #2057

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.6 #2057

[Apache Jenkins Server]

See 

Changes:

[cziegeler] [maven-release-plugin] prepare for next development iteration

[cziegeler] [maven-release-plugin] prepare release 
org.apache.sling.extensions.webconsolesecurityprovider-1.1.2

--
[...truncated 33239 lines...]
[INFO] Failsafe report directory: 

[WARNING] File encoding has not been set, using platform encoding 
ANSI_X3.4-1968, i.e. build is platform dependent!
[JENKINS] Recording test results[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT.jar

[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT.pom
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.launchpad.testing/7-SNAPSHOT/org.apache.sling.launchpad.testing-7-SNAPSHOT-bundlelist.xml
[INFO] Deleting 
 
(includes = [derby.log, cachedir, sling, jackrabbit], excludes = [])
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] Using bundle list file from 

[INFO] Merging partial bundle list 
org.apache.sling:org.apache.sling.launchpad.test-bundles:0.0.1-SNAPSHOT
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/org.apache.sling.launchpad.test-bundles-0.0.1-SNAPSHOT-bundlelistconfig.zip
[INFO] Copying base artifact from 

 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.commons.log/3.0.3-SNAPSHOT/org.apache.sling.commons.log-3.0.3-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.commons.logservice/1.0.2/org.apache.sling.commons.logservice-1.0.2.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/jcl-over-slf4j/1.7.5/jcl-over-slf4j-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/slf4j/log4j-over-slf4j/1.7.5/log4j-over-slf4j-1.7.5.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.settings/1.3.0/org.apache.sling.settings-1.3.0.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.fragment.xml/1.0.2/org.apache.sling.fragment.xml-1.0.2.jar
 to 

RE: some questions around job processing

[Amit.. Gupta.]

Hi Carsten,

Another additional question/assumption around job processing:
My current assumption is that we can keep queuing jobs in sling job queue 
without affecting the performance too much, job execution is anyways throttled 
with the type of queue ordered/max parallel jobs. So, we don't need to throttle 
while putting in the sling job queue.. 

Do you see any issue with such usage?

Thanks,
Amit

-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org] 
Sent: 12 December 2013 04:30
To: dev@sling.apache.org
Subject: Re: some questions around job processing

Hi Amit,


2013/12/12 Amit.. Gupta. 

> Hi devs,
>
> I have some questions around job processing in sling;
>
> 1.   What is the use case around -
> org.apache.sling.event.jobs.QueueConfiguration.Type#IGNORE. Code 
> suggests that such jobs are not assigned any target instance but are 
> persisted.
>

Yes, that's right - the idea is that you might want to suspend processing of a 
specific job type for some time (maintenance, heavy load etc.). Once you want 
to enable it, you either remove the config with IGNORE or change it to another 
type and the jobs will be processed.


>
> 2.   For parallel and round robin queues, target instance id is
> selected on a round robin basis from potential targets. Is this 
> assignment only happening on the leader? Or can job assignment happen 
> on any instance in the cluster? Asking this question as 
> org.apache.sling.event.impl.jobs.TopologyCapabilities#roundRobinMap is 
> a local variable.
>
> This assignment happens on all instances and therefore is not a true 
> round
robin as each instance assigns the jobs round robin solely on its own 
information - but it's the closest we can do without having a communication 
between the instances.



> 3.   If an instance dies then MaintenanceTask on leader takes of
> reassigning all its job. Is this the correct understanding?
>
> Yes, that's right

Regards
Carsten


> Thanks,
> Amit
>



--
Carsten Ziegeler
cziege...@apache.org

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

[Carsten Ziegeler]

I think you missunderstood me, or we're maybe talking about different
things - as repeatedly stated we don't need to change the resource resolver
- we have everything in place; and now we exactly need to define the use
cases to know how the flags api should look like and which possibilites it
has. The implementation of that api can do all kinds of stuff like using
thread locals to access the current request etc.

Carsten


2013/12/13 Alexander Klimetschek 

> On 11.12.2013, at 19:10, Carsten Ziegeler  wrote:
>
> > I think we're pretty clear now how we could implement this, basically
> > everything is in place, so the resource resolver has all features we need
> > in the way we need them. And we should now start defining the feature
> flags
> > api.
>
> Did you read my post? ;) I don't see the open question on how dynamic
> those flags get into the resource resolver being answered, at least not
> here.
>
> I think it really makes sense to experiment with that in an existing
> service interface, let applications be written with that, and figure out
> what the use cases are, before bending the resource resolver in any
> direction.
>
> Cheers,
> Alex
>



-- 
Carsten Ziegeler
cziege...@apache.org

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

[Alexander Klimetschek]

On 11.12.2013, at 19:10, Carsten Ziegeler  wrote:

> I think we're pretty clear now how we could implement this, basically
> everything is in place, so the resource resolver has all features we need
> in the way we need them. And we should now start defining the feature flags
> api.

Did you read my post? ;) I don't see the open question on how dynamic those 
flags get into the resource resolver being answered, at least not here.

I think it really makes sense to experiment with that in an existing service 
interface, let applications be written with that, and figure out what the use 
cases are, before bending the resource resolver in any direction.

Cheers,
Alex

[jira] [Commented] (SLING-3279) Leverage improved observation support from Oak

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3279:
-

Ok, actually these are three things:
a) provide an alternative JcrResourceListener directly using Oak feature
b) Thinking about event listening/delivery optimization
c) Optimizing thread usage

The no. 1 prio is of course on a) and as I wrote, these needs to be done in a 
compatible way. So I suggest we do this first

Just for completeness: as mentioned c) should be easy and b) is reall 
questionable as I know that we have a lot of listeners listening for all 
changes in the repository. But let's do a) first

> Leverage improved observation support from Oak
> --
>
> Key: SLING-3279
> URL: https://issues.apache.org/jira/browse/SLING-3279
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Michael Dürig
>
> OAK-1120 introduces better support for observation, which could be used by 
> Sling. For example JcrResourceListener could be rewritten leveraging Oak's 
> Observer. Since Oak observers already run on background threads further 
> decoupling (like it is currently done) is not necessary. This makes it 
> unnecessary to queue potentially a lot of events in Sling. Since neither Oak 
> there does queue events (they are generated by need) this will probably 
> greatly improve scalability in the face of many events. 
> Furthermore OSGi filters could be passed down and translated to Oak such that 
> filtering is done much closer to the source of the events. 
> Finally instead of using a centralised event dispatcher (like 
> JcrResourceListener  currently is) it would be better to install a dedicated 
> Observer for each OSGi event listener since dispatching is already handled by 
> Oak and thread pooling (i.e. assigning threads for dispatching call backs to 
> observers) can be controlled through Sling's thread pool support (*). This 
> has the further advantage of making individual stats available for the 
> listeners through JMX.
> (*) Register an OakExecutor backed by e.g. a Sling thread pool and it will be 
> picked up by Oak.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (SLING-3281) Expose replication queue items information

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-3281:
---

Attachment: SLING-3281.patch

patch which adds _ReplicationQueue#getItems_ method (and fixes #isEmpty for the 
JobHandling based queue).

> Expose replication queue items information
> --
>
> Key: SLING-3281
> URL: https://issues.apache.org/jira/browse/SLING-3281
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Tommaso Teofili
> Attachments: SLING-3281.patch
>
>
> It'd be useful to have more information on the items contained in a 
> replication queue being still be able to process one item at a time.
> This will ease the monitoring of what's in the replication queues. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Created] (SLING-3281) Expose replication queue items information

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-3281:
--

 Summary: Expose replication queue items information
 Key: SLING-3281
 URL: https://issues.apache.org/jira/browse/SLING-3281
 Project: Sling
  Issue Type: Task
  Components: Extensions
Reporter: Tommaso Teofili


It'd be useful to have more information on the items contained in a replication 
queue being still be able to process one item at a time.
This will ease the monitoring of what's in the replication queues. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Comment Edited] (SLING-3278) Provide a HealthCheckExecutor service

[Georg Henzler (JIRA)]

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

Georg Henzler edited comment on SLING-3278 at 12/12/13 2:29 PM:


The property for async execution property can make sense when you want to make 
sure a check is called not as often as the health check itself (e.g. only twice 
a day).

I'm pretty much done, No 2 of Bertrand's list and unit tests are missing if you 
like you can have a look at the patches to give feedback before I submit a 
final one.

Impl Notes:
* The main entry method is 
org.apache.sling.hc.core.executor.HealthCheckExecutor.runAllForTags(String...)
* Results are cached for 2sec by default (configurable)
* Results have now a HealthCheckDescriptor that contains meta info for the 
check (also used in the executor as cache key etc.) 
* Async is supported by attribute hc.async.cronExpression, a service listener 
is in place for registering/unregistering of jobs 
(org.apache.sling.hc.core.executor.AsyncHealthCheckExecutor)
* I did add a natural order to results (failed tests first, then by name 
alphabetically) - if not using this the order would be arbitrary (depending on 
execution time)
* The result has an additional finishDate and elapsedTime (I think finish date 
is more interesting for caching than the start date!)

Other thoughts (not in patch):
* I'm not sure if the CompositeHealthCheck makes sense - is this not a grouping 
competing with the tags? It is easy to configure it in a way that some checks 
are executed twice, especially if you run all checks without giving a tag (and 
the HealthCheckExecutor cannot prevent it as the CompositeHealthCheck looks 
like any other check to it)
* Exceptions: The result should be able to carry a exception - I would even go 
as far as adding "throws Exception" to the execute() signature (this would not 
break any existing implementation classes) and generically add a last critical 
log if the HC happens to throw an exception


was (Author: henzlerg):
The property for async execution property can make sense when you want to make 
sure a check is called not as often as the health check itself (e.g. only twice 
a day).

I'm pretty much done, No 2 of Bertrand's list and unit tests are missing if you 
like you can have a look at the patches to give feedback before I submit a 
final one.

Impl Notes:
* The main entry method is 
org.apache.sling.hc.core.executor.HealthCheckExecutor.runAllForTags(String...)
* Results have now a HealthCheckDescriptor that contains meta info for the 
check (also used in the executor as cache key etc.) 
* Async is supported by attribute hc.async.cronExpression, a service listener 
is in place for registering/unregistering of jobs 
(org.apache.sling.hc.core.executor.AsyncHealthCheckExecutor)
* I did add a natural order to results (failed tests first, then by name 
alphabetically) - if not using this the order would be arbitrary (depending on 
execution time)
* The result has an additional finishDate and elapsedTime (I think finish date 
is more interesting for caching than the start date!)

Other thoughts (not in patch):
* I'm not sure if the CompositeHealthCheck makes sense - is this not a grouping 
competing with the tags? It is easy to configure it in a way that some checks 
are executed twice, especially if you run all checks without giving a tag (and 
the HealthCheckExecutor cannot prevent it as the CompositeHealthCheck looks 
like any other check to it)
* Exceptions: The result should be able to carry a exception - I would even go 
as far as adding "throws Exception" to the execute() signature (this would not 
break any existing implementation classes) and generically add a last critical 
log if the HC happens to throw an exception

> Provide a HealthCheckExecutor service
> -
>
> Key: SLING-3278
> URL: https://issues.apache.org/jira/browse/SLING-3278
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Reporter: Georg Henzler
>Assignee: Georg Henzler
> Attachments: 
> SLING-3278-hc.core-HealthCheckExecutorService-v0.5.patch, 
> SLING-3278-hc.webconsole-v0.5.patch
>
>
> Goals:
> * Be able to get an overall (aggregated) result as quickly as possible 
> (ideally <2sec)
> * Whenever possible, return most current results (e.g. for a memory check)
> * Provide a declarative way for async checks (async checks should be the 
> exception though) 
> Approach
> * Run checks in parallel
> * Make sure long running (or even stuck) checks are timed out
> * If a health check must run asynchronously (because its execution time 
> cannot be optimized), it should be enough to just specify a service property 
> (e.g. "hc.async").
> See also
> http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td40

[jira] [Commented] (SLING-3278) Provide a HealthCheckExecutor service

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-3278:
--

The property for async execution property can make sense when you want to make 
sure a check is called not as often as the health check itself (e.g. only twice 
a day).

I'm pretty much done, No 2 of Bertrand's list and unit tests are missing if you 
like you can have a look at the patches to give feedback before I submit a 
final one.

Impl Notes:
* The main entry method is 
org.apache.sling.hc.core.executor.HealthCheckExecutor.runAllForTags(String...)
* Results have now a HealthCheckDescriptor that contains meta info for the 
check (also used in the executor as cache key etc.) 
* Async is supported by attribute hc.async.cronExpression, a service listener 
is in place for registering/unregistering of jobs 
(org.apache.sling.hc.core.executor.AsyncHealthCheckExecutor)
* I did add a natural order to results (failed tests first, then by name 
alphabetically) - if not using this the order would be arbitrary (depending on 
execution time)
* The result has an additional finishDate and elapsedTime (I think finish date 
is more interesting for caching than the start date!)

Other thoughts (not in patch):
* I'm not sure if the CompositeHealthCheck makes sense - is this not a grouping 
competing with the tags? It is easy to configure it in a way that some checks 
are executed twice, especially if you run all checks without giving a tag (and 
the HealthCheckExecutor cannot prevent it as the CompositeHealthCheck looks 
like any other check to it)
* Exceptions: The result should be able to carry a exception - I would even go 
as far as adding "throws Exception" to the execute() signature (this would not 
break any existing implementation classes) and generically add a last critical 
log if the HC happens to throw an exception

> Provide a HealthCheckExecutor service
> -
>
> Key: SLING-3278
> URL: https://issues.apache.org/jira/browse/SLING-3278
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Reporter: Georg Henzler
>Assignee: Georg Henzler
> Attachments: 
> SLING-3278-hc.core-HealthCheckExecutorService-v0.5.patch, 
> SLING-3278-hc.webconsole-v0.5.patch
>
>
> Goals:
> * Be able to get an overall (aggregated) result as quickly as possible 
> (ideally <2sec)
> * Whenever possible, return most current results (e.g. for a memory check)
> * Provide a declarative way for async checks (async checks should be the 
> exception though) 
> Approach
> * Run checks in parallel
> * Make sure long running (or even stuck) checks are timed out
> * If a health check must run asynchronously (because its execution time 
> cannot be optimized), it should be enough to just specify a service property 
> (e.g. "hc.async").
> See also
> http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402
> http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (SLING-3278) Provide a HealthCheckExecutor service

[Georg Henzler (JIRA)]

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

Georg Henzler updated SLING-3278:
-

Attachment: SLING-3278-hc.webconsole-v0.5.patch
SLING-3278-hc.core-HealthCheckExecutorService-v0.5.patch

> Provide a HealthCheckExecutor service
> -
>
> Key: SLING-3278
> URL: https://issues.apache.org/jira/browse/SLING-3278
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Reporter: Georg Henzler
>Assignee: Georg Henzler
> Attachments: 
> SLING-3278-hc.core-HealthCheckExecutorService-v0.5.patch, 
> SLING-3278-hc.webconsole-v0.5.patch
>
>
> Goals:
> * Be able to get an overall (aggregated) result as quickly as possible 
> (ideally <2sec)
> * Whenever possible, return most current results (e.g. for a memory check)
> * Provide a declarative way for async checks (async checks should be the 
> exception though) 
> Approach
> * Run checks in parallel
> * Make sure long running (or even stuck) checks are timed out
> * If a health check must run asynchronously (because its execution time 
> cannot be optimized), it should be enough to just specify a service property 
> (e.g. "hc.async").
> See also
> http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402
> http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (SLING-3280) Remove old agents in agents directory

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-3280:
---

Attachment: SLING-3280.patch

trivial patch for the removal of duplicated agent configs

> Remove old agents in agents directory
> -
>
> Key: SLING-3280
> URL: https://issues.apache.org/jira/browse/SLING-3280
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Tommaso Teofili
> Attachments: SLING-3280.patch
>
>
> Agent configurations in SLING-CONTENT/libs/sling/replication/agents should be 
> removed as they were split into 
> SLING-CONTENT/libs/sling/replication/configuration/[author|publish] as part 
> of SLING-3265



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Created] (SLING-3280) Remove old agents in agents directory

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-3280:
--

 Summary: Remove old agents in agents directory
 Key: SLING-3280
 URL: https://issues.apache.org/jira/browse/SLING-3280
 Project: Sling
  Issue Type: Task
  Components: Extensions
Reporter: Tommaso Teofili


Agent configurations in SLING-CONTENT/libs/sling/replication/agents should be 
removed as they were split into 
SLING-CONTENT/libs/sling/replication/configuration/[author|publish] as part of 
SLING-3265



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3179:
--

[~marett] may you please provide an SVN patch :) ?

> Implement solution to the Authentication Handler Credential Validation Problem
> --
>
> Key: SLING-3179
> URL: https://issues.apache.org/jira/browse/SLING-3179
> Project: Sling
>  Issue Type: Bug
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6
>Reporter: Felix Meschberger
>Assignee: Antonio Sanso
> Attachments: SLING-3179.diff
>
>
> The proposal [Solving the Authentication Handler Credential Validation 
> Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem]
>  should be implemented.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Assigned] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem

[Antonio Sanso (JIRA)]

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

Antonio Sanso reassigned SLING-3179:


Assignee: Antonio Sanso

> Implement solution to the Authentication Handler Credential Validation Problem
> --
>
> Key: SLING-3179
> URL: https://issues.apache.org/jira/browse/SLING-3179
> Project: Sling
>  Issue Type: Bug
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6
>Reporter: Felix Meschberger
>Assignee: Antonio Sanso
> Attachments: SLING-3179.diff
>
>
> The proposal [Solving the Authentication Handler Credential Validation 
> Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem]
>  should be implemented.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Assigned] (SLING-2762) AbstractSlingRepository#login violates JCR spec

[Antonio Sanso (JIRA)]

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

Antonio Sanso reassigned SLING-2762:


Assignee: Antonio Sanso

> AbstractSlingRepository#login violates JCR spec
> ---
>
> Key: SLING-2762
> URL: https://issues.apache.org/jira/browse/SLING-2762
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>
> AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
> The API [0] says
> " If credentials is null, it is assumed that authentication is handled by a 
> mechanism external to the repository itself (for example, through the JAAS 
> framework) and that the repository implementation exists within a context 
> (for example, an application server) that allows it to handle authorization 
> of the request for access to the specified workspace."
> while the implementation looks like
> {code}
> ...
> if (credentials == null) {
> credentials = getAnonCredentials(this.anonUser);
> }
> ...
> {code}
> [0] 
> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-2762:
--

bq. Will you also take care of the patch provided by Tim for SLING-3179 ? 

yes I can try :)

> AbstractSlingRepository#login violates JCR spec
> ---
>
> Key: SLING-2762
> URL: https://issues.apache.org/jira/browse/SLING-2762
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>
> AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
> The API [0] says
> " If credentials is null, it is assumed that authentication is handled by a 
> mechanism external to the repository itself (for example, through the JAAS 
> framework) and that the repository implementation exists within a context 
> (for example, an application server) that allows it to handle authorization 
> of the request for access to the specified workspace."
> while the implementation looks like
> {code}
> ...
> if (credentials == null) {
> credentials = getAnonCredentials(this.anonUser);
> }
> ...
> {code}
> [0] 
> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-2762:
--

[~asanso] Yes. Will you also take care of the patch provided by Tim for 
SLING-3179 ? Thanks.

> AbstractSlingRepository#login violates JCR spec
> ---
>
> Key: SLING-2762
> URL: https://issues.apache.org/jira/browse/SLING-2762
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>
> AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
> The API [0] says
> " If credentials is null, it is assumed that authentication is handled by a 
> mechanism external to the repository itself (for example, through the JAAS 
> framework) and that the repository implementation exists within a context 
> (for example, an application server) that allows it to handle authorization 
> of the request for access to the specified workspace."
> while the implementation looks like
> {code}
> ...
> if (credentials == null) {
> credentials = getAnonCredentials(this.anonUser);
> }
> ...
> {code}
> [0] 
> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-2762:
--

I'd be inclined to apply the patch included by [~fmeschbe] and [~anchela] in 
https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem

namely 

{code}

if (credentials == null) {
if (Subject.getSubject(AccessController.getContext()) != null) {
return getRepository().login(null, workspace);
} else {
// TODO: getAnonCredentials(this.anonUser) should not be used for 
anonymous access
return getRepository().login(new GuestCredentials(), workspace);
}
} else {
return getRepository().login(credentials, workspace);
}
{code}

WDYT?

> AbstractSlingRepository#login violates JCR spec
> ---
>
> Key: SLING-2762
> URL: https://issues.apache.org/jira/browse/SLING-2762
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>
> AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
> The API [0] says
> " If credentials is null, it is assumed that authentication is handled by a 
> mechanism external to the repository itself (for example, through the JAAS 
> framework) and that the repository implementation exists within a context 
> (for example, an application server) that allows it to handle authorization 
> of the request for access to the specified workspace."
> while the implementation looks like
> {code}
> ...
> if (credentials == null) {
> credentials = getAnonCredentials(this.anonUser);
> }
> ...
> {code}
> [0] 
> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Issue Comment Deleted] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-3179:
-

Comment: was deleted

(was: [~marett] may you please provide an SVN compatible patch ?

Thanks)

> Implement solution to the Authentication Handler Credential Validation Problem
> --
>
> Key: SLING-3179
> URL: https://issues.apache.org/jira/browse/SLING-3179
> Project: Sling
>  Issue Type: Bug
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6
>Reporter: Felix Meschberger
> Attachments: SLING-3179.diff
>
>
> The proposal [Solving the Authentication Handler Credential Validation 
> Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem]
>  should be implemented.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-3179) Implement solution to the Authentication Handler Credential Validation Problem

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3179:
--

[~marett] may you please provide an SVN compatible patch ?

Thanks

> Implement solution to the Authentication Handler Credential Validation Problem
> --
>
> Key: SLING-3179
> URL: https://issues.apache.org/jira/browse/SLING-3179
> Project: Sling
>  Issue Type: Bug
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Base 2.1.2, API 2.4.2, Resource Resolver 1.0.6
>Reporter: Felix Meschberger
> Attachments: SLING-3179.diff
>
>
> The proposal [Solving the Authentication Handler Credential Validation 
> Problem|https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem]
>  should be implemented.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (SLING-3279) Leverage improved observation support from Oak

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3279:


There isn't more to my f2f conversation with Michael than what I mentioned 
above, he just showed me how the new Oak observation stuff works. My notes 
above are just rough ideas, everything's still open in terms of implementation 
as far as I'm concerned.

I think we are actually discussing two distinct things:

a) Ideally, JcrResourceListener should not listen to more JCR/Oak events than 
it actually needs to supply the OSGi EventHandlers that are listening to its 
OSGi events. This is where we might analyze the set of  event.topics and/or 
event.filter service properties of registered EventHandlers, to find out which 
OSGi events must be sent. We can then derive an optimized JCR/Oak observation 
setup from that.

b) Optimize how threads are used to deliver JCR/Oak events, this is a separate 
concern and might be totally independent of a)

> Leverage improved observation support from Oak
> --
>
> Key: SLING-3279
> URL: https://issues.apache.org/jira/browse/SLING-3279
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Michael Dürig
>
> OAK-1120 introduces better support for observation, which could be used by 
> Sling. For example JcrResourceListener could be rewritten leveraging Oak's 
> Observer. Since Oak observers already run on background threads further 
> decoupling (like it is currently done) is not necessary. This makes it 
> unnecessary to queue potentially a lot of events in Sling. Since neither Oak 
> there does queue events (they are generated by need) this will probably 
> greatly improve scalability in the face of many events. 
> Furthermore OSGi filters could be passed down and translated to Oak such that 
> filtering is done much closer to the source of the events. 
> Finally instead of using a centralised event dispatcher (like 
> JcrResourceListener  currently is) it would be better to install a dedicated 
> Observer for each OSGi event listener since dispatching is already handled by 
> Oak and thread pooling (i.e. assigning threads for dispatching call backs to 
> observers) can be controlled through Sling's thread pool support (*). This 
> has the further advantage of making individual stats available for the 
> listeners through JMX.
> (*) Register an OakExecutor backed by e.g. a Sling thread pool and it will be 
> picked up by Oak.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)