[jira] [Resolved] (SLING-4634) Directly check if view is still current

[Carsten Ziegeler (JIRA)]

 [ 
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)

[jira] [Resolved] (SLING-5083) osgi-mock: Eliminate compile dependency to org.apache.felix.scr.annotations

[Stefan Seifert (JIRA)]

 [ 
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 (JIRA)]

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] [Created] (SLING-5084) sling-mock-oak: Provide a minimal index configuration for Sling-related properties

[Stefan Seifert (JIRA)]

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] [Created] (SLING-5085) Create a Dockerfile for the Sling Launchpad

[Robert Munteanu (JIRA)]

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

[Stefan Seifert (JIRA)]

 [ 
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] [Commented] (SLING-5085) Create a Dockerfile for the Sling Launchpad

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (SLING-4827) Embed all needed classes in the sling-mock-jackrabbit jar

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (SLING-5085) Create a Dockerfile for the Sling Launchpad

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Dockerfile for Sling

[Robert Munteanu]

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-4824) Embed all needed classes in the sling-mock-oak jar

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Re: Dockerfile for Sling

[Bertrand Delacretaz]

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-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Resolved] (SLING-5086) sling-mock: Add SlingContext.registerAdapter convenience method

[Stefan Seifert (JIRA)]

 [ 
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 (JIRA)]

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

[Robert Munteanu]

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

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Comment Edited] (SLING-1794) ConfigInstallTest fails semi-randomly: Configuration is still present

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.java:619)



--