Re: [RT] Sling Resource Providers for NoSQL databases - MongoDB, Couchbase
Am 27.01.15 um 17:09 schrieb Stefan Seifert: we currently evaluate to integrate a Couchbase NoSQL database [1] into a sling resource tree. as a starting point i had a deeper look on the MongoDB resource provider [2], because the concept is quite similar. some thoughts on this: 1. what is the status of the mongodb provider? is someone using it already in production? looking at the code it seems to be not threadsafe concerning the CRUD handling with non-synchronized hash maps. Afaik, there are people using that code slightly modified (not sure what the changes are) in production. I think the impl is thread safe as a resource provider by itself must not be thread safe. But if it's not, we should fix it. 3. the resource provider mixes up the in-memory CRUD handling with keeping maps of changed/deleted resources, and the mapping to the NoSQL structure. if these two aspects would be separated the former could be reused for all NoSQL databases and the latter is responsible only for the flat list resource-to-document mapping and will be different for each NoSQL database. bonus: the thread-safety of the CRUD handling has to be implemented only once, not once for each resource provider. additional logic like type mapping values to strings, generic value map implementations, automatic tree creation etc. could be shared between all NoSQL providers. Yes I heard this suggestion from several people already :) So +1 for refactoring. 4. an open point is whether to support binary data as well, or to leave it out in the first phase. storing binary data may be problematic for some NoSQL databases, requiring a separate storage concept for this. the mongodb resource provider currently does not support binary data. I guess as a first step, not supporting binaries is fine. In general it would be cool to have some more/better NoSQL support in Sling to attract devs using these storages. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle
[
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295162#comment-14295162
]
Carsten Ziegeler commented on SLING-4358:
-
The OSGi CPEG is currently of specifying a namespace for exactly saying this
bundle implements specification XYZ in version N, maybe it makes sense to wait
for the official namespace.
Although adding an own doesn't hurt of course
Add the 'Provide-Capability' OSGi header to the
org.apache.sling.scripting.sightly bundle
-
Key: SLING-4358
URL: https://issues.apache.org/jira/browse/SLING-4358
Project: Sling
Issue Type: Sub-task
Components: Scripting
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.0
The OSGi {{Provide-Capability}} \[0\] header should be added to the
{{org.apache.sling.scripting.sightly}} bundle to easily identify what version
of the Sightly specification \[1\] the bundle implements.
\[0\] - http://wiki.osgi.org/wiki/Provide-Capability
\[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle
[
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295167#comment-14295167
]
Radu Cotescu commented on SLING-4358:
-
In what release of the spec do we expect to have the namespace standardisation?
Add the 'Provide-Capability' OSGi header to the
org.apache.sling.scripting.sightly bundle
-
Key: SLING-4358
URL: https://issues.apache.org/jira/browse/SLING-4358
Project: Sling
Issue Type: Sub-task
Components: Scripting
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.0
The OSGi {{Provide-Capability}} \[0\] header should be added to the
{{org.apache.sling.scripting.sightly}} bundle to easily identify what version
of the Sightly specification \[1\] the bundle implements.
\[0\] - http://wiki.osgi.org/wiki/Provide-Capability
\[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.7 #1380
See https://builds.apache.org/job/sling-trunk-1.7/1380/changes
Jenkins build is back to stable : sling-trunk-1.7 #1381
See https://builds.apache.org/job/sling-trunk-1.7/1381/changes
Jenkins build is back to stable : sling-trunk-1.8 #667
See https://builds.apache.org/job/sling-trunk-1.8/667/changes
[jira] [Commented] (SLING-913) Add a cache for pre-compiled scripts
[ https://issues.apache.org/jira/browse/SLING-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294895#comment-14294895 ] Radu Cotescu commented on SLING-913: Wouldn't this still need a read operation to be performed, which in this case would be more expensive than reading the last modified property? Add a cache for pre-compiled scripts Key: SLING-913 URL: https://issues.apache.org/jira/browse/SLING-913 Project: Sling Issue Type: New Feature Components: Scripting Affects Versions: Scripting Core 2.0.2 Reporter: Felix Meschberger Attachments: SLING-913.patch The Java Scripting API provides support for scripting langugages which may precompile script source and reuse the precompiled scripts: javax.script.Compilable: May be implemented by a ScriptEngine if precompilation is supported javax.script.CompiledScript: Result of calling the Compilable.compile method. The CompiledScript can be called to repeatedly execute the script without the need for recompilation and thus for improved performance. The Sling Core Scripting support should make use of this functionality by maintaining a cache compiled scripts with the following properties * indexed by script path * size limited (using LinkedHashMap overwriting the removeEldestEntry method) * entries are weak or soft references ot cache entries A cache entry consists of the following information: * The CompiledScript instance * The time of last compilation. this is compared to the last modification time of the script to decide on whether to recompile We might probaly also try to add a reference to the script engine implementation bundle to only use the cache entry if the bundle has not been stopped since adding the cache entry Executing the script would then consist of the following steps: 1 Check the cache of precompiled scripts. if an entry exists and can be used, use it 2. if the ScriptEngine is Compilable: 2a. Compile the script and add it to the cache and use it 2b. Otherwise have the script engine execute the script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.7 #1377
See https://builds.apache.org/job/sling-trunk-1.7/changes
[RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli I will promote the artifacts to the central Maven repository and update this sling site. @any PMC member: please copy this release to the Sling dist directory. stefan
[jira] [Created] (SLING-4361) Improve handling of unregistering ResourceProviderFactories
Carsten Ziegeler created SLING-4361: --- Summary: Improve handling of unregistering ResourceProviderFactories Key: SLING-4361 URL: https://issues.apache.org/jira/browse/SLING-4361 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 Right now, if a ResourceProviderFactory is unregistered, the ResourceResolverFactory is first unregistered and then registered again. This is in order to clean up all usages of ResourceResolvers which might have a reference to the unregistered provider factory. This reregistration can lead to nearly the whole system going down and up again. Therefore if there are several unregistrations in a row, the system might go down and up several times. If there are circular dependencies, this might also result in an endless down/up loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock
Nicolas Peltier created SLING-4362:
--
Summary: [jcr mocks] Resource type not correctly loaded when using
jcr mock
Key: SLING-4362
URL: https://issues.apache.org/jira/browse/SLING-4362
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing JCR Mock 1.1.2
Reporter: Nicolas Peltier
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
thisIs:root,
foo:{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock
[
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-4362:
---
Description:
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
thisIs:root,
foo:{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
was:
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
thisIs:root,
foo:{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType
[jcr mocks] Resource type not correctly loaded when using jcr mock
--
Key: SLING-4362
URL: https://issues.apache.org/jira/browse/SLING-4362
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing JCR Mock 1.1.2
Reporter: Nicolas Peltier
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
thisIs:root,
foo:{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
Am 27.01.15 um 17:33 schrieb Bertrand Delacretaz: On Tue, Jan 27, 2015 at 5:15 PM, Stefan Seifert sseif...@pro-vision.de wrote: one (binding) vote is missing... it's fine for you to vote as well ;-) We need a third *binding* vote, and it realyl would be nice if more people would vote Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
+1 Sorry for the delay, been underwater lately. On Jan 28, 2015, at 10:36 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 27.01.15 um 17:33 schrieb Bertrand Delacretaz: On Tue, Jan 27, 2015 at 5:15 PM, Stefan Seifert sseif...@pro-vision.de wrote: one (binding) vote is missing... it's fine for you to vote as well ;-) We need a third *binding* vote, and it realyl would be nice if more people would vote Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is back to stable : sling-trunk-1.6 #2988
See https://builds.apache.org/job/sling-trunk-1.6/2988/changes
[jira] [Created] (SLING-4359) LargeTopologyWithHubTest.testLargeTopologyWithHub test failure
Stefan Egli created SLING-4359:
--
Summary: LargeTopologyWithHubTest.testLargeTopologyWithHub test
failure
Key: SLING-4359
URL: https://issues.apache.org/jira/browse/SLING-4359
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.12
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: Discovery Impl 1.0.14
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/1376/testReport/org.apache.sling.discovery.impl.topology/LargeTopologyWithHubTest/testLargeTopologyWithHub/
{code}
java.lang.AssertionError: expected:101 but was:43
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.sling.discovery.impl.topology.TopologyTestHelper.assertTopologyConsistsOf(TopologyTestHelper.java:127)
at
org.apache.sling.discovery.impl.topology.LargeTopologyWithHubTest.testLargeTopologyWithHub(LargeTopologyWithHubTest.java:84)
{code}
grepping for log.info testLargeTopologyWithHub shows :
{code}
28.01.2015 08:16:25 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 47 Instances
...
28.01.2015 08:16:32 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 46 Instances
...
28.01.2015 08:16:38 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 45 Instances
...
28.01.2015 08:16:44 *INFO * [main] LargeTopologyWithHubTest:
testLargeTopologyWithHub: checking if all connectors are registered,
TopologyView has 44 Instances
{code}
basically the instances die one after each other - probably due to no longer
sending heartbeats. I'll check
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
Am 28.01.15 um 10:55 schrieb Stefan Seifert: Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli I will promote the artifacts to the central Maven repository and update this sling site. @any PMC member: please copy this release to the Sling dist directory. Will do Thhanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build became unstable: sling-trunk-1.7 #1376
See https://builds.apache.org/job/sling-trunk-1.7/1376/changes
[jira] [Commented] (SLING-4340) SLING-4247 created odd side-effects
[ https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294941#comment-14294941 ] Carsten Ziegeler commented on SLING-4340: - [~justinedelson] What about a compromise: - we set the resource type based on Resource#getResourceType() as introduced in SLING-4247 - we set resource super type to sling:resourceType - if different from resource type Would that help in your case? SLING-4247 created odd side-effects --- Key: SLING-4340 URL: https://issues.apache.org/jira/browse/SLING-4340 Project: Sling Issue Type: Bug Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Resource Merger 1.2.4 The change made in SLING-4247 created an unfortunate side effect for this scenario: /apps/a/1/a - nt:unstructured node, no sling:resourceType property /apps/a/2/a - sling:resourceType set to foo/bar /apps/a/1 has sling:resourceSuperType set to /apps/a/2 Then resourceResolver.getResource(/mnt/override/apps/a/1/a).getResourceType() will be nt:unstructured This strikes me as wrong. And in fact screws up what is for me the main usage of this feature because it shouldn't be necessary to set the sling:resourceType all the time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4360) Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered
[ https://issues.apache.org/jira/browse/SLING-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4360. - Resolution: Fixed Solved as explained above Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered --- Key: SLING-4360 URL: https://issues.apache.org/jira/browse/SLING-4360 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 If the resource resolver factory is unregistered, the factory object itself can still be used (although it might fail) and the created resource resolver instances are not aware that the factory is gone either. We should add a marker to the factory which can be used by the resource resolver in the isLive() method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
+1, (verified md5/sha1) Cheers, Stefan On 1/27/15 5:15 PM, Stefan Seifert sseif...@pro-vision.de wrote: one (binding) vote is missing... stefan -Original Message- From: Stefan Seifert [mailto:sseif...@pro-vision.de] Sent: Thursday, January 22, 2015 10:11 PM To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2 Hi, We solved 2 issues in JCR Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329091 We solved 2 issues in ResourceResolver Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329092 We solved 3 issues in Sling Mock 1.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12329089 We solved 2 issues in Sling Mock Jackrabbit 0.1.2: https://issues.apache.org/jira/browse/SLING/fixforversion/12328858 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1175/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1175 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. stefan
Jenkins build is back to stable : sling-trunk-1.7 #1378
See https://builds.apache.org/job/sling-trunk-1.7/1378/changes
Re: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.2, ResourceResolver Mock 1.1.2, Sling Mock 1.1.2, Sling Mock Jackrabbit 0.1.2
Am 28.01.15 um 11:24 schrieb Carsten Ziegeler: Am 28.01.15 um 10:55 schrieb Stefan Seifert: Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli I will promote the artifacts to the central Maven repository and update this sling site. @any PMC member: please copy this release to the Sling dist directory. Will do Done Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-4360) Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered
Carsten Ziegeler created SLING-4360: --- Summary: Mark ResourceResolver and ResourceResolverFactory as invalid if factory is unregistered Key: SLING-4360 URL: https://issues.apache.org/jira/browse/SLING-4360 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 If the resource resolver factory is unregistered, the factory object itself can still be used (although it might fail) and the created resource resolver instances are not aware that the factory is gone either. We should add a marker to the factory which can be used by the resource resolver in the isLive() method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: SLING-4358 - provide/require capability, should we define a standard for capability names?
Hi, On Tue, Jan 27, 2015 at 6:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, By analogy with http://www.osgi.org/Specifications/ReferenceNamespaces, should we agree on a prefix such as org.apache.sling.capability.MMM for our capability names, where MMM is the module name like sightly? I don't see why not, it's good to namespace them. I would be slightly inclined to drop the 'capability' from the prefix, since it would look a bit rendundant. Compare Require-Capability: org.apache.sling.capability.sightly; filter:=(version=1.0) with Require-Capability: org.apache.sling.sightly; filter:=(version=1.0) Cheers, Robert
Re: svn commit: r1655278 - in /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource: Resource.java ResourceResolver.java
On Wed, 2015-01-28 at 12:29 +, cziege...@apache.org wrote:
Author: cziegeler
Date: Wed Jan 28 12:29:44 2015
New Revision: 1655278
URL: http://svn.apache.org/r1655278
Log:
Clarify lifetime of resource and resource resolver objects.
Modified:
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
Modified:
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
URL:
http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java?rev=1655278r1=1655277r2=1655278view=diff
==
---
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
(original)
+++
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/Resource.java
Wed Jan 28 12:29:44 2015
@@ -29,6 +29,11 @@ import aQute.bnd.annotation.ProviderType
* other types. A JCR based resource might support adapting to the JCR Node
on
* which the resource is based.
* p
+ * A codeResource/code object is valid for as long as the
+ * codeResourceResolver/code that provided this instance is valid. The
+ * same applies in general to all objects returned by this instance,
+ * especially those returned by a call to {@link #adaptTo(Class)}.
+ * p
* All implementations must support returning a value map from
* {@link #getValueMap()}, even if the map is empty.
* p
Modified:
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
URL:
http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java?rev=1655278r1=1655277r2=1655278view=diff
==
---
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
(original)
+++
sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolver.java
Wed Jan 28 12:29:44 2015
@@ -86,6 +86,12 @@ import aQute.bnd.annotation.ProviderType
* To check whether a Resource Resolver can still be used, the {@link
#isLive()}
* method can be called.
* p
+ * A codeResourceResolver/code is only valid for as long as the
+ * codeResourceResolverFactory/code that created this instance exists.
The
+ * same applies in general to all objects returned by this instance,
+ * especially for all instances. If the codeResourceResolverFactory/code
+ * does not exist anymore, the resource resolver instances becomes invalid.
+ * p
Not sure what the above is supposed to mean:
The same applies in general to all objects returned by this
instance, especially for all instances
Robert
[jira] [Commented] (SLING-4358) Add the 'Provide-Capability' OSGi header to the org.apache.sling.scripting.sightly bundle
[
https://issues.apache.org/jira/browse/SLING-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295223#comment-14295223
]
David Bosschaert commented on SLING-4358:
-
It will be in Enterprise R6.
However, we can also pre-empt that with a proprietary namespace. The once the
standard capability comes in, we can simply provide that alongside...
Add the 'Provide-Capability' OSGi header to the
org.apache.sling.scripting.sightly bundle
-
Key: SLING-4358
URL: https://issues.apache.org/jira/browse/SLING-4358
Project: Sling
Issue Type: Sub-task
Components: Scripting
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.0
The OSGi {{Provide-Capability}} \[0\] header should be added to the
{{org.apache.sling.scripting.sightly}} bundle to easily identify what version
of the Sightly specification \[1\] the bundle implements.
\[0\] - http://wiki.osgi.org/wiki/Provide-Capability
\[1\] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/releases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4318) Sling resource API does not expose any versioning features - bounty offered.
[ https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4318: --- Attachment: SLING-4318-test.patch The attached SLING-4318-test.patch provides some integration tests. The new V selector can potentially conflict with existing user servlets, we might want to put the versions servlet in a different bundle or make its selector configurable - I'll discuss this on the dev list. Sling resource API does not expose any versioning features - bounty offered. Key: SLING-4318 URL: https://issues.apache.org/jira/browse/SLING-4318 Project: Sling Issue Type: New Feature Components: Documentation, JCR, Servlets Affects Versions: Servlets Resolver 2.3.8 Environment: N/A Reporter: Bruce Edge Labels: api, crud, servlet-api, versioning, versions Attachments: SLING-4318-test.patch The javax.jcr.version.VersionManager is not exposed in the sling resource API: http://thread.gmane.org/gmane.comp.apache.sling.user/1610 My company is interested in paying for this development. Please contact if interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
SLING-4318 servlet that lists versions, potential conflict with V selector
Hi, For SLING-4318 Tomek's contribution uses the V selector that I suggested so that foo.V.json lists the versions of the foo node. Putting this servlet in our servlets.get bundle might interfere with existing user servlets that use this selector. How should we avoid this potential collision? Put the new servlet in a different bundle? Make its selector configurable? -Bertrand
[jira] [Commented] (SLING-4340) SLING-4247 created odd side-effects
[ https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295476#comment-14295476 ] Justin Edelson commented on SLING-4340: --- [~cziegeler] I think this will work for my use case, but I'd like to test a bit locally. [~gknob] any thoughts? SLING-4247 created odd side-effects --- Key: SLING-4340 URL: https://issues.apache.org/jira/browse/SLING-4340 Project: Sling Issue Type: Bug Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Resource Merger 1.2.4 The change made in SLING-4247 created an unfortunate side effect for this scenario: /apps/a/1/a - nt:unstructured node, no sling:resourceType property /apps/a/2/a - sling:resourceType set to foo/bar /apps/a/1 has sling:resourceSuperType set to /apps/a/2 Then resourceResolver.getResource(/mnt/override/apps/a/1/a).getResourceType() will be nt:unstructured This strikes me as wrong. And in fact screws up what is for me the main usage of this feature because it shouldn't be necessary to set the sling:resourceType all the time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.8 #674
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12
+1 On Jan 28, 2015, at 4:57 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we solved three issue https://issues.apache.org/jira/browse/SLING/fixforversion/12329309 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1178/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1178 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is still unstable: sling-trunk-1.7 #1383
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295900#comment-14295900
]
Alexander Klimetschek commented on SLING-4344:
--
Hmm, while the fix might be good, I don't think it's a good idea to put
resource bundles outside /apps or /libs. They are considered part of the code
base and thus follow very different ACLs and lifecycle than say /content (as in
above example), so you want to be really careful about this.
Modifying i18n language node in a path outside the resource resolver's search
path will not invalidate the ResourceBundle cache
---
Key: SLING-4344
URL: https://issues.apache.org/jira/browse/SLING-4344
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.3.2
Reporter: Konrad Windszus
Fix For: i18n 2.3.4
Attachments: SLING-4344-v02.patch
Currently any modification of a Sling i18n message will not invalidate the
{{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
basename and contents only outside of the resource resolver's search path are
always empty
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
I would argue that it should be allowed to place language nodes anywhere in
the repository, which seems to work well except for the cache invalidation.
The problem is in the {{loadFully}} method
(https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
which will only set languageRoots if they are below any of the resource
resolver's search paths.
To reproduce the issue you can just add the following node structure
{code}
/content/languages
+-- English (nt:folder, mix:language)
|+-- jcr:language = en
|+-- basename = myuniquebasename
|+-- m1 (sling:messageEntry)
||+-- sling:key = msg001
||+-- sling:message = This is a message
{code}
Then load the key from this resource bundle (by giving the right basename).
It will internally put the resource bundle into the cache (although all
contents of the given resource bundle are outside any of the default search
paths /apps or /libs). Whenever you change the message that won't be
reflected, because the resource bundle cache is not invalidated (caused by
the empty {{languageRoots}}) therefore the old message would still be
exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: SLING-4318 servlet that lists versions, potential conflict with V selector
Hello Justin, On Wed, Jan 28, 2015 at 8:14 PM, Justin Edelson jus...@justinedelson.com wrote: How about using ConfigurationPolicy.REQUIRE for this so that it needs to be manually enabled? I suspect that's probably a good idea for this feature anyway even if there was no potential collision. Great idea! I can add the ConfigurationPolicy and set the configuration as metatype, so users can create their configuration via Felix Console. Bertrand, WDYT? Regards, Tomek On Wed, Jan 28, 2015 at 12:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, For SLING-4318 Tomek's contribution uses the V selector that I suggested so that foo.V.json lists the versions of the foo node. Putting this servlet in our servlets.get bundle might interfere with existing user servlets that use this selector. How should we avoid this potential collision? Put the new servlet in a different bundle? Make its selector configurable? -Bertrand -- Tomek Rękawek Senior Software Engineer Cognifide Polska Sp. z o.o. skype: trekawek www.cognifide.com
[jira] [Created] (SLING-4363) Unregistering a resource provider should also reregister the resource resolver factory
Carsten Ziegeler created SLING-4363: --- Summary: Unregistering a resource provider should also reregister the resource resolver factory Key: SLING-4363 URL: https://issues.apache.org/jira/browse/SLING-4363 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 Right now, only if a resource provider factory is unregistered, the resource resolver factory is reregistered. This is in order to notify all clients which potentially have used an instance of the provider factory and restart them. However, if a client holds resources from an unregistered resource provider, this might result in a memory leak as well, therefore we should use the same mechanism and reregister the resource provider factory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Apache Sling Resource Resolver 1.1.12
Hi, we solved three issue https://issues.apache.org/jira/browse/SLING/fixforversion/12329309 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1178/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1178 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: svn commit: r1655278 - in /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource: Resource.java ResourceResolver.java
Not sure what the above is supposed to mean: The same applies in general to all objects returned by this instance, especially for all instances Good catch, thanks - I meant resources. Fixed now Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock
[
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295235#comment-14295235
]
Nicolas Peltier commented on SLING-4362:
my guess here is content loader uses modifiable value map to create the
resource that actually set the resourceType, but returns a resource based on
the node (whose transient space is disconected from the modifiable value map's
transient space).
[jcr mocks] Resource type not correctly loaded when using jcr mock
--
Key: SLING-4362
URL: https://issues.apache.org/jira/browse/SLING-4362
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing JCR Mock 1.1.2
Reporter: Nicolas Peltier
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4363) Unregistering a resource provider should also reregister the resource resolver factory
[ https://issues.apache.org/jira/browse/SLING-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4363. - Resolution: Fixed Fixed in rev 1655361 Unregistering a resource provider should also reregister the resource resolver factory -- Key: SLING-4363 URL: https://issues.apache.org/jira/browse/SLING-4363 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 Right now, only if a resource provider factory is unregistered, the resource resolver factory is reregistered. This is in order to notify all clients which potentially have used an instance of the provider factory and restart them. However, if a client holds resources from an unregistered resource provider, this might result in a memory leak as well, therefore we should use the same mechanism and reregister the resource provider factory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4362) [jcr mocks] Resource type not correctly loaded when using jcr mock
[
https://issues.apache.org/jira/browse/SLING-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-4362:
---
Description:
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
was:
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
thisIs:root,
foo:{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
[jcr mocks] Resource type not correctly loaded when using jcr mock
--
Key: SLING-4362
URL: https://issues.apache.org/jira/browse/SLING-4362
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing JCR Mock 1.1.2
Reporter: Nicolas Peltier
when setting resource resolver type to
ResourceResolverType.JCR_MOCK
such loaded json
{Code}
{
jcr:primaryType:nt:unstructured,
sling:resourceType: fooType,
thisIs: child
}
{Code}
to /content
gives /content/foo a resourceType == nt:unstructured instead of fooType,
other properties (here thisIs) are correctly loaded
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4361) Improve handling of unregistering ResourceProviderFactories
[ https://issues.apache.org/jira/browse/SLING-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4361. - Resolution: Fixed I've refactored the handling in 1655358 to use a background thread for coordination. When an unregistration happens, the reregistration is delayed for 2 secs Improve handling of unregistering ResourceProviderFactories --- Key: SLING-4361 URL: https://issues.apache.org/jira/browse/SLING-4361 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.10 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Resolver 1.1.12 Right now, if a ResourceProviderFactory is unregistered, the ResourceResolverFactory is first unregistered and then registered again. This is in order to clean up all usages of ResourceResolvers which might have a reference to the unregistered provider factory. This reregistration can lead to nearly the whole system going down and up again. Therefore if there are several unregistrations in a row, the system might go down and up several times. If there are circular dependencies, this might also result in an endless down/up loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build became unstable: sling-oak-it-1.6 #299
See https://builds.apache.org/job/sling-oak-it-1.6/299/changes
Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12
+1 On Jan 28, 2015 4:57 PM, Carsten Ziegeler cziege...@apache.org wrote: Hi, we solved three issue https://issues.apache.org/jira/browse/SLING/fixforversion/12329309 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1178/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1178 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build became unstable: sling-trunk-1.7 #1382
See https://builds.apache.org/job/sling-trunk-1.7/1382/changes
Jenkins build became unstable: sling-trunk-1.6 #2994
See https://builds.apache.org/job/sling-trunk-1.6/2994/changes
Re: [VOTE] Release Apache Sling Resource Resolver 1.1.12
+1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build became unstable: sling-trunk-1.8 #673
See https://builds.apache.org/job/sling-trunk-1.8/673/changes
[jira] [Created] (SLING-4364) Integrate new JavaScript node type library
Sandro Boehme created SLING-4364: Summary: Integrate new JavaScript node type library Key: SLING-4364 URL: https://issues.apache.org/jira/browse/SLING-4364 Project: Sling Issue Type: New Feature Components: Commons Reporter: Sandro Boehme Assignee: Sandro Boehme This copies the code I ([~sandro]) have written at GitHub [1] to Apache Sling as discussed [2] at the mailing list. [1] - https://github.com/sandroboehme/jsNodeTypes [2] - http://apache-sling.73963.n3.nabble.com/PROPOSAL-JSNodeTypes-contribution-tp4045070.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [PROPOSAL] JSNodeTypes contribution :: IP clearance needed?
Hi Bertrand, thanks for your feedback, that sounds good! If there are no objections I would commit it with SLING-4364 in the folder /contrib/commons/js/nodetypes with the Sling parent pom, the ArtifactId org.apache.sling.commons.js.nodetypes and the version 1.0.SNAPSHOT. Does that fit in the general structure? Best, Sandro Am 27.01.15 um 17:29 schrieb Bertrand Delacretaz: Hi Sandro, On Tue, Jan 27, 2015 at 4:51 PM, Sandro Boehme sandro.boe...@gmx.de wrote: ...Now that I'm a Committer in the meantime and I have written the JSNodeTypes library solely on my own the question is if the IP clearance process is still needed IMO it's not needed in this case, committing code that you wrote yourself is covered by your iCLA. I suggest that you wait 24 hours for possible objections, and if there's none go ahead and commit. -Bertrand
Re: SLING-4358 - provide/require capability, should we define a standard for capability names?
Hi I think the capability here really says „this bundle implements Sightly Language Spec 1.1“ And since this spec is outside of Sling at [1] and commonly referred to as sightly.io I would think we should be using a namespace which matches the Sightly Language Spec and is not implementation specific with Sling We could, of course, add an attribute indicating that this would be the Sling implementation. Regards Felix [1] https://github.com/Adobe-Marketing-Cloud/sightly-spec Am 28.01.2015 um 13:43 schrieb Robert Munteanu romb...@apache.org: Hi, On Tue, Jan 27, 2015 at 6:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, By analogy with http://www.osgi.org/Specifications/ReferenceNamespaces, should we agree on a prefix such as org.apache.sling.capability.MMM for our capability names, where MMM is the module name like sightly? I don't see why not, it's good to namespace them. I would be slightly inclined to drop the 'capability' from the prefix, since it would look a bit rendundant. Compare Require-Capability: org.apache.sling.capability.sightly; filter:=(version=1.0) with Require-Capability: org.apache.sling.sightly; filter:=(version=1.0) Cheers, Robert
Re: [PROPOSAL] JSNodeTypes contribution :: IP clearance needed?
Hi Sandro, On Wed, Jan 28, 2015 at 5:37 PM, Sandro Boehme sandro.boe...@gmx.de wrote: ...If there are no objections I would commit it with SLING-4364 in the folder /contrib/commons/js/nodetypes with the Sling parent pom, the ArtifactId org.apache.sling.commons.js.nodetypes and the version 1.0.SNAPSHOT Works for me but maybe use 0.1.0-SNAPSHOT so that the first release can be 1.0.0 We use alternating odd/even versions so after 1.0.0 it's 1.0.1-SNAPSHOT and the next release is 1.0.2. -Bertrand
Re: SLING-4318 servlet that lists versions, potential conflict with V selector
How about using ConfigurationPolicy.REQUIRE for this so that it needs to be manually enabled? I suspect that's probably a good idea for this feature anyway even if there was no potential collision. Regards, Justin On Wed, Jan 28, 2015 at 12:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, For SLING-4318 Tomek's contribution uses the V selector that I suggested so that foo.V.json lists the versions of the foo node. Putting this servlet in our servlets.get bundle might interfere with existing user servlets that use this selector. How should we avoid this potential collision? Put the new servlet in a different bundle? Make its selector configurable? -Bertrand
