[jira] [Comment Edited] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present
[ https://issues.apache.org/jira/browse/SLING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940571#comment-14940571 ] Bertrand Delacretaz edited comment on SLING-1794 at 10/1/15 10:57 PM: -- This has appeared again today at https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.installer.it/2388/testReport/junit/org.apache.sling.installer.it/ConfigInstallTest/testDeferredConfigRemove/ {code} java.lang.AssertionError: Config must be removed once ConfigurationAdmin restarts: config is still present (ConfigInstallTest.deferred.1_1443734921741) at org.junit.Assert.fail(Assert.java:88) at org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:361) at org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:311) at org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigRemove(ConfigInstallTest.java:529) {code} was (Author: bdelacretaz): This has appeared again today at https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.installer.it/2388/testReport/junit/org.apache.sling.installer.it/ConfigInstallTest/testDeferredConfigRemove/ > ConfigInstallTest fails semi-randomly: Configuration is still present > - > > Key: SLING-1794 > URL: https://issues.apache.org/jira/browse/SLING-1794 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Andreas Kuckartz >Assignee: Carsten Ziegeler > Labels: it,intermittent, sling-IT > Attachments: stdio.txt > > > --- > Test set: org.apache.sling.installer.it.ConfigInstallTest > --- > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec > <<< FAILURE! > testDeferredConfigInstall > [felix](org.apache.sling.installer.it.ConfigInstallTest) Time elapsed: > 10.072 sec <<< FAILURE! > java.lang.AssertionError: Config must be removed once ConfigurationAdmin > restarts: Configuration is still present > (ConfigInstallTest.deferred.1285097628299) > at org.junit.Assert.fail(Assert.java:74) > at > org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246) > at > org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143) > at > org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) > at sun.rmi.transport.Transport$1.run(Transport.java:159) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.ja
[jira] [Commented] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present
[ https://issues.apache.org/jira/browse/SLING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940571#comment-14940571 ] Bertrand Delacretaz commented on SLING-1794: This has appeared again today at https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.installer.it/2388/testReport/junit/org.apache.sling.installer.it/ConfigInstallTest/testDeferredConfigRemove/ > ConfigInstallTest fails semi-randomly: Configuration is still present > - > > Key: SLING-1794 > URL: https://issues.apache.org/jira/browse/SLING-1794 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Andreas Kuckartz >Assignee: Carsten Ziegeler > Labels: it,intermittent, sling-IT > Attachments: stdio.txt > > > --- > Test set: org.apache.sling.installer.it.ConfigInstallTest > --- > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.044 sec > <<< FAILURE! > testDeferredConfigInstall > [felix](org.apache.sling.installer.it.ConfigInstallTest) Time elapsed: > 10.072 sec <<< FAILURE! > java.lang.AssertionError: Config must be removed once ConfigurationAdmin > restarts: Configuration is still present > (ConfigInstallTest.deferred.1285097628299) > at org.junit.Assert.fail(Assert.java:74) > at > org.apache.sling.installer.it.OsgiInstallerTestBase.waitForConfiguration(OsgiInstallerTestBase.java:246) > at > org.apache.sling.installer.it.ConfigInstallTest.testDeferredConfigInstall(ConfigInstallTest.java:149) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143) > at > org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) > at sun.rmi.transport.Transport$1.run(Transport.java:159) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5067) sling-mock: "uniqueRoot()" to simplify creation and cleanup of unique root paths in repository
[ https://issues.apache.org/jira/browse/SLING-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940516#comment-14940516 ] Stefan Seifert commented on SLING-5067: --- ah, ok? as suspected does not fail on "my machine". what special process limit have you configured on your machine that produces this problem? i wonder why esp. this commit should be the source of new troubles. the tests of which project exactly fail on your machine? sling-mock or sling-mock-oak? currently we do nothing more than closing the resource resolvers after a unit test is done. the underlying oak repo is currently not closed explicitly (how is this possible? i've not found a method for this on a first quick look.) > sling-mock: "uniqueRoot()" to simplify creation and cleanup of unique root > paths in repository > -- > > Key: SLING-5067 > URL: https://issues.apache.org/jira/browse/SLING-5067 > Project: Sling > Issue Type: New Feature > Components: Testing >Affects Versions: Testing Sling Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: mocks > Fix For: Testing Sling Mock Jackrabbit 1.0.0, Testing Sling Mock > Oak 1.0.0, Testing Sling Mock 1.6.0 > > > when using resource resolver types JCR_JACKRABBIT and JCR_OAK unique root > paths have to be used because the repository is not cleaned up after each > run, and esp. if unit tests run in parallel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5086) sling-mock: Add SlingContext.registerAdapter convenience method
[ https://issues.apache.org/jira/browse/SLING-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5086. --- Resolution: Fixed Completed: At revision: 1706325 > sling-mock: Add SlingContext.registerAdapter convenience method > --- > > Key: SLING-5086 > URL: https://issues.apache.org/jira/browse/SLING-5086 > Project: Sling > Issue Type: New Feature > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: mocks > Fix For: Testing Sling Mock 1.6.0 > > > scenario: adapt from an object in your unit test where no existing > adapterfactory is available. currently you have to create a AdapterFactory > instance and register it with proper OSGi properties in OSGi. > two convenience methods simplify this by allowing to trim it down to one > codeline: > {code:java} > /** > * Create a Sling AdapterFactory on the fly which can adapt from > adaptableClass > * to adapterClass and just returns the given value as > result. > * @param adaptableClass Class to adapt from > * @param adapterClass Class to adapt to > * @param adapter Object which is always returned for this adaption. > */ > public void registerAdapter(final Class adaptableClass, > final Class adapterClass, final T2 adapter) { > ... > {code} > {code:java} > /** > * Create a Sling AdapterFactory on the fly which can adapt from > adaptableClass > * to adapterClass and delegates the adapter mapping to the > given adaptHandler function. > * @param adaptableClass Class to adapt from > * @param adapterClass Class to adapt to > * @param adaptHandler Function to handle the adaption > */ > public void registerAdapter(final Class adaptableClass, > final Class adapterClass, final Function adaptHandler) { > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5086) sling-mock: Add SlingContext.registerAdapter convenience method
Stefan Seifert created SLING-5086: - Summary: sling-mock: Add SlingContext.registerAdapter convenience method Key: SLING-5086 URL: https://issues.apache.org/jira/browse/SLING-5086 Project: Sling Issue Type: New Feature Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock 1.6.0 scenario: adapt from an object in your unit test where no existing adapterfactory is available. currently you have to create a AdapterFactory instance and register it with proper OSGi properties in OSGi. two convenience methods simplify this by allowing to trim it down to one codeline: {code:java} /** * Create a Sling AdapterFactory on the fly which can adapt from adaptableClass * to adapterClass and just returns the given value as result. * @param adaptableClass Class to adapt from * @param adapterClass Class to adapt to * @param adapter Object which is always returned for this adaption. */ public void registerAdapter(final Class adaptableClass, final Class adapterClass, final T2 adapter) { ... {code} {code:java} /** * Create a Sling AdapterFactory on the fly which can adapt from adaptableClass * to adapterClass and delegates the adapter mapping to the given adaptHandler function. * @param adaptableClass Class to adapt from * @param adapterClass Class to adapt to * @param adaptHandler Function to handle the adaption */ public void registerAdapter(final Class adaptableClass, final Class adapterClass, final Function adaptHandler) { ... {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Dockerfile for Sling
On Thu, 2015-10-01 at 23:18 +0200, Bertrand Delacretaz wrote: > Hi, > > On Thu, Oct 1, 2015 at 9:36 PM, Robert Munteanu > wrote: > > ...http://svn.apache.org/repos/asf/sling/trunk/launchpad/docker/ .. > > . > > FWIW the Dockerfile from my docker-sling-cluster prototype from last > year also installs Maven and builds Sling locally, such a technique > allows for running the Sling trunk by just specifying which svn > version or tag you want. It also starts Sling at image build time, to > make startup of the final image faster. > > It's at [1] and can be simplified today, by using a java:8 base image > as yours does. We might need different flavors of those images, I'm > not saying you should change yours. Ah, interesting approach. What is not clear to me is how this would work for distribution. If we build the docker image with the Sling home already populated then we 'decide' the runmode, context path, etc in advance. It starts up faster, indeed, but it's less flexible. It might be worth creating different flavour though ( oak-tar, oak -mongo, etc ). Robert
[jira] [Commented] (SLING-5067) sling-mock: "uniqueRoot()" to simplify creation and cleanup of unique root paths in repository
[ https://issues.apache.org/jira/browse/SLING-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940459#comment-14940459 ] Robert Munteanu commented on SLING-5067: [~sseif...@pro-vision.de] - the mock tests have recently started to fail for me, e.g. with {noformat}Exception in thread "oak-scheduled-executor-3" java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:714) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950) at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1018) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745){noformat} I don't expect to fail for someone else, my laptop intentionally has a low process limit to catch these kinds of things :-) git bisect indicates that this is the bad commit {noformat}3ead30640692c1d387703e1f5c966c01f47d911b is the first bad commit commit 3ead30640692c1d387703e1f5c966c01f47d911b Author: Stefan Seifert Date: Sun Sep 27 09:46:11 2015 + SLING-5067 sling-mock: "uniqueRoot()" to simplify creation and cleanup of unique root paths in repository git-svn-id: https://svn.apache.org/repos/asf/sling/trunk@1705520 13f79535-47bb-0310-9956-ffa450edef68 :04 04 c685db6473c73ba8a09682e691c69ec7a82d4fd8 53f1cf2e6a2c51b6b387cad3deb24008d8b1f9f1 M testing{noformat} Can you take a look and see whether there are some leaks? I would expect that an unclosed Oak repository causes this issue, as it internally starts some threads which are only cleaned up at shutdown. If the repository is not shutdown then those threads will stay alive, exhausting all available processes for my user -> OutOfMemoryError > sling-mock: "uniqueRoot()" to simplify creation and cleanup of unique root > paths in repository > -- > > Key: SLING-5067 > URL: https://issues.apache.org/jira/browse/SLING-5067 > Project: Sling > Issue Type: New Feature > Components: Testing >Affects Versions: Testing Sling Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: mocks > Fix For: Testing Sling Mock Jackrabbit 1.0.0, Testing Sling Mock > Oak 1.0.0, Testing Sling Mock 1.6.0 > > > when using resource resolver types JCR_JACKRABBIT and JCR_OAK unique root > paths have to be used because the repository is not cleaned up after each > run, and esp. if unit tests run in parallel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Dockerfile for Sling
Hi, On Thu, Oct 1, 2015 at 9:36 PM, Robert Munteanu wrote: > ...http://svn.apache.org/repos/asf/sling/trunk/launchpad/docker/ ... FWIW the Dockerfile from my docker-sling-cluster prototype from last year also installs Maven and builds Sling locally, such a technique allows for running the Sling trunk by just specifying which svn version or tag you want. It also starts Sling at image build time, to make startup of the final image faster. It's at [1] and can be simplified today, by using a java:8 base image as yours does. We might need different flavors of those images, I'm not saying you should change yours. -Bertrand [1] https://github.com/bdelacretaz/docker-sling-cluster/blob/master/docker/sling/Dockerfile
[jira] [Commented] (SLING-4824) Embed all needed classes in the sling-mock-oak jar
[ https://issues.apache.org/jira/browse/SLING-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940373#comment-14940373 ] Stefan Seifert commented on SLING-4824: --- Completed: At revision: 1706320 i've removed the embedding of dependency {{org.apache.sling.jcr.resource}} - this is a transitive dependency of sling-mock and not a dependency of sling-mock-oak, so it should not be embedded here. otherwise we have it twice - once as dependency of sling-mock and once embedded in this jar. > Embed all needed classes in the sling-mock-oak jar > -- > > Key: SLING-4824 > URL: https://issues.apache.org/jira/browse/SLING-4824 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: Testing Sling Mock Oak 1.0.0 > > > When using the JCR_OAK resource resolve type recent versions of the > Jackrabbit/Oak are pulled in as transitive dependencies. This causes the > maven-bundle-plugin to generate Import-Version ranges based on the > dependencies of those artifacts required for the test code, as opposed to the > the dependencies required by production code. > Embedding the relevant dependencies in the sling-oak-mock jar should be > enough to remove this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4827) Embed all needed classes in the sling-mock-jackrabbit jar
[ https://issues.apache.org/jira/browse/SLING-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940374#comment-14940374 ] Stefan Seifert commented on SLING-4827: --- Completed: At revision: 1706320 i've removed the embedding of dependency {{org.apache.sling.jcr.resource}} - this is a transitive dependency of sling-mock and not a dependency of sling-mock-jackrabbit, so it should not be embedded here. otherwise we have it twice - once as dependency of sling-mock and once embedded in this jar. > Embed all needed classes in the sling-mock-jackrabbit jar > - > > Key: SLING-4827 > URL: https://issues.apache.org/jira/browse/SLING-4827 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock Jackrabbit 0.1.2 >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: Testing Sling Mock Jackrabbit 1.0.0 > > > When using the JCR_JACKRABBIT resource resolver type recent versions of the > Jackrabbit are pulled in as transitive dependencies. This causes the > maven-bundle-plugin to generate Import-Version ranges based on the > dependencies of those artifacts required for the test code, as opposed to the > the dependencies required by production code. > Embedding the relevant dependencies in the sling-oak-mock jar should be > enough to remove this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Dockerfile for Sling
Hi, I added an initial version of a Dockerfile for the Sling Launchpad - you can find it under http://svn.apache.org/repos/asf/sling/trunk/launchpad/docker/ . In my limited tests it works as expected, but since I'm not a Docker expert I probably missed some things. It would be great if anyone with more knowledge would take a look. I plan to use it to build an 'official' docker image for the Launchpad 8 release which would be pushed on Docker Hub. Thanks, Robert
[jira] [Commented] (SLING-5085) Create a Dockerfile for the Sling Launchpad
[ https://issues.apache.org/jira/browse/SLING-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940277#comment-14940277 ] Robert Munteanu commented on SLING-5085: And subsequent fix in https://svn.apache.org/r1706309 > Create a Dockerfile for the Sling Launchpad > --- > > Key: SLING-5085 > URL: https://issues.apache.org/jira/browse/SLING-5085 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5085) Create a Dockerfile for the Sling Launchpad
[ https://issues.apache.org/jira/browse/SLING-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940274#comment-14940274 ] Robert Munteanu commented on SLING-5085: Initial version added in https://svn.apache.org/r1706308 > Create a Dockerfile for the Sling Launchpad > --- > > Key: SLING-5085 > URL: https://issues.apache.org/jira/browse/SLING-5085 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5085) Create a Dockerfile for the Sling Launchpad
Robert Munteanu created SLING-5085: -- Summary: Create a Dockerfile for the Sling Launchpad Key: SLING-5085 URL: https://issues.apache.org/jira/browse/SLING-5085 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Robert Munteanu Assignee: Robert Munteanu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5084) sling-mock-oak: Provide a minimal index configuration for Sling-related properties
[ https://issues.apache.org/jira/browse/SLING-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5084. --- Resolution: Fixed Completed: At revision: 1706299 i applied a subset of indexes as defined in {{org.apache.sling.jcr.oak.server}} bundle. once {{org.apache.sling.jcr.oak.server}} is released we could think about using this for initializing the repository instead of using {{org.apache.jackrabbit.oak.jcr.Jcr}} with those extra indexes to be more close to real oak-jcr setup used by oak-server. > sling-mock-oak: Provide a minimal index configuration for Sling-related > properties > -- > > Key: SLING-5084 > URL: https://issues.apache.org/jira/browse/SLING-5084 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Labels: mocks > Fix For: Testing Sling Mock Oak 1.0.0 > > > by default, no sling-specific indexes are defined in the JCR_OAK resource > resolver type for sling mocks. this leads to warnings on every usage (when > the resource-jcr mapping is initialized) like: > {noformat} > WARN org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor - Traversed > 1000 nodes with filter Filter(query=SELECT sling:alias FROM nt:base WHERE > sling:alias IS NOT NULL, path=*, property=[sling:alias=[is not null]]); > consider creating an index or changing the query > {noformat} > we should provide a minimal index configuration for the default sling > attribute to avoid these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5084) sling-mock-oak: Provide a minimal index configuration for Sling-related properties
Stefan Seifert created SLING-5084: - Summary: sling-mock-oak: Provide a minimal index configuration for Sling-related properties Key: SLING-5084 URL: https://issues.apache.org/jira/browse/SLING-5084 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Priority: Minor Fix For: Testing Sling Mock Oak 1.0.0 by default, no sling-specific indexes are defined in the JCR_OAK resource resolver type for sling mocks. this leads to warnings on every usage (when the resource-jcr mapping is initialized) like: {noformat} WARN org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor - Traversed 1000 nodes with filter Filter(query=SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL, path=*, property=[sling:alias=[is not null]]); consider creating an index or changing the query {noformat} we should provide a minimal index configuration for the default sling attribute to avoid these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5083) osgi-mock: Eliminate compile dependency to org.apache.felix.scr.annotations
[ https://issues.apache.org/jira/browse/SLING-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5083. --- Resolution: Fixed Completed: At revision: 1706287 > osgi-mock: Eliminate compile dependency to org.apache.felix.scr.annotations > --- > > Key: SLING-5083 > URL: https://issues.apache.org/jira/browse/SLING-5083 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing OSGi Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Trivial > Labels: mocks > Fix For: Testing OSGi Mock 1.5.2 > > > osgi-mock 1.5.0 depends on {{org.apache.felix.scr.annotations}} with a > compile time dependency. this is not required and pollutes the transient > dependencies for other bundles. and a provided dependency to it is already > inherited from the parent pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5083) osgi-mock: Eliminate compile dependency to org.apache.felix.scr.annotations
Stefan Seifert created SLING-5083: - Summary: osgi-mock: Eliminate compile dependency to org.apache.felix.scr.annotations Key: SLING-5083 URL: https://issues.apache.org/jira/browse/SLING-5083 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing OSGi Mock 1.5.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Priority: Trivial Fix For: Testing OSGi Mock 1.5.2 osgi-mock 1.5.0 depends on {{org.apache.felix.scr.annotations}} with a compile time dependency. this is not required and pollutes the transient dependencies for other bundles. and a provided dependency to it is already inherited from the parent pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4634) Directly check if view is still current
[ https://issues.apache.org/jira/browse/SLING-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4634. - Resolution: Fixed Minor change in rev 1706229, setting this to fixed for now > Directly check if view is still current > --- > > Key: SLING-4634 > URL: https://issues.apache.org/jira/browse/SLING-4634 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Event 3.6.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Event 3.7.6 > > > Currently, the job handler continues until it receives a topology event > (changing/changed/init). However , the current view object can directly be > checked whether it's current -- This message was sent by Atlassian JIRA (v6.3.4#6332)