[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=14941149#comment-14941149
]
Robert Munteanu commented on SLING-5067:
Right now I can only provide the result of
{noformat}$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 127107
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1200
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
{noformat}
I guess {{ulimit -u}} is what interests you here. As a way of debugging, maybe
you can monitor the number of threads started in the surefire process? That
would indicate if there is indeed a problem.
> 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] [Reopened] (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:all-tabpanel ] Stefan Seifert reopened SLING-5067: --- [~rombert] can you provide more info how it is possible to reproduce the issue (see above)? > 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)
Planning to release Sling IDE Tooling for Eclipse 1.0.8 next week
Hi, I plan to do a new release of the Eclipse tooling next week. This will be a bugfix / minor usability release. For references, the issues fixed are at [1], with nothing extra planned so far. If there are any issues that you think have to be included in the next release, please let me know and I'll try and fix them. Thanks, Robert [1]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING%2 0AND%20fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.0.8%22%20AND%20s tatus%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
Re: Oak, Launchpad 8, Docker
Am 02.10.15 um 11:19 schrieb Robert Munteanu: > On Fri, 2015-10-02 at 10:53 +0200, Carsten Ziegeler wrote: >> Am 30.09.15 um 23:26 schrieb Robert Munteanu: >> >>> I think the big one is >>> >>> UserAdmin and GroupAdmin groups are missing on our Oak setup >>> https://issues.apache.org/jira/browse/SLING-3144 >>> >>> There are more details in the issue but the basic idea is that Oak >>> does >>> not and will not support them. >>> >>> My suggestion is: >>> >>> - remove the metatype from the service exposing these parameters ( >>> AuthorizablePrivilegesInfoImpl ) >>> - warn if a non-default value is found set for these properties >>> - no longer take the properties into account >>> - delete the ITs which exercise this functionality >>> >> I don't really understand what the issue is. Is it correct that we >> still >> can have an implementation of AuthorizablePrivilegesInfo with Oak? >> The >> problem is more that the implementation of that one can't be >> configurable? > > Yes, the implementation will still exist, just that the items that were > configurable with Jackrabbit - UserAdmin and GroupAdmin - no longer > exist, therefore it no longer makes sense to expose them. > Ok, then I think we should follow your radical approach from above. Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-5087) The ResourceResolverImpl should provide a stack trace when CRUD operations are performed with a closed resolver
Radu Cotescu created SLING-5087:
---
Summary: The ResourceResolverImpl should provide a stack trace
when CRUD operations are performed with a closed resolver
Key: SLING-5087
URL: https://issues.apache.org/jira/browse/SLING-5087
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.6
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Resource Resolver 1.2.8
Currently trying to use a closed resource resolver for CRUD operations will
throw a {{java.lang.IllegalStateException}}. However, it would also be useful
to log where the resolver was closed, to help debugging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Oak, Launchpad 8, Docker
On Fri, 2015-10-02 at 10:53 +0200, Carsten Ziegeler wrote: > Am 30.09.15 um 23:26 schrieb Robert Munteanu: > > > I think the big one is > > > > UserAdmin and GroupAdmin groups are missing on our Oak setup > > https://issues.apache.org/jira/browse/SLING-3144 > > > > There are more details in the issue but the basic idea is that Oak > > does > > not and will not support them. > > > > My suggestion is: > > > > - remove the metatype from the service exposing these parameters ( > > AuthorizablePrivilegesInfoImpl ) > > - warn if a non-default value is found set for these properties > > - no longer take the properties into account > > - delete the ITs which exercise this functionality > > > I don't really understand what the issue is. Is it correct that we > still > can have an implementation of AuthorizablePrivilegesInfo with Oak? > The > problem is more that the implementation of that one can't be > configurable? Yes, the implementation will still exist, just that the items that were configurable with Jackrabbit - UserAdmin and GroupAdmin - no longer exist, therefore it no longer makes sense to expose them. Robert
Re: Oak, Launchpad 8, Docker
Am 30.09.15 um 23:26 schrieb Robert Munteanu: > I think the big one is > > UserAdmin and GroupAdmin groups are missing on our Oak setup > https://issues.apache.org/jira/browse/SLING-3144 > > There are more details in the issue but the basic idea is that Oak does > not and will not support them. > > My suggestion is: > > - remove the metatype from the service exposing these parameters ( > AuthorizablePrivilegesInfoImpl ) > - warn if a non-default value is found set for these properties > - no longer take the properties into account > - delete the ITs which exercise this functionality > I don't really understand what the issue is. Is it correct that we still can have an implementation of AuthorizablePrivilegesInfo with Oak? The problem is more that the implementation of that one can't be configurable? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-5080) org.apache.sling.scripting.javascript fails baseline check with maven-bundle-plugin 3.0.0
[
https://issues.apache.org/jira/browse/SLING-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941339#comment-14941339
]
Robert Munteanu commented on SLING-5080:
See also [dev@felix: Split-package warnings from embedded jars
|http://felix.markmail.org/thread/5pfl53ym7d4c7jxt]
> org.apache.sling.scripting.javascript fails baseline check with
> maven-bundle-plugin 3.0.0
> -
>
> Key: SLING-5080
> URL: https://issues.apache.org/jira/browse/SLING-5080
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.24
>Reporter: Robert Munteanu
>Assignee: Radu Cotescu
> Fix For: Scripting JavaScript 2.0.26
>
>
> After updating the maven-bundle-plugin to 3.0.0 the mentioned module fails to
> build due to a baseline check. When compared to the 2.5.3 build output, I can
> see that
> 1. it complains about multiple {{org.mozilla.javascript}} split packages,
> e..g.
> {noformat}[WARNING] Bundle
> org.apache.sling:org.apache.sling.scripting.javascript:bundle:2.0.25-SNAPSHOT
> : Split package, multiple jars provide the same
> package:org/mozilla/javascript/serialize
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:rhino, Jar:js]{noformat}
> 2. It thinks that org.mozilla.javascript should be exported with the 1.1.0
> version instead of 1.0.0, due to multiple classes being added:
> ScriptOrFnNode, PropertyException, NotAFunctionException, Node$Jump,
> FunctionNode, ClassDefinitionException .
> The first note might hold the key to understanding why the second one happens
> ; bnd might have changed the way it embeds/reexports classes and therefore
> triggers this problem
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
Stefan Seifert created SLING-5088: - Summary: sling-mock: Threads created by resource resolver/JCR are not terminated properly Key: SLING-5088 URL: https://issues.apache.org/jira/browse/SLING-5088 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.5.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Priority: Critical Fix For: Testing Sling Mock 1.6.0 as detected in SLING-5067 threads that are opened during unit test run when setting up resource resolver with JCR mapping for the mocks are not terminated properly and may lead to problems if the number of unit tests increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4442) Invalid parametrisation of Sightly statements should lead to exceptions instead of errors
[
https://issues.apache.org/jira/browse/SLING-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-4442:
Summary: Invalid parametrisation of Sightly statements should lead to
exceptions instead of errors (was: Invalid parametrization of Sightly
statements should lead to exceptions instead of errors)
> Invalid parametrisation of Sightly statements should lead to exceptions
> instead of errors
> -
>
> Key: SLING-4442
> URL: https://issues.apache.org/jira/browse/SLING-4442
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.6
>
>
> Currently invalid parametrization of Sightly statements only leads to
> errors/warnings in the log. Rather programmatic errors should lead to
> exceptions so that errors are detected earlier during development and to
> prevent invalid HTML output due to failures within a Sightly script (a HTML
> page with a 500 status is the right thing to do IMHO).
> This affects:
> # data-sly-include with invalid/empty path
> # data-sly-call with invalid name (this does not even provide logging
> currently)
> # data-sly-use when the identifier cannot be solved by any of the registered
> {{UseProvider}} services
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4971) "static" node name not allowed as a script ancestor
[
https://issues.apache.org/jira/browse/SLING-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936716#comment-14936716
]
Radu Cotescu edited comment on SLING-4971 at 10/2/15 4:06 PM:
--
Fixed in
[r1705994|https://svn.apache.org/viewvc?view=revision=r1705994].
Simplified implementation in
[r1706440|https://svn.apache.org/viewvc?view=revision=r1706440].
was (Author: radu.cotescu):
Fixed in
[r1705994|https://svn.apache.org/viewvc?view=revision=r1705994].
> "static" node name not allowed as a script ancestor
> ---
>
> Key: SLING-4971
> URL: https://issues.apache.org/jira/browse/SLING-4971
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Nicolas Peltier
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: Scripting Sightly Engine 1.0.6
>
>
> Looks like having "static" as a script ancestor (e.g.
> /apps/blah/static/foo/foo.html) will break badly the script rendering (and
> all the rendering process), yelling:
> {noformat}
> Line 1, column 0 : The declared package "" does not match the expected
> package "apps.blah.static.foo"
> Line 19, column 994 : Syntax error on token "static", Identifier expected
> at
> org.apache.sling.scripting.sightly.impl.compiler.SightlyJavaCompilerService.compileSource(SightlyJavaCompilerService.java:143)
> at
> org.apache.sling.scripting.sightly.impl.engine.UnitLoader.createUnit(UnitLoader.java:140)
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.evaluateScript(SightlyScriptEngine.java:94)
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.eval(SightlyScriptEngine.java:83)
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:361)
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:171)
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:463)
> ... 258 common frames omitted
> Caused by:
> org.apache.sling.scripting.sightly.impl.compiler.CompilerException:
> org.apache.sling.scripting.sightly.impl.compiler.CompilerException:
> Compilation errors in apps/blah/static/foo/SightlyJava_foo.java:
> Line 1, column 0 : The declared package "" does not match the expected
> package "apps.blah.static.foo"
> Line 19, column 994 : Syntax error on token "static", Identifier expected
> at
> org.apache.sling.scripting.sightly.impl.compiler.SightlyJavaCompilerService.compileJavaResource(SightlyJavaCompilerService.java:258)
> at
> org.apache.sling.scripting.sightly.impl.compiler.SightlyJavaCompilerService.compileSource(SightlyJavaCompilerService.java:141)
> ... 264 common frames omitted
> Caused by:
> org.apache.sling.scripting.sightly.impl.compiler.CompilerException:
> Compilation errors in apps/blah/static/foo/SightlyJava_foo.java:
> Line 1, column 0 : The declared package "" does not match the expected
> package "apps.blah.static.foo"
> Line 19, column 994 : Syntax error on token "static", Identifier expected
> at
> org.apache.sling.scripting.sightly.impl.compiler.SightlyJavaCompilerService.compileJavaResource(SightlyJavaCompilerService.java:250)
> ... 265 common frames omitted
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5087) The ResourceResolverImpl should provide a stack trace when CRUD operations are performed with a closed resolver
[
https://issues.apache.org/jira/browse/SLING-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-5087.
-
Resolution: Fixed
Fixed in
[r1706439|https://svn.apache.org/viewvc?view=revision=r1706439].
> The ResourceResolverImpl should provide a stack trace when CRUD operations
> are performed with a closed resolver
> ---
>
> Key: SLING-5087
> URL: https://issues.apache.org/jira/browse/SLING-5087
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Resource Resolver 1.2.8
>
>
> Currently trying to use a closed resource resolver for CRUD operations will
> throw a {{java.lang.IllegalStateException}}. However, it would also be useful
> to log where the resolver was closed, to help debugging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4442) Invalid parametrisation of Sightly statements should lead to exceptions instead of errors
[
https://issues.apache.org/jira/browse/SLING-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-4442.
-
Resolution: Fixed
Fixed in
[r1706441|https://svn.apache.org/viewvc?view=revision=r1706441].
> Invalid parametrisation of Sightly statements should lead to exceptions
> instead of errors
> -
>
> Key: SLING-4442
> URL: https://issues.apache.org/jira/browse/SLING-4442
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.6
>
>
> Currently invalid parametrization of Sightly statements only leads to
> errors/warnings in the log. Rather programmatic errors should lead to
> exceptions so that errors are detected earlier during development and to
> prevent invalid HTML output due to failures within a Sightly script (a HTML
> page with a 500 status is the right thing to do IMHO).
> This affects:
> # data-sly-include with invalid/empty path
> # data-sly-call with invalid name (this does not even provide logging
> currently)
> # data-sly-use when the identifier cannot be solved by any of the registered
> {{UseProvider}} services
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5087) The ResourceResolverImpl should provide a stack trace when CRUD operations are performed with a closed resolver
[
https://issues.apache.org/jira/browse/SLING-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941322#comment-14941322
]
Konrad Windszus commented on SLING-5087:
As creating exceptions is expensive I would prefer being able to switch it off
(for production servers).
> The ResourceResolverImpl should provide a stack trace when CRUD operations
> are performed with a closed resolver
> ---
>
> Key: SLING-5087
> URL: https://issues.apache.org/jira/browse/SLING-5087
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Resource Resolver 1.2.8
>
>
> Currently trying to use a closed resource resolver for CRUD operations will
> throw a {{java.lang.IllegalStateException}}. However, it would also be useful
> to log where the resolver was closed, to help debugging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[
https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941352#comment-14941352
]
Stefan Seifert commented on SLING-5088:
---
examples for threads that pile up after surefire run of sling-mock:
{noformat}
Thread "Apache Sling JCR Resource Event Queue Processor for path '/'":
at sun.misc.Unsafe.park(boolean, long)
at java.util.concurrent.locks.LockSupport.park(java.lang.Object)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()
at java.util.concurrent.LinkedBlockingQueue.take()
at
org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue()
at org.apache.sling.jcr.resource.internal.JcrResourceListener$1.run()
at java.lang.Thread.run()
{noformat}
{noformat}
Thread "MapEntries Update":
at sun.misc.Unsafe.park(boolean, long)
at java.util.concurrent.locks.LockSupport.park(java.lang.Object)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(int)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(int)
at java.util.concurrent.Semaphore.acquire()
at org.apache.sling.resourceresolver.impl.mapping.MapEntries.init()
at
org.apache.sling.resourceresolver.impl.mapping.MapEntries.access$000(org.apache.sling.resourceresolver.impl.mapping.MapEntries)
at org.apache.sling.resourceresolver.impl.mapping.MapEntries$1.run()
at java.lang.Thread.run()
{noformat}
{noformat}
Thread "pool-12-thread-1":
at sun.misc.Unsafe.park(boolean, long)
at java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long)
at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.util.concurrent.SynchronousQueue$TransferStack$SNode,
boolean, long)
at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.lang.Object,
boolean, long)
at java.util.concurrent.SynchronousQueue.poll(long,
java.util.concurrent.TimeUnit)
at java.util.concurrent.ThreadPoolExecutor.getTask()
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
at java.util.concurrent.ThreadPoolExecutor$Worker.run()
at java.lang.Thread.run()
{noformat}
> sling-mock: Threads created by resource resolver/JCR are not terminated
> properly
>
>
> Key: SLING-5088
> URL: https://issues.apache.org/jira/browse/SLING-5088
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing Sling Mock 1.5.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
> Labels: mocks
> Fix For: Testing Sling Mock 1.6.0
>
>
> as detected in SLING-5067 threads that are opened during unit test run when
> setting up resource resolver with JCR mapping for the mocks are not
> terminated properly and may lead to problems if the number of unit tests
> increases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[ https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941400#comment-14941400 ] Stefan Seifert commented on SLING-5088: --- Completed: At revision: 1706448 updated sling-mock to latest osgi-mock version for SLING-5089. does not solve the problem yet, further work is needed. > sling-mock: Threads created by resource resolver/JCR are not terminated > properly > > > Key: SLING-5088 > URL: https://issues.apache.org/jira/browse/SLING-5088 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Critical > Labels: mocks > Fix For: Testing Sling Mock 1.6.0 > > > as detected in SLING-5067 threads that are opened during unit test run when > setting up resource resolver with JCR mapping for the mocks are not > terminated properly and may lead to problems if the number of unit tests > increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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:all-tabpanel ] Stefan Seifert resolved SLING-5067. --- Resolution: Fixed i can confirm we have a problem here with threads not terminated, even in sling-mock alone without oak. i've created SLING-5088 to track it - i'm quite sure it's not related to this issue, perhaps the issue was only that the number of unit tests increased. setting this feature ticket to fixed again. > 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] [Created] (SLING-5089) mock-osgi: Deactivate all services on shutdown
Stefan Seifert created SLING-5089: - Summary: mock-osgi: Deactivate all services on shutdown Key: SLING-5089 URL: https://issues.apache.org/jira/browse/SLING-5089 Project: Sling Issue Type: New Feature Components: Testing Affects Versions: Testing OSGi Mock 1.5.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing OSGi Mock 1.5.2 currently not deactivate method is called on registered osgi services if it is not done explicitly in the unit test code. this may cause problems if the services has opened resources (e.g. files, threads) that needs to be cleaned up in the deactivate method. we should deactivate all registered services when each unit test run is complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5089) mock-osgi: Deactivate all services on shutdown
[ https://issues.apache.org/jira/browse/SLING-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5089. --- Resolution: Fixed Completed: At revision: 1706447 > mock-osgi: Deactivate all services on shutdown > -- > > Key: SLING-5089 > URL: https://issues.apache.org/jira/browse/SLING-5089 > Project: Sling > Issue Type: New Feature > Components: Testing >Affects Versions: Testing OSGi Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: mocks > Fix For: Testing OSGi Mock 1.5.2 > > > currently not deactivate method is called on registered osgi services if it > is not done explicitly in the unit test code. > this may cause problems if the services has opened resources (e.g. files, > threads) that needs to be cleaned up in the deactivate method. > we should deactivate all registered services when each unit test run is > complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5090) osgi-mock: Support ServiceFactory
Stefan Seifert created SLING-5090: - Summary: osgi-mock: Support ServiceFactory Key: SLING-5090 URL: https://issues.apache.org/jira/browse/SLING-5090 Project: Sling Issue Type: New Feature Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing OSGi Mock 1.6.0 we need a minimal support for the ServiceFactory concept in OSGi mocks. if a service is registered as ServiceFactory the service instance has to be get via the factory. we do not bother about real bundle scoping because we do not handle different bundles in osgi mock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5090) osgi-mock: Support ServiceFactory
[ https://issues.apache.org/jira/browse/SLING-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5090. --- Resolution: Fixed Completed: At revision: 1706494 > osgi-mock: Support ServiceFactory > - > > Key: SLING-5090 > URL: https://issues.apache.org/jira/browse/SLING-5090 > Project: Sling > Issue Type: New Feature > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: mocks > Fix For: Testing OSGi Mock 1.6.0 > > > we need a minimal support for the ServiceFactory concept in OSGi mocks. > if a service is registered as ServiceFactory the service instance has to be > get via the factory. > we do not bother about real bundle scoping because we do not handle different > bundles in osgi mock. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[ https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-5088. --- Resolution: Fixed rev. 1706500 should be fixed for sling-mock. no threads kept open exception some JDK-internal ThreadPoolExecutor pool items. the code for setting up ResourceResolverFactoryActivator is much cleaner now and more correct than before. will have to look separately at sling-mock-oak. > sling-mock: Threads created by resource resolver/JCR are not terminated > properly > > > Key: SLING-5088 > URL: https://issues.apache.org/jira/browse/SLING-5088 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Critical > Labels: mocks > Fix For: Testing Sling Mock 1.6.0 > > > as detected in SLING-5067 threads that are opened during unit test run when > setting up resource resolver with JCR mapping for the mocks are not > terminated properly and may lead to problems if the number of unit tests > increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[ https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-5088: -- Affects Version/s: Testing Sling Mock Jackrabbit 0.1.2 Fix Version/s: Testing OSGi Mock 1.6.0 Testing Sling Mock Oak 1.0.0 Testing Sling Mock Jackrabbit 1.0.0 > sling-mock: Threads created by resource resolver/JCR are not terminated > properly > > > Key: SLING-5088 > URL: https://issues.apache.org/jira/browse/SLING-5088 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock Jackrabbit 0.1.2, Testing Sling Mock > 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Critical > Labels: mocks > Fix For: Testing Sling Mock Jackrabbit 1.0.0, Testing Sling Mock > Oak 1.0.0, Testing OSGi Mock 1.6.0, Testing Sling Mock 1.6.0 > > > as detected in SLING-5067 threads that are opened during unit test run when > setting up resource resolver with JCR mapping for the mocks are not > terminated properly and may lead to problems if the number of unit tests > increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[ https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941973#comment-14941973 ] Stefan Seifert commented on SLING-5088: --- rev. 1706506 there where misc. executor services left in oak and osgi-mock that were not closed properly. fixed no. thead list in sling-mock is not completely clean after all unit tests completed. marked some methods in MockSling and MockOsgi as deprecated which usage may lead to memory leaks because bundle context cannot be shut down properly. > sling-mock: Threads created by resource resolver/JCR are not terminated > properly > > > Key: SLING-5088 > URL: https://issues.apache.org/jira/browse/SLING-5088 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock Jackrabbit 0.1.2, Testing Sling Mock > 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Critical > Labels: mocks > Fix For: Testing Sling Mock Jackrabbit 1.0.0, Testing Sling Mock > Oak 1.0.0, Testing OSGi Mock 1.6.0, Testing Sling Mock 1.6.0 > > > as detected in SLING-5067 threads that are opened during unit test run when > setting up resource resolver with JCR mapping for the mocks are not > terminated properly and may lead to problems if the number of unit tests > increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5088) sling-mock: Threads created by resource resolver/JCR are not terminated properly
[ https://issues.apache.org/jira/browse/SLING-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942024#comment-14942024 ] Stefan Seifert commented on SLING-5088: --- [~rombert]: if you find the time please validate that the memory leak problem on your machine is solved as well. i want to make new releases early next week, because this is a rather serious issue, and because of the new features and 1.0.0 releases of sling-mock-oak and sling-mock-jackrabbit with automatic node type registration. > sling-mock: Threads created by resource resolver/JCR are not terminated > properly > > > Key: SLING-5088 > URL: https://issues.apache.org/jira/browse/SLING-5088 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock Jackrabbit 0.1.2, Testing Sling Mock > 1.5.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Critical > Labels: mocks > Fix For: Testing Sling Mock Jackrabbit 1.0.0, Testing Sling Mock > Oak 1.0.0, Testing OSGi Mock 1.6.0, Testing Sling Mock 1.6.0 > > > as detected in SLING-5067 threads that are opened during unit test run when > setting up resource resolver with JCR mapping for the mocks are not > terminated properly and may lead to problems if the number of unit tests > increases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SLING-5087) The ResourceResolverImpl should provide a stack trace when CRUD operations are performed with a closed resolver
[
https://issues.apache.org/jira/browse/SLING-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reopened SLING-5087:
-
I agree with Konrad, and I think the exception variable should be volatile
(just to be on the safe side)
> The ResourceResolverImpl should provide a stack trace when CRUD operations
> are performed with a closed resolver
> ---
>
> Key: SLING-5087
> URL: https://issues.apache.org/jira/browse/SLING-5087
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Resource Resolver 1.2.8
>
>
> Currently trying to use a closed resource resolver for CRUD operations will
> throw a {{java.lang.IllegalStateException}}. However, it would also be useful
> to log where the resolver was closed, to help debugging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
