Jenkins build is still unstable: sling-contrib-1.7 #161
See https://builds.apache.org/job/sling-contrib-1.7/161/
[jira] [Updated] (SLING-4755) DiscoveryService isn't shutdown aware
[
https://issues.apache.org/jira/browse/SLING-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4755:
---
Issue Type: Improvement (was: Bug)
DiscoveryService isn't shutdown aware
-
Key: SLING-4755
URL: https://issues.apache.org/jira/browse/SLING-4755
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: Discovery Impl 1.0.10
Environment: AEM 6 SP2
Reporter: Ilyas Türkben
Assignee: Stefan Egli
Priority: Blocker
Fix For: Discovery Impl 1.1.6
DiscoveryServiceImpl seems to perform write operations and require repository
reference during a shutdown and it blocks the shutdown for a unpredictable
time(here, almost 26 minutes).
*Error log*
{code:java}
26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl
Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131]
ServiceEvent UNREGISTERING
26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository
Service [5185] ServiceEvent REGISTERED
26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository
Service [5185] ServiceEvent UNREGISTERING
{code}
*Thread dump for Thread-60*
{code:java}
Thread-60 daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable
[0x7f783b0ea000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
at com.mongodb.OutMessage.pipe(OutMessage.java:236)
at com.mongodb.DBPort$1.execute(DBPort.java:140)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked 0x00050a8eee30 (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
at com.mongodb.DBCursor._check(DBCursor.java:458)
at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
at
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
- locked 0x000768234398 (a
com.google.common.cache.LocalCache$StrongAccessEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
at
org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.remove(ContentMirrorStoreStrategy.java:110)
at
[jira] [Updated] (SLING-4385) TopologyEventTest.testNonDelayedInitEvent test failure
[
https://issues.apache.org/jira/browse/SLING-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4385:
---
Fix Version/s: (was: Discovery Impl 1.1.6)
Discovery Impl 1.1.8
TopologyEventTest.testNonDelayedInitEvent test failure
--
Key: SLING-4385
URL: https://issues.apache.org/jira/browse/SLING-4385
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Impl 1.1.8
TopologyEventTest.testNonDelayedInitEvent sometimes fails.
eg:
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/695/testReport/junit/org.apache.sling.discovery.impl.cluster/TopologyEventTest/testNonDelayedInitEvent/
{code}
java.lang.AssertionError: expected:2 but was:1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.sling.discovery.impl.cluster.TopologyEventTest.testNonDelayedInitEvent(TopologyEventTest.java:255)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4640) Possibility of duplicate leaders w/discovery.impl on eventually consistent repo
[
https://issues.apache.org/jira/browse/SLING-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4640:
---
Fix Version/s: (was: Discovery Impl 1.1.6)
Discovery Impl 1.1.8
Possibility of duplicate leaders w/discovery.impl on eventually consistent
repo
---
Key: SLING-4640
URL: https://issues.apache.org/jira/browse/SLING-4640
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.1.0
Reporter: Stefan Egli
Fix For: Discovery Impl 1.1.8
Note: This is a fork of SLING-3432 based on a
[comment|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14495936page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495936].
So here is that comment again:
Note that [the
above|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
does not solve the problem where the underlying repository is eventually
consistent and the heartbeat configured is too low to catch all possible
delays (that such an eventually consistent repository might produce under
load). Consider the following:
# a cluster consisting of 3 nodes: A, B and C, A is the leader
# writes from B and C are fast - and can be read by all 3 nodes fast
# writes from A though are slow (ie A behaves asymmetric: slow writes but
fast reads)
# at some point writes from A are slower than the configured heartbeat
timeout: at this point B and C find out about this and vote on a new
clusterView consisting only of B and C and (let's say) B becomes leader.
#* meanwhile at A however: A is still happy: it sees the heartbeats of B and
C in time and would not start a new voting.
# at some later point (with a *certain read delay*) A sees that B and C have
declared a new {{/establishedViews}} - at this point it would (according to
the new rule above) immediately send a TOPOLOGY_CHANGING and things would be
'ok' again.
#* *but* until it does send this event - *between 4. and 5. - we have two
leaders: A and B*! - thus could see issues reported here in SLING-3432 still
during that small timeframe (which is basically the amount of time it takes
for the new established view declared by B and C to be read by A).
#* at a later time, when eg the delays in the repository have come down, A
would rejoin the cluster - but would have to *not become leader* again, as
the leader is B and must stay stable.
This IMHO highlights the problem that using an eventually consistent
repository (that has no max guaranteed delay) is *not*
pseudo-network-partition/duplicate-leader free under load.
Note that what is described here is not fixed by SLING-4627.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4590) topology console reporting a inconsistent state of topology for isolated cluster node
[ https://issues.apache.org/jira/browse/SLING-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4590: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 topology console reporting a inconsistent state of topology for isolated cluster node - Key: SLING-4590 URL: https://issues.apache.org/jira/browse/SLING-4590 Project: Sling Issue Type: Bug Components: Console Affects Versions: Discovery Impl 1.1.0 Reporter: Michael Tarantino Priority: Minor Fix For: Discovery Impl 1.1.8 After a split because of a heart beat timeout, the topology console is reporting an inconsistence state of the topology. The screenshot below shows 4 instances while the local cluster node is isolated from the rest of the cluster. ||Sling id || ClusterView id || Local instance || Leader instance || In local cluster|| Announced by instance || | 0d08c47d-6a1b-48d2-87b2-f88813da03f5 | f07aec64-4289-4b07-becc-dfdd76178f04 | false | false | remote | (changing) | | 9d2bad89-bba7-47d8-bcf7-090d7989a747 | f07aec64-4289-4b07-becc-dfdd76178f04 | false | false | remote | (changing) | | c1d45df4-8703-4ada-85db-ae597cda8032 | f07aec64-4289-4b07-becc-dfdd76178f04 | true | true | local | n/a | | c26b9027-c367-425e-8fa4-8b595f476473 | f07aec64-4289-4b07-becc-dfdd76178f04 | false | false | remote | (changing) | The issue might be located between 'topology.getLocalInstance().getClusterView()' and 'clusterViewService.contains' which seem to differ with the isolated cluster mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4135) Make discovery implementation independent from JCR
[ https://issues.apache.org/jira/browse/SLING-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4135: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 Make discovery implementation independent from JCR -- Key: SLING-4135 URL: https://issues.apache.org/jira/browse/SLING-4135 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Fix For: Discovery Impl 1.1.8 There are only a few calls to the JCR api - in order to make it completely use just the Sling API these places should be changed to the Sling API as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4587) Increase ClusterTest stability
[ https://issues.apache.org/jira/browse/SLING-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4587: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 Increase ClusterTest stability -- Key: SLING-4587 URL: https://issues.apache.org/jira/browse/SLING-4587 Project: Sling Issue Type: Test Components: Extensions Affects Versions: Discovery Impl 1.1.0 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.1.8 There are some infrequent test failures with ClusterTest atm. This is to keep track of them and get them fixed. Individual test failures fixes in comments below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4380) Use sling mocks for the discovery impl tests
[ https://issues.apache.org/jira/browse/SLING-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4380: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 Use sling mocks for the discovery impl tests Key: SLING-4380 URL: https://issues.apache.org/jira/browse/SLING-4380 Project: Sling Issue Type: Improvement Components: Extensions, Testing Affects Versions: Discovery Impl 1.0.12 Reporter: Robert Munteanu Fix For: Discovery Impl 1.1.8 The org.apache.sling.discovery.impl has its own utility mocks in https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/discovery/impl/src/test/java/org/apache/sling/discovery/impl/setup/ . Most of these can be replaced by the new Sling mocks. The benefits would be: - less maintenance for the discovery impl project - more exposure/coverage for the Sling mocks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4622) Sporadic discovery test failures
[ https://issues.apache.org/jira/browse/SLING-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4622: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 Sporadic discovery test failures Key: SLING-4622 URL: https://issues.apache.org/jira/browse/SLING-4622 Project: Sling Issue Type: Bug Components: Extensions Reporter: Carsten Ziegeler Labels: sling-IT Fix For: Discovery Impl 1.1.8 It seems we have sporadic test failures with the discovery impl, see e.g. https://builds.apache.org/job/sling-trunk-1.8/982/org.apache.sling$org.apache.sling.discovery.impl/ with three test failures: org.apache.sling.discovery.impl.cluster.ClusterTest.testLeaderDesc org.apache.sling.discovery.impl.cluster.ClusterTest.testDuplicateInstance3726 org.apache.sling.discovery.impl.cluster.TopologyEventTest.testDelayedInitEvent In detail: java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.junit.Assert.assertFalse(Assert.java:74) at org.apache.sling.discovery.impl.cluster.ClusterTest.doTestLeader(ClusterTest.java:189) at org.apache.sling.discovery.impl.cluster.ClusterTest.testLeaderDesc(ClusterTest.java:147) java.lang.AssertionError: could not find a match in the topology with instance=c4ede060-31fd-4f3e-8e0b-a22086db22a1 and clusterViews=3 at org.junit.Assert.fail(Assert.java:88) at org.apache.sling.discovery.impl.cluster.ClusterTest.assertTopology(ClusterTest.java:767) at org.apache.sling.discovery.impl.cluster.ClusterTest.assertSameTopology(ClusterTest.java:542) at org.apache.sling.discovery.impl.cluster.ClusterTest.testDuplicateInstance3726(ClusterTest.java:526) java.lang.AssertionError: expected:0 but was:1 at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:555) at org.junit.Assert.assertEquals(Assert.java:542) at org.apache.sling.discovery.impl.cluster.TopologyEventTest.testDelayedInitEvent(TopologyEventTest.java:158) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3432) pseudo network partition causes job deserialization issue in a cluster (when reading while job is being reassigned)
[ https://issues.apache.org/jira/browse/SLING-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-3432: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 pseudo network partition causes job deserialization issue in a cluster (when reading while job is being reassigned) --- Key: SLING-3432 URL: https://issues.apache.org/jira/browse/SLING-3432 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.1.8 There is a race condition between two instances in a cluster (eg oak or crx): Instance 1 is writing a job with a binary property, instance 2 is reading the job (likely triggered by discovery sending it a topologychangedevent). It looks like instance 2 is reading the job just about while instance 1 is still in the process or completely writing the job, or at least the binary. Resulting in the following exception: 04.03.2014 06:55:39.667 *WARN* [Apache Sling Job Background Loader] org.apache.sling.event.impl.jobs.JobManagerImpl Unable to read job from /var/eventing/jobs/assigned/e4337f8f-47d2-41df-b3ab-0d40b1b2acd4/slingevent:eventadmin/2014/3/3/8/45/cq.wcm.msm.job.pageEvent_9718d7db-85b4-4930-a2ba-11a80d772970_172 java.lang.Exception: Unable to deserialize property 'pageEvent' at org.apache.sling.event.impl.support.ResourceHelper.cloneValueMap(ResourceHelper.java:213) at org.apache.sling.event.impl.jobs.JobManagerImpl.readJob(JobManagerImpl.java:538) at org.apache.sling.event.impl.jobs.BackgroundLoader.loadJobInTheBackground(BackgroundLoader.java:318) at org.apache.sling.event.impl.jobs.BackgroundLoader.loadJobsInTheBackground(BackgroundLoader.java:294) at org.apache.sling.event.impl.jobs.BackgroundLoader.run(BackgroundLoader.java:203) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779) at java.io.ObjectInputStream.init(ObjectInputStream.java:279) at org.apache.sling.event.impl.support.ResourceHelper.cloneValueMap(ResourceHelper.java:208) ... 5 common frames omitted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4761) Latest view seems to get marked as not current
[ https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-4761: --- Fix Version/s: (was: Discovery Impl 1.1.6) Discovery Impl 1.1.8 Latest view seems to get marked as not current -- Key: SLING-4761 URL: https://issues.apache.org/jira/browse/SLING-4761 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.1.0, Discovery Impl 1.1.2 Reporter: Carsten Ziegeler Assignee: Stefan Egli Fix For: Discovery Impl 1.1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Apache Sling Commons Scheduler
Hi, We solved two issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12329585 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1258/ 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 1258 /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
[jira] [Updated] (SLING-4359) LargeTopologyWithHubTest.testLargeTopologyWithHub test failure
[
https://issues.apache.org/jira/browse/SLING-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-4359:
---
Fix Version/s: (was: Discovery Impl 1.1.6)
Discovery Impl 1.1.8
LargeTopologyWithHubTest.testLargeTopologyWithHub test failure
--
Key: SLING-4359
URL: https://issues.apache.org/jira/browse/SLING-4359
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Impl 1.1.8
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/1376/testReport/org.apache.sling.discovery.impl.topology/LargeTopologyWithHubTest/testLargeTopologyWithHub/
{code}
java.lang.AssertionError: expected:101 but was:43
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.sling.discovery.impl.topology.TopologyTestHelper.assertTopologyConsistsOf(TopologyTestHelper.java:127)
at
org.apache.sling.discovery.impl.topology.LargeTopologyWithHubTest.testLargeTopologyWithHub(LargeTopologyWithHubTest.java:84)
{code}
grepping for log.info testLargeTopologyWithHub shows :
{code}
28.01.2015 08:16:25 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 47 Instances
...
28.01.2015 08:16:32 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 46 Instances
...
28.01.2015 08:16:38 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 45 Instances
...
28.01.2015 08:16:44 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 44 Instances
{code}
basically the instances die one after each other - probably due to no longer
sending heartbeats. I'll check
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4777) Decouple the model provider from the actual validation service
[ https://issues.apache.org/jira/browse/SLING-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580473#comment-14580473 ] Carsten Ziegeler commented on SLING-4777: - [~kwin] Thanks for taking this up, this looks basically good for me (haven't checked in detail). I think, if Radu agrees, we should apply this and then do another review round on the result Decouple the model provider from the actual validation service -- Key: SLING-4777 URL: https://issues.apache.org/jira/browse/SLING-4777 Project: Sling Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Validation 1.0.0 As being mentioned in SLING-4027, it would be good to completely decouple the model providing capabilities from the actual validation, as that would a) make the codebase cleaner (and would ease testing) b) allow to plug-in other services which provide models (e.g. based on annotations on some files) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Commons Scheduler
+1 Cheers, Stefan On 6/10/15 2:32 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved two issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12329585 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1258/ 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 1258 /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
[RESULT][VOTE] Release Apache Sling discovery.impl 1.1.4
On 6/5/15 9:53 AM, Stefan Egli stefane...@apache.org wrote: Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1255/ The vote passed with three binding +1 from Robert, Carsten and myself, and two non-binding +1 from Timothée and Tommaso. Thanks, Cheers, Stefan
[jira] [Created] (SLING-4794) SchedulerServiceFactory.fireJobAt ignores date, thus fires immediately
Stefan Egli created SLING-4794: -- Summary: SchedulerServiceFactory.fireJobAt ignores date, thus fires immediately Key: SLING-4794 URL: https://issues.apache.org/jira/browse/SLING-4794 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Scheduler 2.4.6 Reporter: Stefan Egli Assignee: Carsten Ziegeler Fix For: Commons Scheduler 2.4.8 [SchedulerServiceFactory.fireJobAt 'swallows' the date by calling scheduler.fireJob() instead of scheduler.fireJobAt()|https://github.com/apache/sling/blob/dbf5122bb38cd011a5cd88cd6540acf8a98a9e82/bundles/commons/scheduler/src/main/java/org/apache/sling/commons/scheduler/impl/SchedulerServiceFactory.java#L150] - with the effect that it fires immediately instead of delaying. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4794) SchedulerServiceFactory.fireJobAt ignores date, thus fires immediately
[ https://issues.apache.org/jira/browse/SLING-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4794. - Resolution: Fixed Fixed copy/paste error SchedulerServiceFactory.fireJobAt ignores date, thus fires immediately -- Key: SLING-4794 URL: https://issues.apache.org/jira/browse/SLING-4794 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Scheduler 2.4.6 Reporter: Stefan Egli Assignee: Carsten Ziegeler Fix For: Commons Scheduler 2.4.8 [SchedulerServiceFactory.fireJobAt 'swallows' the date by calling scheduler.fireJob() instead of scheduler.fireJobAt()|https://github.com/apache/sling/blob/dbf5122bb38cd011a5cd88cd6540acf8a98a9e82/bundles/commons/scheduler/src/main/java/org/apache/sling/commons/scheduler/impl/SchedulerServiceFactory.java#L150] - with the effect that it fires immediately instead of delaying. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Commons Scheduler
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Closed] (SLING-4765) Add debugging info to duplicate sling.id detection in discovery.impl
[ https://issues.apache.org/jira/browse/SLING-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli closed SLING-4765. -- Add debugging info to duplicate sling.id detection in discovery.impl Key: SLING-4765 URL: https://issues.apache.org/jira/browse/SLING-4765 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.1.2 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.1.4 In case of SLING-2901 or SLING-2892 it sometimes is not exactly clear if indeed a second instance was hooked to the same repository or whether there is something else causing the detection to report a false positive. To clarify this, add more debugging infos to the log output when these two situations occur, which should include: * log runtimeId at activate time * besides runtimeId, add pid/ip/port information which can then be logged in case a duplicate situation is detected (to simply proof which other 'ghost' instance was causing the duplicate situation) * when the duplicate situation is detected, print all available information: local runtimeId/lastHeartbeat/pid/ip/port plus the same for what is stored under /var/discovery/impl/clusterInstances/slingId Basically provide enough infos to proof the ghost duplicate instance (or help detecting that the issue is locally if it is) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580521#comment-14580521 ] Dan Klco commented on SLING-4792: - This is a convenience tool for developers. When you encounter a Runtime Exception in a JSP, the stack trace will point back to the line number in the Java file created for that JSP. When the ClassLoader was repository-based, you could navigate to /var/classes to find the corresponding Java file. With the FSClassLoader putting the files in the Bundle data directory this is more cumbersome. FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4777) Decouple the model provider from the actual validation service
[ https://issues.apache.org/jira/browse/SLING-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580464#comment-14580464 ] Konrad Windszus commented on SLING-4777: [~cziegeler] Would you mind having a look at the PR. This should solve your concern raised SLING-4027. [~radu.cotescu] Are you fine with the proposed major refactoring? Decouple the model provider from the actual validation service -- Key: SLING-4777 URL: https://issues.apache.org/jira/browse/SLING-4777 Project: Sling Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Validation 1.0.0 As being mentioned in SLING-4027, it would be good to completely decouple the model providing capabilities from the actual validation, as that would a) make the codebase cleaner (and would ease testing) b) allow to plug-in other services which provide models (e.g. based on annotations on some files) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.6
+1 Cheers, Stefan On 6/10/15 2:45 PM, Stefan Egli stefane...@apache.org wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12332740 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1259/ 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 1259 /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. Cheers, Stefan
Re: [VOTE] Release Apache Sling discovery.impl 1.1.6
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Assigned] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SLING-4779:
--
Assignee: Konrad Windszus
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4755) DiscoveryService isn't shutdown aware
[
https://issues.apache.org/jira/browse/SLING-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-4755.
Resolution: Fixed
Implemented async sending of topology event in discovery.impl 1.1.6. That will
allow deactivate to continue even though an event is still being processed by a
long-running-listener
DiscoveryService isn't shutdown aware
-
Key: SLING-4755
URL: https://issues.apache.org/jira/browse/SLING-4755
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.10
Environment: AEM 6 SP2
Reporter: Ilyas Türkben
Assignee: Stefan Egli
Priority: Blocker
Fix For: Discovery Impl 1.1.6
DiscoveryServiceImpl seems to perform write operations and require repository
reference during a shutdown and it blocks the shutdown for a unpredictable
time(here, almost 26 minutes).
*Error log*
{code:java}
26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl
Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131]
ServiceEvent UNREGISTERING
26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository
Service [5185] ServiceEvent REGISTERED
26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository
Service [5185] ServiceEvent UNREGISTERING
{code}
*Thread dump for Thread-60*
{code:java}
Thread-60 daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable
[0x7f783b0ea000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
at com.mongodb.OutMessage.pipe(OutMessage.java:236)
at com.mongodb.DBPort$1.execute(DBPort.java:140)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked 0x00050a8eee30 (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
at com.mongodb.DBCursor._check(DBCursor.java:458)
at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
at
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
at
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
- locked 0x000768234398 (a
com.google.common.cache.LocalCache$StrongAccessEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
at
org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
at
Jenkins build is still unstable: sling-trunk-1.8 #1198
See https://builds.apache.org/job/sling-trunk-1.8/changes
[VOTE] Release Apache Sling discovery.impl 1.1.6
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12332740 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1259/ 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 1259 /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. Cheers, Stefan
Re: [VOTE] Release Apache Sling Installer Core 3.6.6
+1 Cheers, Stefan On 6/10/15 7:43 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved one issue (which is required for the recent updates of the provisioning model): https://issues.apache.org/jira/browse/SLING-4793 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1257/ 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 1257 /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
June Board Report
I've created a draft at https://cwiki.apache.org/confluence/display/SLING/Status+Report+June+2015 Feel free to comment/change/adjust Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Content Distribution Core version 0.1.4
Am 10.06.15 um 10:47 schrieb Marius Petria: The vote passed with three binding +1 votes and 2 non-binding votes. Can a PMC please help promoting the bundle. I've updated the dist dir. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Installer Core 3.6.6
+1 Robert On Wed, Jun 10, 2015 at 10:22 AM, Stefan Egli stefane...@apache.org wrote: +1 Cheers, Stefan On 6/10/15 7:43 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved one issue (which is required for the recent updates of the provisioning model): https://issues.apache.org/jira/browse/SLING-4793 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1257/ 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 1257 /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: [VOTE] Release Apache Sling Content Distribution Core version 0.1.4
The vote passed with three binding +1 votes and 2 non-binding votes. Can a PMC please help promoting the bundle. Thanks, Marius On 6/9/15, 3:59 PM, Carsten Ziegeler cziege...@apache.org wrote: +1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Assigned] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco reassigned SLING-4792: --- Assignee: Dan Klco FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Assignee: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 Attachments: Screen Shot 2015-06-10 at 9.46.08 AM.png With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco updated SLING-4792: Attachment: Screen Shot 2015-06-10 at 9.46.08 AM.png FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 Attachments: Screen Shot 2015-06-10 at 9.46.08 AM.png With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #162
See https://builds.apache.org/job/sling-contrib-1.7/162/
[jira] [Commented] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580537#comment-14580537 ] Dan Klco commented on SLING-4792: - Yep, I actually have it completed as a GitHub Pull Request here: https://github.com/apache/sling/pull/94 You can see from the latest screenshot (attached to this issue), that by default it displays the full file with syntax highlighting as well as links to download the class, deps and java file. BTW - is it possible to merge GitHub PR's into the Sling codebase? It seems like I can't do it, but I'm wondering if there's a way to set this up. If not I could create a patch and commit that into Subversion. FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Assignee: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 Attachments: Screen Shot 2015-06-10 at 9.46.08 AM.png With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580562#comment-14580562 ] Robert Munteanu commented on SLING-4792: It's not possible to directly merge github PRs, you need to to through SVN either by using an svn checkout or git-svn FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Assignee: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 Attachments: Screen Shot 2015-06-10 at 9.46.08 AM.png With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Installer Core 3.6.6
+1 On Wed, Jun 10, 2015 at 4:34 AM, Robert Munteanu romb...@apache.org wrote: +1 Robert On Wed, Jun 10, 2015 at 10:22 AM, Stefan Egli stefane...@apache.org wrote: +1 Cheers, Stefan On 6/10/15 7:43 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved one issue (which is required for the recent updates of the provisioning model): https://issues.apache.org/jira/browse/SLING-4793 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1257/ 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 1257 /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
Jenkins build became unstable: sling-trunk-1.7 #1912
See https://builds.apache.org/job/sling-trunk-1.7/1912/changes
[jira] [Commented] (SLING-4792) FS ClassLoader Find .java File
[ https://issues.apache.org/jira/browse/SLING-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580530#comment-14580530 ] Carsten Ziegeler commented on SLING-4792: - Ah right, yes, thanks - do you plan to display the whole file including line numbers? FS ClassLoader Find .java File -- Key: SLING-4792 URL: https://issues.apache.org/jira/browse/SLING-4792 Project: Sling Issue Type: Improvement Affects Versions: File System ClassLoader 1.0.0 Reporter: Dan Klco Labels: features Fix For: File System ClassLoader 1.0.2 With SLING-4707, finding the .java files associated with a compiled script has been made more difficult as you need to find the ID of the FSClassLoader bundle, find the data directory for this bundle on the filesystem and find the associated files. I suggest we add a OSGi console for finding the associated .java files based on a script. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Commons Scheduler
+1 On Wed, Jun 10, 2015 at 8:32 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved two issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12329585 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1258/ 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 1258 /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
Jenkins build is unstable: sling-trunk-1.8 #1197
See https://builds.apache.org/job/sling-trunk-1.8/1197/changes
i18n: RequestLocaleResolver#resolveLocale(HttpServletRequest request):ListLocale
hi all, is the type of parameter request in resolveLocale(HttpServletRequest request) a bug? Shouldn't that be SlingHttpServletRequest like it is in LocaleResolver and described in javadoc instead? Regards, O. https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/RequestLocaleResolver.java
Jenkins build is still unstable: sling-trunk-1.8 #1200
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Created] (SLING-4795) Only discard the ResourceBundles if they are really invalid
Konrad Windszus created SLING-4795:
--
Summary: Only discard the ResourceBundles if they are really
invalid
Key: SLING-4795
URL: https://issues.apache.org/jira/browse/SLING-4795
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: i18n 2.4.4
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Currently on all changes on the JCR language nodes the full cache in
{{JcrResourceBundleProvider}} becomes invalid.
Since most of the changes won't change the actual locale or basename the
invalidation could be improved so that only that {{JcrResourceBundle}} gets
invalid, which is having the same locale/basename.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580761#comment-14580761
]
Konrad Windszus commented on SLING-4779:
Applied a fixed version of the patch in rev.1684708.
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.7 #1913
See https://builds.apache.org/job/sling-trunk-1.7/1913/changes
[jira] [Commented] (SLING-4777) Decouple the model provider from the actual validation service
[ https://issues.apache.org/jira/browse/SLING-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580991#comment-14580991 ] Radu Cotescu commented on SLING-4777: - The decoupling is a good idea and I fully support it. We should try to get this PR applied and fine tune it once it's in Sling. Decouple the model provider from the actual validation service -- Key: SLING-4777 URL: https://issues.apache.org/jira/browse/SLING-4777 Project: Sling Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Validation 1.0.0 As being mentioned in SLING-4027, it would be good to completely decouple the model providing capabilities from the actual validation, as that would a) make the codebase cleaner (and would ease testing) b) allow to plug-in other services which provide models (e.g. based on annotations on some files) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
i've a problem with this new release. in rev. 1684389 you updated the dependency on org.apache.felix.configadmin from 1.2.8 to 1.8.6. the problem is that this version always writes osgi config files with arrays in multiple lines - and if such a version is deployed to a felix instance with an older version org.apache.felix.configadmin 1.8.4 or below the configuration cannot be read and is ignored. thus this slingstart plugin version only supports instances with the very latest configadmin - is this intended? stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Tuesday, June 09, 2015 2:14 PM To: Sling Developers Subject: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0 Hi, We solved some issues and added some new features in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329643 https://issues.apache.org/jira/browse/SLING/fixforversion/12332066 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1256/ 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 1256 /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
Jenkins build is still unstable: sling-contrib-1.7 #164
See https://builds.apache.org/job/sling-contrib-1.7/164/
Jenkins build is still unstable: sling-trunk-1.8 #1201
See https://builds.apache.org/job/sling-trunk-1.8/changes
Jenkins build is still unstable: sling-contrib-1.7 #163
See https://builds.apache.org/job/sling-contrib-1.7/163/
Re: i18n: RequestLocaleResolver#resolveLocale(HttpServletRequest request):ListLocale
On 10.06.2015, at 09:53, Oliver Lietz apa...@oliverlietz.de wrote: is the type of parameter request in resolveLocale(HttpServletRequest request) a bug? Shouldn't that be SlingHttpServletRequest like it is in LocaleResolver and described in javadoc instead? No, this might be called in the filter chain before sling request/response objects are available: https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java#L114-L126 Cheers, Alex
Re: [RT] New resource query API
On 09.06.2015, at 22:24, Carsten Ziegeler cziege...@apache.org wrote: If you mean whatever query language is supported by mongo or other nosql providers (and fits into a string), then that's the best you can do on the Sling layer. Thanks for confirming my point why an abstraction is necessary :) But that's my point: introducing abstraction here comes at great cost. It's much easier to set up an external search index such as Solr, pump data from different backends (behind the different resource providers) and query this one directly for a search across everything (if this is what an application needs). Cheers, Alex
Sling JCR Mocks, testing dependencies and imported ranges
Hi, I'm starting to be very much convinced that the Sling Mocks are the simplest way to add fast, repository and OSGi-enabled tests. Since they are executed out-of-container, they can live in the same module as the code under test. One conflict that I found with this approach is that while the Sling JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require recent versions of jackrabbit ( api, commons ), while we typically aim to keep the dependency versions as low as possible. One example is the recent change I added to the jcr.contentloader module [1], bumping the jackrabbit-api version from 2.2.0 to 2.10.1 (!). I have considered various approaches, but none of them looks good. 1. Declaring two dependencies with different scopes - used to work with Maven 3, no longer works with Maven 2. 2. Just live with the more strict import range - a bad idea to restrict bundles from running on older versions just because the tests need new versions. 3. Split the tests in a different module - defies the purpose of having the tests live with the code under test 4. Manually set the import-package versions in the pom.xml file - manual and error-prone Hm ... writing this email I just got the idea of the JCR mocks packaging all dependencies using the maven-shade-plugin [2] so that the actual dependencies used for testing are not the ones used at compile time and implicitly not the ones used to calculate dependencies. This means that for instance org.apache.sling.testing.sling-mock-oak will embed all of oak and the dependendent jackrabbit apis. Thoughts? Alternatives? Thanks, Robert [1]: http://svn.apache.org/viewvc?view=revisionrevision=r1684450 [2]: https://maven.apache.org/plugins/maven-shade-plugin/
[jira] [Updated] (SLING-4779) Rely on RankedServices for Sling Models
[
https://issues.apache.org/jira/browse/SLING-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4779:
---
Attachment: SLING-4779-v1.diff
Attached a first version of the patch. Unfortunately a lot of tests are failing
after applying it. I will have to investigate further...
Rely on RankedServices for Sling Models
---
Key: SLING-4779
URL: https://issues.apache.org/jira/browse/SLING-4779
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Attachments: SLING-4779-v1.diff
To prevent issues like SLING-4195 and SLING-4192 and to make the code cleaner
and leaner we should switch to the helper class {{ServiceRanking}} from
SLING-4521.
For that we must increase the dependency towards {{commons-osgi}} to version
2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.6
+1 On Wed, Jun 10, 2015 at 8:53 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
