[jira] [Created] (SLING-4944) JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it
Konrad Windszus created SLING-4944: -- Summary: JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it Key: SLING-4944 URL: https://issues.apache.org/jira/browse/SLING-4944 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.2 Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: i18n 2.4.4 After fixing SLING-4910 there is still a very slim chance that the resource resolver is being null while being used within the scheduleReloadBundles, because that is called, before the resolver is initialized. The chance to see that in reality is close to zero though, because scheduleReloadBundles is using the resource resolver only in a scheduled thread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4811) Handle OSGi event in a separate thread to prevent being blacklisted by the OSGi Event Admin
[
https://issues.apache.org/jira/browse/SLING-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4811.
---
Handle OSGi event in a separate thread to prevent being blacklisted by the
OSGi Event Admin
---
Key: SLING-4811
URL: https://issues.apache.org/jira/browse/SLING-4811
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.4.2
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: i18n 2.4.4
Attachments: SLING-4811-v02.patch
Since Apache Felix blacklists all OSGi Event Handlers which take too long to
complete it would be good if all long-running tasks would be executed in a
separate thread (like preloading resource bundles).
Otherwise the {{JcrResourceBundleProvider}} might get blacklisted if the
instance is under load and in the future is not notified about any changes.
The default timeout of Apache Felix is 5 seconds
(http://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4859) embed org.apache.jackrabbit.commons.json.Json* classes
[ https://issues.apache.org/jira/browse/SLING-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4859. --- embed org.apache.jackrabbit.commons.json.Json* classes -- Key: SLING-4859 URL: https://issues.apache.org/jira/browse/SLING-4859 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: i18n 2.4.2 Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: i18n 2.4.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4858) fix Javadoc in RequestLocaleResolver
[ https://issues.apache.org/jira/browse/SLING-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4858. --- fix Javadoc in RequestLocaleResolver Key: SLING-4858 URL: https://issues.apache.org/jira/browse/SLING-4858 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.2 Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: i18n 2.4.4 dev@: [i18n: RequestLocaleResolver#resolveLocale(HttpServletRequest request):ListLocale|http://mail-archives.us.apache.org/mod_mbox/sling-dev/201506.mbox/%3c1578459.EWsyv128nl@madness%3e] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4814) i18n translations not working unless server is restarted
[ https://issues.apache.org/jira/browse/SLING-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4814. --- i18n translations not working unless server is restarted Key: SLING-4814 URL: https://issues.apache.org/jira/browse/SLING-4814 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.2 Reporter: Nitin Goyal Assignee: Konrad Windszus Fix For: i18n 2.4.4 Attachments: SLING-4814-v01.patch We have deployed an AEM package where the i18n translations are defined in the standard way under /apps/myapp/i18n as sling:key/sling:value pairs. After installing the package on AEM 6.1 we found that none of the strings (not even the English ones) get translated properly. Once we restart the AEM server all translations works fine. It works fine in AEM 6.0 without requiring any server restart. I tried to capture the logs after setting the org.apache.sling.i18n to DEBUG level. When I install the app bundle I see the following entry in the log file: 17.06.2015 11:54:14.438 INFO [0:0:0:0:0:0:0:1 [1434522253131] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n.impl.JcrResourceBundleProvider Currently loaded dictionaries across all locales: [/libs/foundation/components/mobilefooter/i18n/en, /libs/cq/searchpromote/components/pagination/i18n/en, /libs/foundation/components/search/i18n/en, /libs/commerce/components/search/i18n/en] It does not list the dictionary of my app bundle. There is no other log related to loading dictionaries. However when I restart the server after installing my package I see the entry in the log file related to loading the dictionaries corresponding to my application bundle /apps/connect/i18n/en/strings. Pasting the log entries below: 17.06.2015 11:14:38.232 INFO [0:0:0:0:0:0:0:1 [1434519877679] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n Service [3279, [java.util.ResourceBundle]] ServiceEvent REGISTERED 17.06.2015 11:14:38.234 DEBUG [0:0:0:0:0:0:0:1 [1434519877679] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n.impl.JcrResourceBundleProvider registerResourceBundle(Key(null, en), ...): added service registration and language roots [/libs/foundation/components/mobilefooter/i18n/en, /libs/cq/searchpromote/components/pagination/i18n/en, /libs/foundation/components/search/i18n/en, /libs/commerce/components/search/i18n/en, /apps/connect/i18n/en/strings] 17.06.2015 11:14:38.234 INFO [0:0:0:0:0:0:0:1 [1434519877679] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n.impl.JcrResourceBundleProvider Currently loaded dictionaries across all locales: [/libs/foundation/components/mobilefooter/i18n/en, /libs/cq/searchpromote/components/pagination/i18n/en, /apps/connect/i18n/en/strings, /libs/foundation/components/search/i18n/en, /libs/commerce/components/search/i18n/en] 17.06.2015 11:14:38.267 DEBUG [0:0:0:0:0:0:0:1 [1434519877679] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n.impl.JcrResourceBundleProvider getResourceBundleInternal(Key(null, en)): got cache hit on first try -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4812) Incorrect event handling for initially empty dictionary
[
https://issues.apache.org/jira/browse/SLING-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4812.
---
Incorrect event handling for initially empty dictionary
---
Key: SLING-4812
URL: https://issues.apache.org/jira/browse/SLING-4812
Project: Sling
Issue Type: Bug
Affects Versions: i18n 2.4.2
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: i18n 2.4.4
Currently the Event Handler of the {{JcrResourceBundleProvider}} only
invalidates the caches if there was some modification on or below one of the
{{languageRootPaths}}
(https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L180).
Since empty dictionaries (without any messages) are not added to the
{{languageRootPaths}}
(https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L199)
the following use case is not supported
# create a new empty dictionary without any entries
# create an entry below the empty dictionary
If between step 1 and 2 the i18n bundle is not reloaded the newly created
entry is not detected and therefore not part of any JcrResourceBundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE RESULT] Release Apache Sling i18n 2.4.4
The vote passes with three binding +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4862) Sling Health Checks Servlet
[ https://issues.apache.org/jira/browse/SLING-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694856#comment-14694856 ] Bertrand Delacretaz commented on SLING-4862: Thanks, I have included your improved help texts in revision 1695656 Sling Health Checks Servlet --- Key: SLING-4862 URL: https://issues.apache.org/jira/browse/SLING-4862 Project: Sling Issue Type: Improvement Components: Health Check Reporter: Bertrand Delacretaz Priority: Minor Fix For: Health Check Core 1.2.4 Attachments: SLING-4862-HealthCheckExecutorServlet-v2.patch, SLING-4862-HealthCheckExecutorServlet.patch A Servlet that can execute health checks would be useful. It can take as input the tags of the HCs to execute, and output their results in JSON format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4944) JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it
[ https://issues.apache.org/jira/browse/SLING-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-4944. Resolution: Fixed JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it - Key: SLING-4944 URL: https://issues.apache.org/jira/browse/SLING-4944 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.2 Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: i18n 2.4.4 After fixing SLING-4910 there is still a very slim chance that the resource resolver is being null while being used within the scheduleReloadBundles, because that is called, before the resolver is initialized. The chance to see that in reality is close to zero though, because scheduleReloadBundles is using the resource resolver only in a scheduled thread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4795) Only discard the ResourceBundles if they are really invalid
[
https://issues.apache.org/jira/browse/SLING-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4795.
---
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
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: i18n 2.4.4
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] [Closed] (SLING-4910) NPE in JCrResourceBundleProvider
[
https://issues.apache.org/jira/browse/SLING-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4910.
---
NPE in JCrResourceBundleProvider
Key: SLING-4910
URL: https://issues.apache.org/jira/browse/SLING-4910
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.4.4
Reporter: Chetan Mehrotra
Assignee: Konrad Windszus
Priority: Minor
Fix For: i18n 2.4.4
At fresh startup seeing couple of exceptions like below. Looks like by the
time events are delivered ResourceResolverFactory is still not set
(ResourceResolverFactory is missing. Cannot create ResourceResolver) which
later causes NPE.
{noformat}
28.07.2015 09:37:49.803 *ERROR* [Thread-36]
org.apache.sling.i18n.impl.JcrResourceBundleProvider getResourceResolver:
ResourceResolverFactory is missing. Cannot create ResourceResolver
28.07.2015 09:37:49.804 *WARN* [Thread-36] org.apache.felix.eventadmin
Service [org.apache.sling.i18n.impl.JcrResourceBundleProvider,160,
[org.apache.sling.i18n.ResourceBundleProvider,
org.osgi.service.event.EventHandler]] EventAdmin: Exception during event
dispatch [org.osgi.service.event.Event
[topic=org/apache/sling/api/resource/Resource/ADDED] |
[org.apache.sling.i18n.ResourceBundleProvider,
org.osgi.service.event.EventHandler] | Bundle(org.apache.sling.i18n [93])]
(java.lang.NullPointerException)
java.lang.NullPointerException: null
at
org.apache.sling.i18n.impl.JcrResourceBundle.refreshSession(JcrResourceBundle.java:98)
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:250)
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.handleEvent(JcrResourceBundleProvider.java:229)
at
org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)
at
org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks$1.run(SyncDeliverTasks.java:145)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4944) JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it
[ https://issues.apache.org/jira/browse/SLING-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4944: --- Fix Version/s: (was: i18n 2.4.4) i18n 2.4.6 JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it - Key: SLING-4944 URL: https://issues.apache.org/jira/browse/SLING-4944 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.4 Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: i18n 2.4.6 After fixing SLING-4910 there is still a very slim chance that the resource resolver is being null while being used within the scheduleReloadBundles, because that is called, before the resolver is initialized. The chance to see that in reality is close to zero though, because scheduleReloadBundles is using the resource resolver only in a scheduled thread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4944) JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it
[ https://issues.apache.org/jira/browse/SLING-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-4944: --- Affects Version/s: (was: i18n 2.4.2) i18n 2.4.4 JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it - Key: SLING-4944 URL: https://issues.apache.org/jira/browse/SLING-4944 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: i18n 2.4.4 Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: i18n 2.4.6 After fixing SLING-4910 there is still a very slim chance that the resource resolver is being null while being used within the scheduleReloadBundles, because that is called, before the resolver is initialized. The chance to see that in reality is close to zero though, because scheduleReloadBundles is using the resource resolver only in a scheduled thread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4862) Sling Health Checks Servlet
[ https://issues.apache.org/jira/browse/SLING-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694800#comment-14694800 ] Georg Henzler commented on SLING-4862: -- [~bdelacretaz] Looks all good to me, I like the minimal text rendering that can be quite useful in shell scripts. Maybe the following two descriptions in the parameter documentation could be improved: - forceInstantExecution: Forces instant execution by executing async checks directly and circumventing the cache (2sec by default) of the health check executor - timeout: Timeout in ms - a timeout status is returned for any check still running after this period (this overrides the default timeout of the health check executor) Sling Health Checks Servlet --- Key: SLING-4862 URL: https://issues.apache.org/jira/browse/SLING-4862 Project: Sling Issue Type: Improvement Components: Health Check Reporter: Bertrand Delacretaz Priority: Minor Fix For: Health Check Core 1.2.4 Attachments: SLING-4862-HealthCheckExecutorServlet-v2.patch, SLING-4862-HealthCheckExecutorServlet.patch A Servlet that can execute health checks would be useful. It can take as input the tags of the HCs to execute, and output their results in JSON format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: Sling JCR Mocks, testing dependencies and imported ranges
hello konrad. i'm not sure if embedding more dependencies into the sling-mock JAR is a good idea. one main idea when designing sling-mock was that it should not be tied to a certain (esp. not only the newest) sling version/dependencies to still allow using it in projects that are using a sling version that is a bit older. in fact up to now sling-mocks imports only dependencies from ~mid 2013 and is thus quite compatible with most sling versions from then up to now for the most common testing use cases. when new features are added to APIs that need implementations we implement them in the mocks as well, but to not raise the dependency version to not force all users to this update. each project that uses sling-mocks usually has some dependencies already declared (e.g. the sling api version it uses), so this overwrites the dependencies from sling-mock. this approach has limitations: when a new interface we want to be upwards compatible to but not update the dependency version references a class not available in the old dependencies this way is no longer possible. fortunately this happens quite rarely. SLING-4932 may be such a case. aem-mock [1] for example overwrites all related dependencies with those from AEM6 because this is the main version the wcm.io libraries are currently targeted at. but with a different set of dependencies it should be possible to use sling mock with newer or older sling versions as well. of course it can be a bit brittle to get the dependencies right which may be inconvenient for the user. but when we embed some dependencies with a fixed version this may breaks this wide-range version compatibility, or at least may introduce a different behavior e.g. for the JCR-sling-resource mapping than is used really in the project itself, lessening the trustability of the unit tests. for oak or jackrabbit embedding the dependencies is not problematic, because sling and oak/jackrabbit are only loosely coupled via their respective APIs which are quite stable. obviously i want to avoid to have to maintain an own sling-mock version for each sling version or combination of sling api/jcr resource mapping/etc. version. stefan [1] http://wcm.io/testing/aem-mock/ -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Friday, August 07, 2015 3:04 PM To: dev@sling.apache.org Subject: Re: Sling JCR Mocks, testing dependencies and imported ranges Actually this does also affect sling-mocks IMHO (please compare with https://issues.apache.org/jira/browse/SLING-4932 https://issues.apache.org/jira/browse/SLING-4932). Therefore I suggest to also do the embedding in sling-mocks (https://issues.apache.org/jira/browse/SLING-4934 https://issues.apache.org/jira/browse/SLING-4934). Usually in our projects we have one big dependency management section reflecting the actual versions being running in Apache Felix (i.e. the runtime version). This may be newer versions than the ones sling-mocks is using. Unfortunately the dependency management does also affect the transitive dependencies of sling-mock at run-time (i.e. while executing the tests). Anything speaks against embedding all transitive dependencies there? Konrad On 11 Jun 2015, at 16:43, Stefan Seifert sseif...@pro-vision.de wrote: hello robert. to clarify for the others, this does not affect the primary mocks jcr-mock and sling-mock, but only if you want to use one of the (more experimental) mocks with real repository underneath, namely sling-mock-jackrabbit and sling- mock-oak. for most usecases the resourcresolver-mock or jcr-mock will suffice and has not this problem. but if a real repository like oak or jackrabbit is required one hits the problem as described by robert. 1+2 are real no options, 3 is quite inconvenient and complicates code coverage checks a lot. yes, embedding the oak/jackrabbit dependencies in the sling-mock- jackrabbit/sling-mock-oak artifacts could be a good option. the only small drawback i see is the bloating of the JAR file. perhaps we should give it a try. stefan -Original Message- From: Robert Munteanu [mailto:romb...@apache.org] Sent: Wednesday, June 10, 2015 5:08 PM To: Sling Dev Subject: 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.
[jira] [Resolved] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-4895. -- Resolution: Fixed I committed a slightly modified version of the patch in revision 1695707. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.1.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- 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.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 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] [Closed] (SLING-4935) Rhino scripts not based on a resource will not get cached correctly by the Sling Script Cache
[
https://issues.apache.org/jira/browse/SLING-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-4935.
---
Rhino scripts not based on a resource will not get cached correctly by the
Sling Script Cache
-
Key: SLING-4935
URL: https://issues.apache.org/jira/browse/SLING-4935
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting JavaScript 2.0.20
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting JavaScript 2.0.22
Rhino scripts not based on repository resources will not get cached correctly
by the Sling Script Cache since their default name will be set to the value
of the
{{org.apache.sling.scripting.javascript.internal.RhinoJavaScriptEngine#NO_SCRIPT_NAME}}
constant.
The first such script will get cached and attempts to run similar scripts
afterwards will always return the first compiled script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4931) Allow the script cache to observe other paths than search paths
[ https://issues.apache.org/jira/browse/SLING-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-4931. --- Allow the script cache to observe other paths than search paths --- Key: SLING-4931 URL: https://issues.apache.org/jira/browse/SLING-4931 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.32 Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting Core 2.0.34 There are cases when a script resides outside of search paths, in which case custom locations should be allowed to be added to the Script Cache Event Handler implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4936) Enhance the Sling Script Cache to only cache scripts from the search paths
[
https://issues.apache.org/jira/browse/SLING-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-4936.
---
Enhance the Sling Script Cache to only cache scripts from the search paths
--
Key: SLING-4936
URL: https://issues.apache.org/jira/browse/SLING-4936
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Core 2.0.32
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting Core 2.0.34
The {{ScriptCache}} implementation should not cache scripts which are not
stored in any of the configured search paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[RESULT][VOTE] Release Apache Sling Scripting Core 2.0.34
Hi, The vote passed with 3 +1 from: Stefan Egli, Carsten Ziegeler and Daniel Klco, therefore I'll start promoting the release. @PMC: please move the artifacts to dist. Thanks, Radu
[RESULT][VOTE] Release Apache Sling Scripting JavaScript 2.0.22
Hi, The vote passed with 3 +1 from: Stefan Egli, Carsten Ziegeler and Daniel Klco, therefore I'll start promoting the release. @PMC: please move the artifacts to dist. Thanks, Radu
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14695322#comment-14695322
]
Stefan Egli commented on SLING-3432:
Small but important correction to this one: {{TOPOLOGY_INIT}} must only be sent
when discovery has a stable view (contrary to my above comment). So, in 99% of
the cases {{TOPOLOGY_INIT}} should carry a {{getNewView}} which says
{{isCurrent()==true}} - but there's the unlikely situation that just when
discovery was starting to send out the {{TOPOLOGY_INIT}} event it
asynchronously noticed a view change - in which case {{isCurrent()==false}}...
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
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)
Re: [VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.8
On Mon, Aug 10, 2015 at 4:52 PM, Radu Cotescu r...@apache.org wrote: ...Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1311 ... +1, checked signatures, build and svn tag of the following archive SHA1(org.apache.sling.scripting.sightly.js.provider-1.0.8-source-release.zip)= 1be5df199a6737f2d30658802aef121eda84 -Bertrand
[RESULT][VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.8
Hi, The vote passed with 3 +1 from: Stefan Egli, Carsten Ziegeler and Bertrand Delacretaz, therefore I'll start promoting the release. @PMC: please move the artifacts to dist. Thanks, Radu
[jira] [Closed] (SLING-4940) Add the Sling ScriptCache configuration applied by o.a.s.s.sightly.js.provider to the provisioning model
[
https://issues.apache.org/jira/browse/SLING-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-4940.
---
Add the Sling ScriptCache configuration applied by
o.a.s.s.sightly.js.provider to the provisioning model
Key: SLING-4940
URL: https://issues.apache.org/jira/browse/SLING-4940
Project: Sling
Issue Type: Bug
Components: Scripting
Affects Versions: Scripting Sightly JS Use Provider 1.0.6
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Launchpad Builder 8, Scripting Sightly JS Use Provider
1.0.8
The {{ScriptCache}} configuration applied by the
{{org.apache.sling.scripting.sightly.js.provider}} for caching JS scripts
should be moved to the provisioning model, since the Sightly JavaScript Use
Provider is already present in the launchpad.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Sling JCR Mocks, testing dependencies and imported ranges
Hi Stefan, On 12 Aug 2015, at 21:26, Stefan Seifert sseif...@pro-vision.de wrote: hello konrad. i'm not sure if embedding more dependencies into the sling-mock JAR is a good idea. one main idea when designing sling-mock was that it should not be tied to a certain (esp. not only the newest) sling version/dependencies to still allow using it in projects that are using a sling version that is a bit older. in fact up to now sling-mocks imports only dependencies from ~mid 2013 and is thus quite compatible with most sling versions from then up to now for the most common testing use cases. Is thus quite compatible sounds too fuzzy for me. Since it is way too much effort to list which dependency versions are supported I would rather support only one version (which is the newest) and make that version unchangeable through e.g. dependencyManagement by embedding it. when new features are added to APIs that need implementations we implement them in the mocks as well, but to not raise the dependency version to not force all users to this update. each project that uses sling-mocks usually has some dependencies already declared (e.g. the sling api version it uses), so this overwrites the dependencies from sling-mock. this approach has limitations: when a new interface we want to be upwards compatible to but not update the dependency version references a class not available in the old dependencies this way is no longer possible. fortunately this happens quite rarely. SLING-4932 may be such a case. Updating sling-mock to a newer version which e.g. depends on a brand new version of sling API does not mean your code does need to depend on the same version of Sling API. You can easily override that by explicitly stating another dependency in your pom. That also won’t interfere with the maven-bundle-plugin as that will only evaluate the Maven compile class path (which sling-mock should never be part of) to figure out the import version range for packages. aem-mock [1] for example overwrites all related dependencies with those from AEM6 because this is the main version the wcm.io libraries are currently targeted at. but with a different set of dependencies it should be possible to use sling mock with newer or older sling versions as well. of course it can be a bit brittle to get the dependencies right which may be inconvenient for the user. but when we embed some dependencies with a fixed version this may breaks this wide-range version compatibility, or at least may introduce a different behavior e.g. for the JCR-sling-resource mapping than is used really in the project itself, lessening the trustability of the unit tests. for oak or jackrabbit embedding the dependencies is not problematic, because sling and oak/jackrabbit are only loosely coupled via their respective APIs which are quite stable. Since most of the API is backwards compatible anyways I don’t really see the risk here, if you use a different implementation in your unit test leveraging sling-mock as in your production environment. In the end you don’t want to test if the Sling/Jackrabbit/Oak implementation is correct rather than if your own code is correct. Could you give a good example where using sling-mock with a newer version of some Sling/Jackrabbit/Oak dependency lead to compatibility problems (i.e. your code runs in sling-mock, but not in your production environment)? What exactly has been changed in the jcr-resource mapping that would require testing with an older Sling dependency? obviously i want to avoid to have to maintain an own sling-mock version for each sling version or combination of sling api/jcr resource mapping/etc. version. I completely understand and therefore would only support the newest version (because testing should still cover old API usages, because it should be backwards compatible in most of the cases). Thanks, Konrad stefan [1] http://wcm.io/testing/aem-mock/ -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Friday, August 07, 2015 3:04 PM To: dev@sling.apache.org Subject: Re: Sling JCR Mocks, testing dependencies and imported ranges Actually this does also affect sling-mocks IMHO (please compare with https://issues.apache.org/jira/browse/SLING-4932 https://issues.apache.org/jira/browse/SLING-4932). Therefore I suggest to also do the embedding in sling-mocks (https://issues.apache.org/jira/browse/SLING-4934 https://issues.apache.org/jira/browse/SLING-4934). Usually in our projects we have one big dependency management section reflecting the actual versions being running in Apache Felix (i.e. the runtime version). This may be newer versions than the ones sling-mocks is using. Unfortunately the dependency management does also affect the transitive dependencies of sling-mock at run-time (i.e. while executing the tests). Anything speaks against embedding all transitive
[jira] [Comment Edited] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695740#comment-14695740 ] Manfred Baedke edited comment on SLING-4676 at 8/13/15 6:38 PM: Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. Opinions? was (Author: baedke): Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. Clean up threads or refresh threads when put back into the pool --- Key: SLING-4676 URL: https://issues.apache.org/jira/browse/SLING-4676 Project: Sling Issue Type: Improvement Components: Commons Reporter: Carsten Ziegeler Fix For: Commons Threads 3.2.2 Attachments: sling-4676-provisional.patch A thread from the pool might use thread locals which are - for whatever reason - not cleaned up, when the thread is put back into the pool. This can lead to memory leaks. We should protect against this. Unfortunately there is no official API to clean up thread locals. There are solutions out there using reflection. Another option is to simply discard the thread object after some time of usage and use a fresh one. This needs to include thread objects staying in the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695893#comment-14695893
]
Stefan Seifert commented on SLING-4932:
---
additionally i added a maven profile {{jcr.resource-2.5.4}} to the POM with
allows to run the unit tests with jcr.resource 2.5.4 (has to be executed
manually, not covered by CI).
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Assignee: Stefan Seifert
Fix For: Testing Sling Mock 1.4.2
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
RE: Sling JCR Mocks, testing dependencies and imported ranges
obviously i want to avoid to have to maintain an own sling-mock version for each sling version or combination of sling api/jcr resource mapping/etc. version. I completely understand and therefore would only support the newest version (because testing should still cover old API usages, because it should be backwards compatible in most of the cases). projects should contain the set to all sling bundle dependencies in their parent POMs which are used in their sling lauchpad or AEM version. then it is ensured sling-mock and the unit tests uses exactly that versions. and we try our best that sling-mock can use both old and new dependencies (e.g. via some reflection magic as in SLING-4932). embedding the dependences removes this control from the users which may lead to problems. e.g. embedding jcr.resource 2.5.4 would force uses to declare sling API 2.9.0 dependencies in their POM as well, otherwise the unit tests will fail. and in maven 3 it's no longer possible to define different versions for compile scope and test scope. stefan
[jira] [Resolved] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-4932.
---
Resolution: Fixed
Assignee: Stefan Seifert
Completed: At revision: 1695774
i switched dependency back to old API and jcr.resource version, and changed the
registration of the PathMapper service to use reflection. it is registered only
if it exists. the project that uses it then has to ensure it declares matching
dependencies for both jcr.resource and api bundle. if old versions are used
PathMapper services is not registered.
it think this should solve your problem.
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Assignee: Stefan Seifert
Fix For: Testing Sling Mock 1.4.2
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4945) Model files are missing from created repository
[ https://issues.apache.org/jira/browse/SLING-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4945: Fix Version/s: Slingstart Maven Plugin 1.3.2 Model files are missing from created repository --- Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4945) Model files are missing from created repository
[ https://issues.apache.org/jira/browse/SLING-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4945: Description: The repository goal is creating a repository of all referenced artifacts. The model of the project and all referenced model files are missing - the artifacts from those models are added Model files are missing from created repository --- Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 The repository goal is creating a repository of all referenced artifacts. The model of the project and all referenced model files are missing - the artifacts from those models are added -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4826) WebConsolePrinter.testConsolePrinter always fails on Java 8
[
https://issues.apache.org/jira/browse/SLING-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4826.
---
WebConsolePrinter.testConsolePrinter always fails on Java 8
---
Key: SLING-4826
URL: https://issues.apache.org/jira/browse/SLING-4826
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Scheduler 2.4.8
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Commons Scheduler 2.4.10
Attachments: SLING-4826_Tests_Fails_on_Java_8.patch
On builds.apache.org the test fails with Java 8 but passes with Java 7. I've
verified that the same happens locally, so this is not a flaky test.
*Error Message*
{noformat}Expecting regexp match: 'Job : testName2, class: java.lang.Thread,
concurrent: true, bundleId: 2, serviceId: 2' / '^Job.*testName3.*'{noformat}
*Stacktrace*
{noformat}java.lang.AssertionError: Expecting regexp match: 'Job : testName2,
class: java.lang.Thread, concurrent: true, bundleId: 2, serviceId: 2' /
'^Job.*testName3.*'
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.sling.commons.scheduler.impl.WebConsolePrinterTest.assertRegexp(WebConsolePrinterTest.java:86)
at
org.apache.sling.commons.scheduler.impl.WebConsolePrinterTest.testConsolePrinter(WebConsolePrinterTest.java:71){noformat}
*Standard Error*
{noformat}373 [main] INFO
org.apache.sling.commons.threads.impl.DefaultThreadPoolManager - Startet
Apache Sling Thread Pool Manager:
org.apache.sling.commons.threads.impl.DefaultThreadPoolManager
373 [main] ERROR
org.apache.sling.commons.threads.impl.DefaultThreadPoolManager -
Configuration admin is not available.
373 [main] INFO org.apache.sling.commons.threads.impl.DefaultThreadPool -
Initializing thread pool [testName] ...
373 [main] INFO org.apache.sling.commons.threads.impl.DefaultThreadPool -
Thread pool [testName] initialized.
373 [main] INFO org.quartz.core.SchedulerSignalerImpl - Initialized Scheduler
Signaller of type: class org.quartz.core.SchedulerSignalerImpl
373 [main] INFO org.quartz.core.QuartzScheduler - Quartz Scheduler v.2.2.1
created.
373 [main] INFO org.quartz.simpl.RAMJobStore - RAMJobStore initialized.
373 [main] INFO org.quartz.core.QuartzScheduler - Scheduler meta-data: Quartz
Scheduler (v2.2.1) 'ApacheSling' with instanceId
'Mon_Jun_22_08:44:40_UTC_2015'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool
'org.apache.sling.commons.scheduler.impl.QuartzScheduler$QuartzThreadPool' -
with 5 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support
persistence. and is not clustered.
374 [main] INFO org.quartz.impl.DirectSchedulerFactory - Quartz scheduler
'ApacheSling
374 [main] INFO org.quartz.impl.DirectSchedulerFactory - Quartz scheduler
version: 2.2.1
374 [main] INFO org.quartz.core.QuartzScheduler - Scheduler
ApacheSling_$_Mon_Jun_22_08:44:40_UTC_2015 started.
378 [main] INFO org.quartz.core.QuartzScheduler - Scheduler
ApacheSling_$_Mon_Jun_22_08:44:40_UTC_2015 shutting down.
378 [main] INFO org.quartz.core.QuartzScheduler - Scheduler
ApacheSling_$_Mon_Jun_22_08:44:40_UTC_2015 paused.
378 [main] INFO org.quartz.core.QuartzScheduler - Scheduler
ApacheSling_$_Mon_Jun_22_08:44:40_UTC_2015 shutdown complete.
378 [main] INFO org.apache.sling.commons.threads.impl.DefaultThreadPool -
Shutting down thread pool [testName] ...
378 [main] INFO org.apache.sling.commons.threads.impl.DefaultThreadPool -
Thread pool [testName] is shut down.{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE RESULT] Release Apache Sling Commons Scheduller 2.4.10
The vote passed with four binding +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-4945) Model files are missing from created repository
Carsten Ziegeler created SLING-4945: --- Summary: Model files are missing from created repository Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Carsten Ziegeler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4945) Model files are missing from created repository
[ https://issues.apache.org/jira/browse/SLING-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4945: --- Assignee: Carsten Ziegeler Model files are missing from created repository --- Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4945) Model files are missing from created repository
[ https://issues.apache.org/jira/browse/SLING-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4945: Affects Version/s: Slingstart Maven Plugin 1.3.0 Model files are missing from created repository --- Key: SLING-4945 URL: https://issues.apache.org/jira/browse/SLING-4945 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.3.0 Reporter: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695436#comment-14695436
]
Konrad Windszus commented on SLING-4932:
[~sseif...@pro-vision.de] I don't know how to fix this without raising the
dependency to Sling API 2.9.0. This is urgent for me because AEM 6.1 comes with
o.a.s.jcr.resource 2.5.0 (and is therefore listed in that version in our
dependencyManagement). It currently blocks us using sling-mock together with an
AEM 6.1 dependencyManagement. Do you want to take over that issue?
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Testing Sling Mock 1.4.2
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4932:
---
Assignee: (was: Konrad Windszus)
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Fix For: Testing Sling Mock 1.4.2
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (SLING-4932) Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
[
https://issues.apache.org/jira/browse/SLING-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reopened SLING-4932:
---
Assignee: Konrad Windszus
making it compatible is good, but raising the dependency esp. of the Sling API
for this is not good.
see my response to a related mail thread on this:
http://apache-sling.73963.n3.nabble.com/Sling-JCR-Mocks-testing-dependencies-and-imported-ranges-tp4051852p4053698.html
i've looked into details if we can solve this without raising the dependencies.
Sling Mock: Make compatible with o.a.s.jcr.resource 2.5.0
-
Key: SLING-4932
URL: https://issues.apache.org/jira/browse/SLING-4932
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Testing Sling Mock 1.4.2
Currently if using sling-mock 1.4 with a dependencyManagement setting the
version of jcr.resource to 2.5 the following error can be observed while
executing tests
{code}
org.apache.sling.testing.mock.osgi.ReferenceViolationException: Unable to
inject mandatory reference 'pathMapper' for class
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory
: no matching services were found.
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:313)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:289)
at
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:118)
at
org.apache.sling.testing.mock.sling.MockJcrResourceResolverFactory.getResourceResolverInternal(MockJcrResourceResolverFactory.java:66)
at
org.apache.sling.testing.mock.sling.AbstractMockResourceResolverFactory.getAdministrativeResourceResolver(AbstractMockResourceResolverFactory.java:106)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.resourceResolver(SlingContextImpl.java:179)
at
org.apache.sling.testing.mock.sling.context.SlingContextImpl.load(SlingContextImpl.java:237)
.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-4934: -- Issue Type: Improvement (was: Bug) Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus Attachments: SLING-4934-v01.patch, SLING-4934-v02.patch If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695419#comment-14695419 ] Stefan Seifert commented on SLING-4934: --- i'm not sure if this is a good idea, see my mail thread post http://apache-sling.73963.n3.nabble.com/Sling-JCR-Mocks-testing-dependencies-and-imported-ranges-tp4051852p4053698.html Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus Attachments: SLING-4934-v01.patch, SLING-4934-v02.patch If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-4934: -- Description: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4932. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. (was: If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management.) Sling Mock: Embed transitive dependencies - Key: SLING-4934 URL: https://issues.apache.org/jira/browse/SLING-4934 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing Sling Mock 1.4.0 Reporter: Konrad Windszus Attachments: SLING-4934-v01.patch, SLING-4934-v02.patch If you are using a DependencyManagement section in your pom refererencing a newer version of a dependency being also used by sling-mock, it will also influence the version of that transitive dependency of sling-mock at runtime. That may lead to issues like SLING-4932. Therefore I would suggest to also embed jcr.resource along with all other transitive dependencies within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. A related discussion can be found at http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that was not mentioning the problem with dependency management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4938) sling-mock: Transitive dependency reflections includes very old xml-apis
[
https://issues.apache.org/jira/browse/SLING-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695425#comment-14695425
]
Stefan Seifert commented on SLING-4938:
---
yes, this is a good idea.
we should just give it a try, exclude those dependencies and check if it at
least the unit tests still run.
sling-mock: Transitive dependency reflections includes very old xml-apis
Key: SLING-4938
URL: https://issues.apache.org/jira/browse/SLING-4938
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing Sling Mock 1.4.0
Reporter: Konrad Windszus
Whenever a maven project depends on {{o.a.s.testing.sling-mock}} it
automatically depends on {{xml-apis}} in version {{1.0.b2}}.
This is problematic as this is not only a very old version but also it is
very hard to determine which version should be used with which JRE
(http://stackoverflow.com/questions/11677572/dealing-with-xerces-hell-in-java-maven).
Therefore could we just explicitly ignore the transitive dependency {{dom4j}}
on the dependency {{reflections}} within {{sling-mock}}?
I see that {{reflections}} is only used in {{ModelAdapterFactoryUtil}} and I
don't see why {{dom4j}} would be necessary there. Maybe we could also get rid
of the other optional dependencies {{javassist}}, {{slf4j-api}}, {{gson}},
{{servlet-api}} (https://github.com/ronmamo/reflections/blob/master/pom.xml)?
That way the classpath would be much leaner and cleaner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
