[jira] [Updated] (SLING-4656) ProviderHandler implements compareTo incorreclty
[ https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4656: Fix Version/s: Resource Resolver 1.2.6 ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger Fix For: Resource Resolver 1.2.6 The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[ https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4655: Fix Version/s: Servlets Resolver 2.3.8 Servlet Resolver does not use registered servlet's service.ranking property --- Key: SLING-4655 URL: https://issues.apache.org/jira/browse/SLING-4655 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.3.6 Reporter: Felix Meschberger Fix For: Servlets Resolver 2.3.8 The Servlet Resolver registers a ResourceProvider for each Servlet service registered and handled by the ServletResolver, that is, those with a Sling servlet registration property. As the ResourceResolver supports ranking of ResourceProviders with the same root path, the ServletResolver should really register ResourceProvider services for servlets including the servlet service's service ranking property, if available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4656) ProviderHandler implements compareTo incorreclty
[ https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-4656: - Description: The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). In essence it implements natural ServiceReference ordering instead of ranking order which is the inverse. Two options to fix: * Fix ProviderHandler.compareTo to implement service ranking and thus revers of natural ordering * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. was: The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger Fix For: Resource Resolver 1.2.6 The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). In essence it implements natural ServiceReference ordering instead of ranking order which is the inverse. Two options to fix: * Fix ProviderHandler.compareTo to implement service ranking and thus revers of natural ordering * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4656) ProviderHandler implements compareTo incorreclty
[
https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510554#comment-14510554
]
Carsten Ziegeler commented on SLING-4656:
-
I think we should fix compareTo - I think it's a copy of the
ServiceReference.compareTo method
Adding these tests shows the problem
{noformat}
@Test public void testOrderingWithoutRanking() {
final MapString, Object props1 = new HashMapString, Object();
props1.put(Constants.SERVICE_ID, 1L);
final ProviderHandler ph1 = new MyProviderHandler(props1);
assertEquals(0, ph1.compareTo(ph1));
final MapString, Object props2 = new HashMapString, Object();
props2.put(Constants.SERVICE_ID, 2L);
final ProviderHandler ph2 = new MyProviderHandler(props2);
assertEquals(-1, ph1.compareTo(ph2));
assertEquals(1, ph2.compareTo(ph1));
}
@Test public void testOrderingWithRanking() {
final MapString, Object props1 = new HashMapString, Object();
props1.put(Constants.SERVICE_ID, 1L);
props1.put(Constants.SERVICE_RANKING, 50);
final ProviderHandler ph1 = new MyProviderHandler(props1);
final MapString, Object props2 = new HashMapString, Object();
props2.put(Constants.SERVICE_ID, 2L);
props2.put(Constants.SERVICE_RANKING, 150);
final ProviderHandler ph2 = new MyProviderHandler(props2);
assertEquals(1, ph1.compareTo(ph2));
assertEquals(-1, ph2.compareTo(ph1));
}
{noformat}
ProviderHandler implements compareTo incorreclty
Key: SLING-4656
URL: https://issues.apache.org/jira/browse/SLING-4656
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.4
Reporter: Felix Meschberger
Fix For: Resource Resolver 1.2.6
The implementation of the ResourceResolver's compareTo method is wrong as it
favors services registered later over services registered earlier, while
older services should actually be preferred (assuming there sevice.ranking
values are equal). In essence it implements natural ServiceReference ordering
instead of ranking order which is the inverse.
Two options to fix:
* Fix ProviderHandler.compareTo to implement service ranking and thus revers
of natural ordering
* Fix ResourceProviderEntry.conditionalSort to use a reverse comparator
While at it, the extraction of the service.ranking property is overly complex
since it first checks for null and then for the correct type. This can be
simplified by just checking for the correct type as a null value never
matches any type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_skip-underlying.patch
[~cziegeler], I have created a new patch (SLING-4568_skip-underlying.patch)
which does not contain the exclude search path configuration and does skip the
ParentHidingHandler also for listChildren and CRUDMergingResourceProvider.
Sorry for the detour, I should have seen before that there are other
ParentHidingHandler usages which should be adjusted as well.
I had to adjust the code in CRUDMergingResourceProvider#getAllResources a
little bit further to prevent that the parent is not read unnecessarily. I even
wanted to create a comment addResourceToHolder method, but this isn't possible
right now because they use different unrelated resource holder classes.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Exporting ServletResolverConstants in org.apache.sling.servlets.resolver
Hi devs, why is the class ServletResolverConstants in the Apache Sling Servlet Resolver not accessible in an exported package? I’m currently implementing a SCR component that registers multiple Services based on some configurations shared between them. One of this Services implements javax.servlet.Servlet as a Sling Servlet. Now I was wondering why those constants are not exported, because I think it can be a quite common use case to register services not using SCR (especially the @SlingServlet annotation). Cheers, Dirk Rudolph | Senior Software Engineer Netcentric AG M: +41 79 642 37 11 D: +49 174 966 84 34 dirk.rudo...@netcentric.biz | www.netcentric.biz
[jira] [Commented] (SLING-4415) :applyTo should not display changeLog (when operation fails)
[
https://issues.apache.org/jira/browse/SLING-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510911#comment-14510911
]
Antonio Sanso commented on SLING-4415:
--
in order to reproduce:
* Create an user with username/password test/test and do not give any permission
* Assume that a folder /libs exist with several subfolders (e.g. with the first
one being sling)
* launch this command
{code}
curl -v -F:operation=delete -F:applyTo=/libs/* -u test:test
http://localhost:4502
{code}
The response leaks information
{code}
HTTP/1.1 100 Continue
HTTP/1.1 500 Server Error
Date: Fri, 24 Apr 2015 12:08:32 GMT
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
* Server Jetty(9.2.9.v20150224) is not blacklisted
Server: Jetty(9.2.9.v20150224)
X-Powered-By: Jetty(9.2.9.v20150224)
* HTTP error before end of send, stop sending
html
head
titleError while processing //title
/head
body
h1Error while processing //h1
table
tbody
tr
tdStatus/td
tddiv id=Status500/div/td
/tr
tr
tdMessage/td
tddiv id=Messagejavax.jcr.RepositoryException:
org.apache.sling.api.resource.PersistenceException: Unable to delete resource
at /libs/sling. Resource does not exist./div/td
/tr
tr
tdLocation/td
tda href=/ id=Location//a/td
/tr
tr
tdParent Location/td
tda href= id=ParentLocation/a/td
/tr
tr
tdPath/td
tddiv id=Path//div/td
/tr
tr
tdReferer/td
tda href= id=Referer/a/td
/tr
tr
tdChangeLog/td
tddiv id=ChangeLoglt;pregt;lt;/pregt;/div/td
/tr
/tbody
/table
pa href=Go Back/a/p
pa href=/Modified Resource/a/p
pa href=Parent of Modified Resource/a/p
/body
{code}
:applyTo should not display changeLog (when operation fails)
Key: SLING-4415
URL: https://issues.apache.org/jira/browse/SLING-4415
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Post 2.3.6
Reporter: Lars Krapf
Assignee: Antonio Sanso
When the :applyTo operation fails the change-log leaks information about the
internal path-structure even when the requesting session does not have access
to these paths.
One solution would be to completely omit the ChangeLog (at least when the
operation fails), another option would be to make the :sendError behaviour
configurable in the POST servlet, so that the error message can be reliably
overlaid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.7 #1748
See https://builds.apache.org/job/sling-trunk-1.7/1748/changes
Build failed in Jenkins: sling-contrib-1.7 #22
See https://builds.apache.org/job/sling-contrib-1.7/22/changes Changes: [cziegeler] Add missing plugin versions [cziegeler] Remove duplicate dependency [cziegeler] Remove unnecessary jdk 6 profile -- [...truncated 51015 lines...] [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingJcrIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingScriptingThymeleafIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingAuthOpenidIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingJcrJackrabbitSecurityIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionQueryIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionSecurityIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingCommonsThreadsIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingLaunchpadOakTarIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingInstallerIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionI18nIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionDistributionIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingScriptingGroovyIT.class 2015-04-24 08:03:08,326 | INFO | FelixStartLevel | DefaultThreadPool | 126 - org.apache.sling.commons.threads - 3.2.0 | Initializing thread pool [default] ... [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionBundleresourceIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/JackrabbitSlingIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingScriptingSightlyIT.class 2015-04-24 08:03:08,327 | INFO | FelixStartLevel | DefaultThreadPool | 126 - org.apache.sling.commons.threads - 3.2.0 | Thread pool [default] initialized. [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingCommonsSchedulerIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionDiscoveryIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingExtensionExplorerIT.class [org.ops4j.pax.tinybundles.core.intern.RawBuilder] : Copying resource org/apache/sling/launchpad/karaf/tests/bootstrap/SlingScriptingJavascriptIT.class [org.ops4j.store.intern.TemporaryStore] : Exit store(): 7bed4068091152dd20eb1f86a9becf37988fda43 [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : Preparing and Installing bundle (from stream ).. [org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient] : Packing probe into memory for true RMI. Hopefully things will fill in.. 2015-04-24 08:03:08,355 | INFO | FelixStartLevel | SchedulerSignalerImpl | 127 - org.apache.sling.commons.scheduler - 2.4.6 | Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2015-04-24 08:03:08,355 | INFO | FelixStartLevel | QuartzScheduler | 127 - org.apache.sling.commons.scheduler - 2.4.6 | Quartz Scheduler v.2.2.1 created. 2015-04-24 08:03:08,359 | INFO | FelixStartLevel | RAMJobStore | 127 - org.apache.sling.commons.scheduler - 2.4.6 | RAMJobStore initialized. 2015-04-24 08:03:08,360 | INFO | FelixStartLevel | QuartzScheduler | 127 - org.apache.sling.commons.scheduler - 2.4.6 | Scheduler meta-data: Quartz Scheduler (v2.2.1) 'ApacheSling' with instanceId 'Fri_Apr_24_08:03:08_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' -
[jira] [Commented] (SLING-4607) Implement MockSlingHttpServletRequest.adaptTo(Resource.class)
[
https://issues.apache.org/jira/browse/SLING-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510730#comment-14510730
]
Robert Munteanu commented on SLING-4607:
[~georg.koester] - I reviewed the pull request and it looks good. However, I
wanted to test if the request.adaptTo behaviour appears in the production code
as well, and it does not .My test was the following ( on an empty Sling
Launchpad 7 instance ):
{noformat}
curl -u admin:admin -X POST -Fsling:resourceType=my/testscript
http://localhost:8080/content
curl -u admin:admin -X MKCOL http://localhost:8080/apps/my
curl -u admin:admin -X MKCOL http://localhost:8080/apps/my/testscript
curl -u admin:admin -T testscript.jsp
http://localhost:8080/apps/my/testscript/html.jsp
{noformat}
{code:title=testscript.jsp}
%@taglib prefix=sling uri=http://sling.apache.org/taglibs/sling; %
sling:defineObjects /
slingRequest.adaptTo(Resource.class): %=
slingRequest.adaptTo(org.apache.sling.api.resource.Resource.class) % br /
slingRequest.getResource() : %= slingRequest.getResource() %
{code}
The result I get is
{noformat}slingRequest.adaptTo(Resource.class): null
slingRequest.getResource() : JcrNodeResource, type=my/testscript,
superType=null, path=/content {noformat}
Does this work for you with production code?
Implement MockSlingHttpServletRequest.adaptTo(Resource.class)
-
Key: SLING-4607
URL: https://issues.apache.org/jira/browse/SLING-4607
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Commons Testing 2.0.16
Reporter: Georg Koester
Assignee: Robert Munteanu
Priority: Minor
{code}
request = new MockSlingHttpServletRequest(...);
request.setResource(resource);
assertSame(resource, request.getResource());
assertSame(resource, request.adaptTo(Resource.class));
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4657) Sporadic test failure of WriteableResourcesProxyTest on java 8
Carsten Ziegeler created SLING-4657: --- Summary: Sporadic test failure of WriteableResourcesProxyTest on java 8 Key: SLING-4657 URL: https://issues.apache.org/jira/browse/SLING-4657 Project: Sling Issue Type: Bug Components: Launchpad Environment: java 8, jenkins Reporter: Carsten Ziegeler Fix For: Launchpad Testing 7 org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest Schlägt fehl seit 1 Build (Seit Instabil#1034 ) Dauer: 0.5 Sekunden. 1 tests failed:[testSimpleCRUD(org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest): null] Stacktrace java.lang.AssertionError: 1 tests failed:[testSimpleCRUD(org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest): null] at org.junit.Assert.fail(Assert.java:88) at org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:109) at org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest(WriteableResourcesProxyTest.java:26) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.8 #1035
See https://builds.apache.org/job/sling-trunk-1.8/1035/changes
[jira] [Resolved] (SLING-4469) SlingPostServlet: do not allow redirects to other hosts
[
https://issues.apache.org/jira/browse/SLING-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-4469.
Resolution: Fixed
Fix Version/s: Servlets POST 2.3.8
SlingPostServlet: do not allow redirects to other hosts
---
Key: SLING-4469
URL: https://issues.apache.org/jira/browse/SLING-4469
Project: Sling
Issue Type: Improvement
Affects Versions: Servlets Post 2.3.6
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Servlets POST 2.3.8
Attachments: SLING-4469-v01.patch
Through the {{:redirect}} parameter of the {{SlingPostServlet}} arbitrary
redirects are possible
(http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect).
That should be limited so that redirects to other servers are not possible.
Compare also with discussion at:
http://www.mail-archive.com/dev@sling.apache.org/msg43348.html.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Karaf integration tests running times
On Thu, Apr 23, 2015 at 4:19 PM, Carsten Ziegeler cziege...@apache.org wrote: While we're at it, my build takes forever at Building Apache Sling Launchpad Debian Package Builder 8-SNAPSHOT it seems its executing scripts and whatnot. Does anyone know what it actually does? https://issues.apache.org/jira/browse/SLING-4151 is the initial bug. I guess Tomek and/or Bruce can offer more details. Robert -- Sent from my (old) computer
Jenkins build is unstable: sling-contrib-1.7 #23
See https://builds.apache.org/job/sling-contrib-1.7/23/
Jenkins build is unstable: sling-trunk-1.7 #1747
See https://builds.apache.org/job/sling-trunk-1.7/1747/changes
[jira] [Commented] (SLING-4656) ProviderHandler implements compareTo incorreclty
[ https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510660#comment-14510660 ] Felix Meschberger commented on SLING-4656: -- Thanks for the tests. Will fix compareTo as proposed (sounds to be the better option to me as well) ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger Fix For: Resource Resolver 1.2.6 The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). In essence it implements natural ServiceReference ordering instead of ranking order which is the inverse. Two options to fix: * Fix ProviderHandler.compareTo to implement service ranking and thus revers of natural ordering * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4656) ProviderHandler implements compareTo incorreclty
[ https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-4656: Assignee: Felix Meschberger ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Resource Resolver 1.2.6 The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). In essence it implements natural ServiceReference ordering instead of ranking order which is the inverse. Two options to fix: * Fix ProviderHandler.compareTo to implement service ranking and thus revers of natural ordering * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[ https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-4655. -- Resolution: Fixed Assignee: Felix Meschberger Fixed in Rev. 1675803: * Added method to create servie registration properties for ServletResourceProvider registration * Added test case for new method Servlet Resolver does not use registered servlet's service.ranking property --- Key: SLING-4655 URL: https://issues.apache.org/jira/browse/SLING-4655 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.3.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Servlets Resolver 2.3.8 The Servlet Resolver registers a ResourceProvider for each Servlet service registered and handled by the ServletResolver, that is, those with a Sling servlet registration property. As the ResourceResolver supports ranking of ResourceProviders with the same root path, the ServletResolver should really register ResourceProvider services for servlets including the servlet service's service ranking property, if available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510745#comment-14510745
]
Carsten Ziegeler commented on SLING-4568:
-
[~joelrich] It seems your patch is not against current trunk, so I can't apply
it. Could you please recreate a patch based on current trunk? Thanks
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Karaf integration tests running times
Am 24.04.15 um 11:44 schrieb Robert Munteanu: On Thu, Apr 23, 2015 at 4:19 PM, Carsten Ziegeler cziege...@apache.org wrote: While we're at it, my build takes forever at Building Apache Sling Launchpad Debian Package Builder 8-SNAPSHOT it seems its executing scripts and whatnot. Does anyone know what it actually does? https://issues.apache.org/jira/browse/SLING-4151 is the initial bug. I guess Tomek and/or Bruce can offer more details. Ok, thanks. I moved this into a separate package as I don't see why it should run on each and every contrib build. Especially as it fails at least on my machine :) Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build became unstable: sling-trunk-1.8 #1034
See https://builds.apache.org/job/sling-trunk-1.8/1034/changes
[jira] [Updated] (SLING-4657) Sporadic test failure of WriteableResourcesProxyTest on java 8
[ https://issues.apache.org/jira/browse/SLING-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-4657: --- Labels: sling-IT (was: ) Sporadic test failure of WriteableResourcesProxyTest on java 8 -- Key: SLING-4657 URL: https://issues.apache.org/jira/browse/SLING-4657 Project: Sling Issue Type: Bug Components: Launchpad Environment: java 8, jenkins Reporter: Carsten Ziegeler Labels: sling-IT Fix For: Launchpad Testing 7 org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest Schlägt fehl seit 1 Build (Seit Instabil#1034 ) Dauer: 0.5 Sekunden. 1 tests failed:[testSimpleCRUD(org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest): null] Stacktrace java.lang.AssertionError: 1 tests failed:[testSimpleCRUD(org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest): null] at org.junit.Assert.fail(Assert.java:88) at org.apache.sling.launchpad.webapp.integrationtest.util.ServerSideTestClient.assertTestsPass(ServerSideTestClient.java:109) at org.apache.sling.launchpad.webapp.integrationtest.WriteableResourcesProxyTest.runWriteableResourcesTest(WriteableResourcesProxyTest.java:26) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4656) ProviderHandler implements compareTo incorreclty
[ https://issues.apache.org/jira/browse/SLING-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-4656. -- Resolution: Fixed Fixed in Rev. 1675805: * Document natural order of ProviderHandler to be the same as service.ranking order. which is the revers of the natural ServiceReference order previously implemented * Added test case by Carsten Ziegeler (thanks) ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Resource Resolver 1.2.6 The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). In essence it implements natural ServiceReference ordering instead of ranking order which is the inverse. Two options to fix: * Fix ProviderHandler.compareTo to implement service ranking and thus revers of natural ordering * Fix ResourceProviderEntry.conditionalSort to use a reverse comparator While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[ https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510658#comment-14510658 ] Felix Meschberger edited comment on SLING-4655 at 4/24/15 8:58 AM: --- Fixed in Rev. 1675803: * Added method to create servie registration properties for ServletResourceProvider registration * Added test case for new method was (Author: fmeschbe): Fixed in Rev. 1675803: * Added method to create servie registration properties for ServletResourceProvider registration * Added test case for new method Servlet Resolver does not use registered servlet's service.ranking property --- Key: SLING-4655 URL: https://issues.apache.org/jira/browse/SLING-4655 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.3.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Servlets Resolver 2.3.8 The Servlet Resolver registers a ResourceProvider for each Servlet service registered and handled by the ServletResolver, that is, those with a Sling servlet registration property. As the ResourceResolver supports ranking of ResourceProviders with the same root path, the ServletResolver should really register ResourceProvider services for servlets including the servlet service's service ranking property, if available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4415) :applyTo should not display changeLog (when operation fails)
[ https://issues.apache.org/jira/browse/SLING-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso reassigned SLING-4415: Assignee: Antonio Sanso :applyTo should not display changeLog (when operation fails) Key: SLING-4415 URL: https://issues.apache.org/jira/browse/SLING-4415 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.3.6 Reporter: Lars Krapf Assignee: Antonio Sanso When the :applyTo operation fails the change-log leaks information about the internal path-structure even when the requesting session does not have access to these paths. One solution would be to completely omit the ChangeLog (at least when the operation fails), another option would be to make the :sendError behaviour configurable in the POST servlet, so that the error message can be reliably overlaid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Karaf integration tests running times
On Thu, Apr 23, 2015 at 8:29 PM, Oliver Lietz apa...@oliverlietz.de wrote: On Thursday 23 April 2015 14:44:49 Bertrand Delacretaz wrote: On Thu, Apr 23, 2015 at 1:51 PM, Oliver Lietz apa...@oliverlietz.de wrote: ...Apart from that we can create a dedicated build job for Karaf Launchpad That would be great as it looks like that would speed up the contrib build job a lot. Yes, the 53 integration tests currently take 40 minutes when not failing and this is worth a dedicated build job. While we're at it... is there a build job for running Launchpad's integration tests? We currently build and test the launchpad for each 'folder' - / and /contrib There's the sling-oak-it-1.7 job, but that's because we run against Jackrabbit by default. That being said, I was considering splitting our jobs a bit, so that the integrations tests run after all modules are built and deployed, e.g. sling-trunk-1.7 ( mvn clean deploy # no IT ) \- sling-trunk-it-1.7 ( just ITs, Jackrabbit ) \- sling-trunk-oak-it-1.7 ( just ITs, Oak ) The 1.8 version would be the same, just that we would run mvn clean install on sling-trunk-1.8, as we have already deployed the modules previously . H, maybe it makes sense to also trigger sling-trunk-it-1.8 from sling-trunk-1.7, and leave sling-trunk-1.8 as a simple mvn clean install to validate that the per-module tests run with Java 8. And then we can apply the same pattern to contrib sling-contrib-1.7 ( mvn clean deploy, # no ITs ) \- sling-contrib-it-1.7 \- sling-contrib-karaf-1.7 \- sling-contrib-it-1.7 Thoughts? Robert I still have failing tests when running Launchpad's integration tests against Karaf but I don't think Karaf is the cause (well, there is one test for Felix Http's filter support and Karaf makes use of Pax Web). Regards, O. -Bertrand
[jira] [Commented] (SLING-4469) SlingPostServlet: do not allow redirects to other hosts
[
https://issues.apache.org/jira/browse/SLING-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510907#comment-14510907
]
Konrad Windszus commented on SLING-4469:
Applied in rev. 1675822.
SlingPostServlet: do not allow redirects to other hosts
---
Key: SLING-4469
URL: https://issues.apache.org/jira/browse/SLING-4469
Project: Sling
Issue Type: Improvement
Affects Versions: Servlets Post 2.3.6
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: Servlets POST 2.3.8
Attachments: SLING-4469-v01.patch
Through the {{:redirect}} parameter of the {{SlingPostServlet}} arbitrary
redirects are possible
(http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#redirect).
That should be limited so that redirects to other servers are not possible.
Compare also with discussion at:
http://www.mail-archive.com/dev@sling.apache.org/msg43348.html.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4607) Implement MockSlingHttpServletRequest.adaptTo(Resource.class)
[
https://issues.apache.org/jira/browse/SLING-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned SLING-4607:
--
Assignee: Robert Munteanu
Implement MockSlingHttpServletRequest.adaptTo(Resource.class)
-
Key: SLING-4607
URL: https://issues.apache.org/jira/browse/SLING-4607
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Commons Testing 2.0.16
Reporter: Georg Koester
Assignee: Robert Munteanu
Priority: Minor
{code}
request = new MockSlingHttpServletRequest(...);
request.setResource(resource);
assertSame(resource, request.getResource());
assertSame(resource, request.adaptTo(Resource.class));
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-2387) OBR at http://sling.apache.org/obr/repository.xml is totally out of date
[ https://issues.apache.org/jira/browse/SLING-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-2387: -- Assignee: Robert Munteanu OBR at http://sling.apache.org/obr/repository.xml is totally out of date Key: SLING-2387 URL: https://issues.apache.org/jira/browse/SLING-2387 Project: Sling Issue Type: Bug Reporter: Markus Joschko Assignee: Robert Munteanu Priority: Minor Attachments: screenshot-1.png It would be quite handy to have the most recent stable bundles of sling available in a bundle repository so that existing installations can easily be updated. However the versions in the existing obr are out of date (way out of date). If there is a way to automate the deployment I might be able to give a hand. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-contrib-1.7 #24
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-contrib-1.7 #25
See https://builds.apache.org/job/sling-contrib-1.7/changes
[jira] [Commented] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510943#comment-14510943
]
Stefan Egli commented on SLING-4627:
I think the core of your suggestion is to add some help (by the api) to
simplify the work of a listener when it has to find out if an instance has
joined or left the local cluster. That could indeed make listener's life easier.
However I don't think we necessarily have to change the api for this: I think
all the information is already encapsulated in the TopologyEvent: it knows if
it is a CHANGED event (only then this help is needed), it has the old and the
new view and can provide additional helper methods easily - or by a adjacent
TopologyEventHelper for example.
So I think you could add this functionality to the discovery.api without any
need for change by any discovery.*impl, and even remaining backwards compatible
by adding eg the following methods to either TopologyEvent or creating a new
TopologyEventHelper (in the latter case the methods would of course look
slightly different):
{code}
// added to either TopologyEvent or slightly different to a new
TopologyEventHelper
/**
* @return the list of {@code InstanceDescription} for each instance that
* have been added.
*/
ListInstanceDescription getAddedInstances() {
//TODO
}
/**
*
* @return the list of {@code InstanceDescription} for each instance that
* have been removed.
*/
ListInstanceDescription getRemovedInstances() {
//TODO
}
{code}
wdyt?
TOPOLOGY_CHANGED in an eventually consistent repository
---
Key: SLING-4627
URL: https://issues.apache.org/jira/browse/SLING-4627
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Egli
Priority: Critical
This is a parent ticket describing the +coordination effort needed between
properly sending TOPOLOGY_CHANGED when running ontop of an eventually
consistent repository+. These findings are independent of the implementation
details used inside the discovery implementation, so apply to discovery.impl,
discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific
implementation are best created separately (eg sub-task or related..). Also
note that this assumes immediately sending TOPOLOGY_CHANGING as described [in
SLING-3432|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
h5. The spectrum of possible TOPOLOGY_CHANGED events include the following
scenarios:
|| scenario || classification || action ||
| A. change is completely outside of local cluster | (/) uncritical | changes
outside the cluster are considered uncritical for this exercise. |
| B. a new instance joins the local cluster, this new instance is by contract
not the leader (leader must be stable \[0\]) | (/) uncritical | a join of an
instance is uncritical due to the fact that it merely joins the cluster and
has thus no 'backlog' of changes that might be propagating through the
(eventually consistent) repository. |
| C. a non-leader *leaves* the local cluster | (x) *critical* | changes that
were written by the leaving instance might still not be *seen* by all
surviving (ie it can be that discovery is faster than the repository) and
this must be assured before sending out TOPOLOGY_CHANGED. This is because the
leaving instance could have written changes that are *topology dependent* and
thus those changes must first be settled in the repository before continuing
with a *new topology*. |
| D. the leader *leaves* the local cluster (and thus a new leader is elected)
| (x)(x) *very critical* | same as C except that this is more critical due to
the fact that the leader left |
| E. -the leader of the local cluster changes (without leaving)- this is not
supported by contract (leader must be stable \[0\]) | (/) -irrelevant- | |
So both C and D are about an instance leaving. And as mentioned above the
survivors must assure they have read all changes of the leavers. There are
two parts to this:
* the leaver could have pending writes that are not yet in mongoD: I don't
think this is the case. The only thing that can remain could be an
uncommitted branch and that would be rolled back afaik.
** Exception to this is a partition: where the leaver didn't actually crash
but is still hooked to the repository. *For this I'm not sure how it can be
solved* yet.
* the survivers could however not yet have read all changes (pending in the
background read) and one way to make sure they did is to have each surviving
instance write a (pseudo-) sync token to the repository. Once
[jira] [Updated] (SLING-4178) ValueMapDecorator.convertToArray will never return null (even if type conversion does not work)
[
https://issues.apache.org/jira/browse/SLING-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4178:
---
Fix Version/s: API 2.10.0
ValueMapDecorator.convertToArray will never return null (even if type
conversion does not work)
---
Key: SLING-4178
URL: https://issues.apache.org/jira/browse/SLING-4178
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: API 2.8.0
Reporter: Konrad Windszus
Fix For: API 2.10.0
Currently the {{ValueMapDecorator}} will never return {{null}} in case type
conversion fails and an array type was requested.
This is neither the case if the underlying map did not contain multiple
values (and it was converted a single element array), nor if the underlying
array was of a different (incompatible) type.
For the first case a single element array with value null is returned, for
the second case an array is returned which only contains null values (as many
as original values).
I would propose the following change:
# if array was requested and underlying data is an array: return null instead
of array with null items if no item could be converted to the requested array
type.
# if array was requested and underlying data is an array: only return those
items which could be converted to the requested type (leave out the others)
# if array was requested and underlying data is not an array: return null if
value could not be converted to the requested array type.
This should still be in sync with the behaviour described in SLING-662.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.8 #1036
See https://builds.apache.org/job/sling-trunk-1.8/1036/changes
[jira] [Assigned] (SLING-4178) ValueMapDecorator.convertToArray will never return null (even if type conversion does not work)
[
https://issues.apache.org/jira/browse/SLING-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SLING-4178:
--
Assignee: Konrad Windszus
ValueMapDecorator.convertToArray will never return null (even if type
conversion does not work)
---
Key: SLING-4178
URL: https://issues.apache.org/jira/browse/SLING-4178
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: API 2.8.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: API 2.10.0
Currently the {{ValueMapDecorator}} will never return {{null}} in case type
conversion fails and an array type was requested.
This is neither the case if the underlying map did not contain multiple
values (and it was converted a single element array), nor if the underlying
array was of a different (incompatible) type.
For the first case a single element array with value null is returned, for
the second case an array is returned which only contains null values (as many
as original values).
I would propose the following change:
# if array was requested and underlying data is an array: return null instead
of array with null items if no item could be converted to the requested array
type.
# if array was requested and underlying data is an array: only return those
items which could be converted to the requested type (leave out the others)
# if array was requested and underlying data is not an array: return null if
value could not be converted to the requested array type.
This should still be in sync with the behaviour described in SLING-662.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Sling discovery.impl 1.1.2
+1 On Thu, Apr 23, 2015 at 6:24 AM, Stefan Egli stefane...@apache.org wrote: Hi, We solved 6 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329705/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1246 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 1246 /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. Cheers, Stefan
[jira] [Commented] (SLING-4658) ValueMapDecorator should support conversion from array to single value type
[
https://issues.apache.org/jira/browse/SLING-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511015#comment-14511015
]
Konrad Windszus commented on SLING-4658:
I committed an ignored test case in rev. 1675834.
ValueMapDecorator should support conversion from array to single value type
---
Key: SLING-4658
URL: https://issues.apache.org/jira/browse/SLING-4658
Project: Sling
Issue Type: Bug
Affects Versions: API 2.9.0
Reporter: Konrad Windszus
Similar to what is described in SLING-662 {{ValueMapDecorator}} should
support conversions from multivalue to singlevalue and vice-versa. Currently
it does not support retrieving a single value element from an underlying
array (neither with nor without type conversion).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4178) ValueMapDecorator.convertToArray will never return null (even if type conversion does not work)
[
https://issues.apache.org/jira/browse/SLING-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510997#comment-14510997
]
Konrad Windszus commented on SLING-4178:
I committed this in rev. 1675829 together with some test cases.
[~cziegeler] Can you have a look?
ValueMapDecorator.convertToArray will never return null (even if type
conversion does not work)
---
Key: SLING-4178
URL: https://issues.apache.org/jira/browse/SLING-4178
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: API 2.8.0
Reporter: Konrad Windszus
Currently the {{ValueMapDecorator}} will never return {{null}} in case type
conversion fails and an array type was requested.
This is neither the case if the underlying map did not contain multiple
values (and it was converted a single element array), nor if the underlying
array was of a different (incompatible) type.
For the first case a single element array with value null is returned, for
the second case an array is returned which only contains null values (as many
as original values).
I would propose the following change:
# if array was requested and underlying data is an array: return null instead
of array with null items if no item could be converted to the requested array
type.
# if array was requested and underlying data is an array: only return those
items which could be converted to the requested type (leave out the others)
# if array was requested and underlying data is not an array: return null if
value could not be converted to the requested array type.
This should still be in sync with the behaviour described in SLING-662.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4658) ValueMapDecorator should support conversion from array to single value type
Konrad Windszus created SLING-4658:
--
Summary: ValueMapDecorator should support conversion from array to
single value type
Key: SLING-4658
URL: https://issues.apache.org/jira/browse/SLING-4658
Project: Sling
Issue Type: Bug
Affects Versions: API 2.9.0
Reporter: Konrad Windszus
Similar to what is described in SLING-662 {{ValueMapDecorator}} should support
conversions from multivalue to singlevalue and vice-versa. Currently it does
not support retrieving a single value element from an underlying array (neither
with nor without type conversion).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.7 #1751
See https://builds.apache.org/job/sling-trunk-1.7/1751/changes
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: (was: SLING-4568_skip-underlying.patch)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_skip-underlying.patch
[~cziegeler], I have attached the same patch again, but this time created with
git instead of my IDE.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.8 #1037
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Resolved] (SLING-2387) OBR at http://sling.apache.org/obr/repository.xml is totally out of date
[ https://issues.apache.org/jira/browse/SLING-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-2387. Resolution: Fixed Fixed in https://svn.apache.org/r1675867 OBR at http://sling.apache.org/obr/repository.xml is totally out of date Key: SLING-2387 URL: https://issues.apache.org/jira/browse/SLING-2387 Project: Sling Issue Type: Bug Reporter: Markus Joschko Assignee: Robert Munteanu Priority: Minor Attachments: screenshot-1.png It would be quite handy to have the most recent stable bundles of sling available in a bundle repository so that existing installations can easily be updated. However the versions in the existing obr are out of date (way out of date). If there is a way to automate the deployment I might be able to give a hand. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3307) Updated launchpad bundle list is not reflected after upgrade
[ https://issues.apache.org/jira/browse/SLING-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3307: Assignee: (was: Carsten Ziegeler) Updated launchpad bundle list is not reflected after upgrade Key: SLING-3307 URL: https://issues.apache.org/jira/browse/SLING-3307 Project: Sling Issue Type: Bug Components: Launchpad Affects Versions: Launchpad Installer 1.2.2 Reporter: Robert Munteanu Attachments: SLING-3307-repro.zip This is a follow-up bug report for http://markmail.org/thread/6us2jyrkcz6wjwxr . I've run into a bug when trying to update an existing Sling launchad to add a new bundle. The steps I've taken were: * Create a launchpad ( using the maven-launchpad-plugin ) and executed the jar file * Updated the bundle list to include a new bundle and executed the jar file on top of the existing launchpad directory The end result was that the new bundle was not deployed. Digging in the code a bit, I've noticed that the upgrade goes well if I force the startup mode to update. The sling/conf/launchpad_timestamp.txt exists and is valid. It seems that the StartupManager.getSelfTimeStamp() method does not get the correct timestamp: * looks for the last-modified date of the jar loading StartupManager.class - org.apache.sling.launchpad.base.jar * looks for the last-modified date of the jar loading LaunchpadContentProvider.class - still org.apache.sling.launchpad.base.jar * looks for the last-modified date of all the bundles from sling/startup folder The problem is that at this point, the new/modified bundles are not present in the sling/startup folder, so they are not taken into account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.7 #1752
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Resolved] (SLING-4178) ValueMapDecorator.convertToArray will never return null (even if type conversion does not work)
[
https://issues.apache.org/jira/browse/SLING-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-4178.
Resolution: Fixed
ValueMapDecorator.convertToArray will never return null (even if type
conversion does not work)
---
Key: SLING-4178
URL: https://issues.apache.org/jira/browse/SLING-4178
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: API 2.8.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: API 2.10.0
Currently the {{ValueMapDecorator}} will never return {{null}} in case type
conversion fails and an array type was requested.
This is neither the case if the underlying map did not contain multiple
values (and it was converted a single element array), nor if the underlying
array was of a different (incompatible) type.
For the first case a single element array with value null is returned, for
the second case an array is returned which only contains null values (as many
as original values).
I would propose the following change:
# if array was requested and underlying data is an array: return null instead
of array with null items if no item could be converted to the requested array
type.
# if array was requested and underlying data is an array: only return those
items which could be converted to the requested type (leave out the others)
# if array was requested and underlying data is not an array: return null if
value could not be converted to the requested array type.
This should still be in sync with the behaviour described in SLING-662.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-trunk-1.8 #1038
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: Exporting ServletResolverConstants in org.apache.sling.servlets.resolver
Hi Dirk, that class only contains constants. If you reference those constants within your own bundle they are usually inlined (i.e. there is no run-time dependency to the providing package). Therefore it is totally fine to add that dependency to your Maven module and to directly use those constants in your code. In the end though (i.e. during run-time) there is no longer a dependency (http://blog.bjhargrave.com/2014/04/java-8-bnd-and-references-to-compile.html, http://www.javaspecialists.eu/archive/Issue114.html). Therefore I don’t think there is a need to move this package somewhere else, although the package name org.apache.sling.servlets.resolver.internal might be confusing. Cheers, Konrad Am 24.04.2015 um 10:09 schrieb Dirk Rudolph dirk.rudo...@netcentric.biz: Hi devs, why is the class ServletResolverConstants in the Apache Sling Servlet Resolver not accessible in an exported package? I’m currently implementing a SCR component that registers multiple Services based on some configurations shared between them. One of this Services implements javax.servlet.Servlet as a Sling Servlet. Now I was wondering why those constants are not exported, because I think it can be a quite common use case to register services not using SCR (especially the @SlingServlet annotation). Cheers, Dirk Rudolph | Senior Software Engineer Netcentric AG M: +41 79 642 37 11 D: +49 174 966 84 34 dirk.rudo...@netcentric.biz | www.netcentric.biz
[jira] [Comment Edited] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14512206#comment-14512206
]
Timothee Maret edited comment on SLING-4627 at 4/25/15 2:47 AM:
Yes, I believe we could provide better tooling for figuring out the diff in
topology views.
That would be backward compatible and would allow to process diffs outside of
the scope of receiving an events.
I have added a patch (SLING-4627.patch) which contains a potential version for
it.
It would be some sort of builder that can takes either a TopologyEvent or a set
of TopologyViews and allows to first partition the changes (added, removed,
retained) and then apply further filtering on the partition (the most likely
are by default, custom filtering leverage the InstanceFilter interface).
The patch has no test, and likely is buggy (I haven't tried it..) but it is
good enough for the approach. Assuming we add this, then I believe this issue
could be solved without SPI and leaving each topology listener to figure out
what to do with topology changes.
For instance they could do
{code}
TopologyEvent event = ...;
// Leader instances that have been removed and are in the local cluster
ClusterView localView =
event.getOldView().getLocalInstance().getClusterView();
SetString slingIds = new TopologyViewChange(event)
.removed()
.isLeader()
.isInClusterView(localView)
.get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader, non local instances, from any cluster view, that match
some custom properties and have been added
TopologyView v1 = ...;
TopologyView v2 = ...;
InstanceFilter customFilter = new InstanceFilter() {
public boolean accept(InstanceDescription instance) {
return instance.getProperties().containsKey(my-property);
}
};
SetString slingIds = new TopologyViewChange(v1, v2)
.added()
.isNotLeader()
.isNotLocal()
.filterWith(customFilter).get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader instances that have been retained in a specific cluster
view
ClusterView specificView = ...;
SetString slingIds = new TopologyViewChange(v1, v2)
.retained(true)
.isInClusterView(specificView)
.get();
if (slingIds.size() 0) {
// do something ...
}
// Leader instances which properties have changed in any cluster view
SetString slingIds = new TopologyViewChange(v1, v2)
.retained(true, true)
.get();
if (slingIds.size() 0) {
// do something ...
}
{code}
was (Author: marett):
Yes, I believe we could provide better tooling for figuring out the diff in
topology views. I have added a patch (SLING-4627.patch) which contains a
potential version for it.
It would be some sort of builder that can takes either a TopologyEvent or a set
of TopologyViews and allows to first partition the changes (added, removed,
retained) and then apply further filtering on the partition (the most likely
are by default, custom filtering leverage the InstanceFilter interface).
The patch has no test, and likely is buggy (I haven't tried it..) but it is
good enough for the approach. Assuming we add this, then I believe this issue
could be solved without SPI and leaving each topology listener to figure out
what to do with topology changes.
For instance they could do
{code}
TopologyEvent event = ...;
// Leader instances that have been removed and are in the local cluster
ClusterView localView =
event.getOldView().getLocalInstance().getClusterView();
SetString slingIds = new TopologyViewChange(event)
.removed()
.isLeader()
.isInClusterView(localView)
.get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader, non local instances, from any cluster view, that match
some custom properties and have been added
TopologyView v1 = ...;
TopologyView v2 = ...;
InstanceFilter customFilter = new InstanceFilter() {
public boolean accept(InstanceDescription instance) {
return instance.getProperties().containsKey(my-property);
}
};
SetString slingIds = new TopologyViewChange(v1, v2)
.added()
.isNotLeader()
.isNotLocal()
.filterWith(customFilter).get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader instances
[jira] [Updated] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-4627:
--
Attachment: SLING-4627.patch
TOPOLOGY_CHANGED in an eventually consistent repository
---
Key: SLING-4627
URL: https://issues.apache.org/jira/browse/SLING-4627
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Egli
Priority: Critical
Attachments: SLING-4627.patch
This is a parent ticket describing the +coordination effort needed between
properly sending TOPOLOGY_CHANGED when running ontop of an eventually
consistent repository+. These findings are independent of the implementation
details used inside the discovery implementation, so apply to discovery.impl,
discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific
implementation are best created separately (eg sub-task or related..). Also
note that this assumes immediately sending TOPOLOGY_CHANGING as described [in
SLING-3432|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
h5. The spectrum of possible TOPOLOGY_CHANGED events include the following
scenarios:
|| scenario || classification || action ||
| A. change is completely outside of local cluster | (/) uncritical | changes
outside the cluster are considered uncritical for this exercise. |
| B. a new instance joins the local cluster, this new instance is by contract
not the leader (leader must be stable \[0\]) | (/) uncritical | a join of an
instance is uncritical due to the fact that it merely joins the cluster and
has thus no 'backlog' of changes that might be propagating through the
(eventually consistent) repository. |
| C. a non-leader *leaves* the local cluster | (x) *critical* | changes that
were written by the leaving instance might still not be *seen* by all
surviving (ie it can be that discovery is faster than the repository) and
this must be assured before sending out TOPOLOGY_CHANGED. This is because the
leaving instance could have written changes that are *topology dependent* and
thus those changes must first be settled in the repository before continuing
with a *new topology*. |
| D. the leader *leaves* the local cluster (and thus a new leader is elected)
| (x)(x) *very critical* | same as C except that this is more critical due to
the fact that the leader left |
| E. -the leader of the local cluster changes (without leaving)- this is not
supported by contract (leader must be stable \[0\]) | (/) -irrelevant- | |
So both C and D are about an instance leaving. And as mentioned above the
survivors must assure they have read all changes of the leavers. There are
two parts to this:
* the leaver could have pending writes that are not yet in mongoD: I don't
think this is the case. The only thing that can remain could be an
uncommitted branch and that would be rolled back afaik.
** Exception to this is a partition: where the leaver didn't actually crash
but is still hooked to the repository. *For this I'm not sure how it can be
solved* yet.
* the survivers could however not yet have read all changes (pending in the
background read) and one way to make sure they did is to have each surviving
instance write a (pseudo-) sync token to the repository. Once all survivors
have seen this sync token of all other survivors, the assumption is that all
pending changes are flushed through the eventually consistent repository
and that it is safe to send out a TOPOLOGY_CHANGED event.
* this sync token must be *conflict free* and could be eg:
{{/var/discovery/oak/clusterInstances/slingId/syncTokens/newViewId}} -
where {{newViewId}} is defined by whatever discovery mechanism is used
* a special case is when only one instance is remaining. It can then not wait
for any other survivor to send a sync token. In that case sync tokens would
not work. All it could then possibly do is to wait for a certain time (which
should be larger than any expected background-read duration)
[~mreutegg], [~chetanm] can you pls confirm/comment on the above flush/sync
token approach? Thx!
/cc [~marett]
\[0\] - see [getLeader() in
ClusterView|https://github.com/apache/sling/blob/trunk/bundles/extensions/discovery/api/src/main/java/org/apache/sling/discovery/ClusterView.java]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository
[
https://issues.apache.org/jira/browse/SLING-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14512206#comment-14512206
]
Timothee Maret commented on SLING-4627:
---
Yes, I believe we could provide better tooling for figuring out the diff in
topology views. I have added a patch (SLING-4627.patch) which contains a
potential version for it.
It would be some sort of builder that can takes either a TopologyEvent or a set
of TopologyViews and allows to first partition the changes (added, removed,
retained) and then apply further filtering on the partition (the most likely
are by default, custom filtering leverage the InstanceFilter interface).
The patch has no test, and likely is buggy (I haven't tried it..) but it is
good enough for the approach. Assuming we add this, then I believe this issue
could be solved without SPI and leaving each topology listener to figure out
what to do with topology changes.
For instance they could do
{code}
TopologyEvent event = ...;
// Leader instances that have been removed and are in the local cluster
ClusterView localView =
event.getOldView().getLocalInstance().getClusterView();
SetString slingIds = new TopologyViewChange(event)
.removed()
.isLeader()
.isInClusterView(localView)
.get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader, non local instances, from any cluster view, that match
some custom properties and have been added
TopologyView v1 = ...;
TopologyView v2 = ...;
InstanceFilter customFilter = new InstanceFilter() {
public boolean accept(InstanceDescription instance) {
return instance.getProperties().containsKey(my-property);
}
};
SetString slingIds = new TopologyViewChange(v1, v2)
.added()
.isNotLeader()
.isNotLocal()
.filterWith(customFilter).get();
if (slingIds.size() 0) {
// do something ...
}
// Non leader instances that have been retained in a specific cluster
view
ClusterView specificView = ...;
SetString slingIds = new TopologyViewChange(v1, v2)
.retained(true)
.isInClusterView(specificView)
.get();
if (slingIds.size() 0) {
// do something ...
}
// Leader instances which properties have changed in any cluster view
SetString slingIds = new TopologyViewChange(v1, v2)
.retained(true, true)
.get();
if (slingIds.size() 0) {
// do something ...
}
{code}
TOPOLOGY_CHANGED in an eventually consistent repository
---
Key: SLING-4627
URL: https://issues.apache.org/jira/browse/SLING-4627
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Egli
Priority: Critical
Attachments: SLING-4627.patch
This is a parent ticket describing the +coordination effort needed between
properly sending TOPOLOGY_CHANGED when running ontop of an eventually
consistent repository+. These findings are independent of the implementation
details used inside the discovery implementation, so apply to discovery.impl,
discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific
implementation are best created separately (eg sub-task or related..). Also
note that this assumes immediately sending TOPOLOGY_CHANGING as described [in
SLING-3432|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
h5. The spectrum of possible TOPOLOGY_CHANGED events include the following
scenarios:
|| scenario || classification || action ||
| A. change is completely outside of local cluster | (/) uncritical | changes
outside the cluster are considered uncritical for this exercise. |
| B. a new instance joins the local cluster, this new instance is by contract
not the leader (leader must be stable \[0\]) | (/) uncritical | a join of an
instance is uncritical due to the fact that it merely joins the cluster and
has thus no 'backlog' of changes that might be propagating through the
(eventually consistent) repository. |
| C. a non-leader *leaves* the local cluster | (x) *critical* | changes that
were written by the leaving instance might still not be *seen* by all
surviving (ie it can be that discovery is faster than the repository) and
this must be assured before sending out TOPOLOGY_CHANGED. This is because the
leaving instance could have written changes that are *topology dependent* and
Jenkins build is still unstable: sling-contrib-1.7 #26
See https://builds.apache.org/job/sling-contrib-1.7/changes
Jenkins build is still unstable: sling-trunk-1.7 #1753
See https://builds.apache.org/job/sling-trunk-1.7/changes
Jenkins build is still unstable: sling-trunk-1.8 #1039
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Commented] (SLING-4178) ValueMapDecorator.convertToArray will never return null (even if type conversion does not work)
[
https://issues.apache.org/jira/browse/SLING-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511143#comment-14511143
]
Carsten Ziegeler commented on SLING-4178:
-
[~kwin] lgtm, thanks
ValueMapDecorator.convertToArray will never return null (even if type
conversion does not work)
---
Key: SLING-4178
URL: https://issues.apache.org/jira/browse/SLING-4178
Project: Sling
Issue Type: Bug
Components: API
Affects Versions: API 2.8.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: API 2.10.0
Currently the {{ValueMapDecorator}} will never return {{null}} in case type
conversion fails and an array type was requested.
This is neither the case if the underlying map did not contain multiple
values (and it was converted a single element array), nor if the underlying
array was of a different (incompatible) type.
For the first case a single element array with value null is returned, for
the second case an array is returned which only contains null values (as many
as original values).
I would propose the following change:
# if array was requested and underlying data is an array: return null instead
of array with null items if no item could be converted to the requested array
type.
# if array was requested and underlying data is an array: only return those
items which could be converted to the requested type (leave out the others)
# if array was requested and underlying data is not an array: return null if
value could not be converted to the requested array type.
This should still be in sync with the behaviour described in SLING-662.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Simplified bundle deployment on OBR
Hi, I just checking in a shell script at tooling/releases/sync_obr_with_dist.sh [1] that can be used to update the sling.xml OBR file when releasing bundles. It takes two inputs ( optionally from a config file in a well-known location): - the dist directory where bundles are located - the site directory where the sling.xml OBR file is located I just used it to re-populate sling.xml as it was missing a lot of bundles ( see [2] ) so it works, at least for me. Since it's a shell script I'd like to ask the next release managers to take it for a spin and report any issues. It works for me with Bash 4.3 + the GNU toolchain on Linux, but I'm pretty bad at writing portable scripts :-) Once I get a confirmation that it works for others I'll update to documents to reference it. Cheers, Robert [1]:http://svn.apache.org/repos/asf/sling/trunk/tooling/release/sync_obr_with_dist.sh [2]: https://issues.apache.org/jira/browse/SLING-2387
Jenkins build is back to stable : sling-trunk-1.8 #1032
See https://builds.apache.org/job/sling-trunk-1.8/1032/changes
Build failed in Jenkins: sling-trunk-1.7 #1746
See https://builds.apache.org/job/sling-trunk-1.7/1746/changes Changes: [cziegeler] Use released testing tools 1.0.10 -- [...truncated 53478 lines...] [INFO] Apache Sling Repository API Bundle SUCCESS [4.692s] [INFO] Apache Sling Testing JCR Mock . SUCCESS [6.624s] [INFO] Apache Sling JCR Base Bundle .. SUCCESS [9.476s] [INFO] Apache Sling JCR ClassLoader .. SUCCESS [5.685s] [INFO] Apache Sling Initial Content Loader ... SUCCESS [13.230s] [INFO] Apache Sling Jackrabbit Embedded Repository ... SUCCESS [22.337s] [INFO] Apache Sling Jackrabbit UserManager Support ... SUCCESS [9.769s] [INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support SUCCESS [4.865s] [INFO] Apache Sling Wrapper Bundle for the JCR API ... SUCCESS [4.389s] [INFO] Apache Sling JCR Resource Resolver SUCCESS [50.890s] [INFO] Apache Sling Testing Sling Mock Jackrabbit-based Resource Resolver SUCCESS [29.829s] [INFO] Apache Sling Versioning Integration Tests . SUCCESS [13.414s] [INFO] Apache Sling JCR Repository Registration .. SUCCESS [16.612s] [INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [10.062s] [INFO] Apache Sling DavEx Access to repositories . SUCCESS [10.020s] [INFO] Apache Sling JCR WebConsole Bundle SUCCESS [5.131s] [INFO] Apache Sling Oak Repository Server SUCCESS [13.067s] [INFO] Apache Sling SlingRepository Integration Tests SUCCESS [1:03.413s] [INFO] Apache Sling Servlet Resolver . SUCCESS [7.806s] [INFO] Apache Sling Default GET Servlets . SUCCESS [7.640s] [INFO] Apache Sling Default POST Servlets SUCCESS [8.734s] [INFO] Apache Sling Compat Servlets .. SUCCESS [10.290s] [INFO] Apache Sling Scripting Implementation API . SUCCESS [7.597s] [INFO] Apache Sling Scripting Core implementation SUCCESS [17.053s] [INFO] Apache Sling Scripting JavaScript Support . SUCCESS [20.284s] [INFO] Apache Sling Scripting JSP Support SUCCESS [10.503s] [INFO] Apache Sling JSP Tag Library .. SUCCESS [10.209s] [INFO] Apache Sling JSP Standard Tag Library . SUCCESS [11.127s] [INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [6.024s] [INFO] Apache Sling Bundle Resource Provider . SUCCESS [5.008s] [INFO] Apache Sling Distributed Event Admin .. SUCCESS [4.749s] [INFO] Apache Sling Discovery API SUCCESS [4.653s] [INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [4:24.839s] [INFO] Apache Sling Discovery Support Bundle . SUCCESS [5.438s] [INFO] Apache Sling Discovery Standalone Implementation .. SUCCESS [5.254s] [INFO] Apache Sling Event Support SUCCESS [11:28.704s] [INFO] Apache Sling Feature Flags SUCCESS [4.647s] [INFO] Apache Sling Filesystem Resource Provider . SUCCESS [4.255s] [INFO] Apache Sling javax.activation bundle .. SUCCESS [4.088s] [INFO] Apache Sling Service User Mapper .. SUCCESS [6.258s] [INFO] Apache Sling Settings . SUCCESS [4.441s] [INFO] Apache Sling Web Console Branding . SUCCESS [3.865s] [INFO] Apache Sling Web Console Security Provider SUCCESS [6.327s] [INFO] Apache Sling Explorer . SUCCESS [5.018s] [INFO] Apache Sling Health Check Core SUCCESS [9.117s] [INFO] Apache Sling Health Check Annotations . SUCCESS [5.114s] [INFO] Apache Sling Health Check Samples . SUCCESS [5.191s] [INFO] Apache Sling Health Check Support Components .. SUCCESS [4.801s] [INFO] Apache Sling Health Check Webconsole Plugin ... SUCCESS [3.485s] [INFO] Apache Sling Health Check JUnit Bridge SUCCESS [4.243s] [INFO] Apache Sling Health Check Integration Tests ... SUCCESS [27.608s] [INFO] Apache Sling Health Check Reactor POM . SUCCESS [2.830s] [INFO] Apache Sling Resource Access Security . SUCCESS [4.955s] [INFO] Apache Sling Resource Access Security Integration Tests SUCCESS [28.194s] [INFO] Apache Sling Validation Framework API . SUCCESS [4.409s] [INFO] Apache Sling Validation Framework Core Implementation SUCCESS [12.686s] [INFO] Apache Sling Validation Framework Testing Services SUCCESS [4.357s] [INFO] Apache Sling Validation Framework Integration Tests SUCCESS [23.185s] [INFO] Apache Sling Validation Framework Examples SUCCESS [9.153s] [INFO] Apache Sling Validation Framework Builder . SUCCESS [1.843s] [INFO] Apache Sling Models API ... SUCCESS [3.559s] [INFO] Apache Sling Models Implementation SUCCESS [6.738s] [INFO] Apache Sling
[jira] [Created] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
Felix Meschberger created SLING-4655: Summary: Servlet Resolver does not use registered servlet's service.ranking property Key: SLING-4655 URL: https://issues.apache.org/jira/browse/SLING-4655 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.3.6 Reporter: Felix Meschberger The Servlet Resolver registers a ResourceProvider for each Servlet service registered and handled by the ServletResolver, that is, those with a Sling servlet registration property. As the ResourceResolver supports ranking of ResourceProviders with the same root path, the ServletResolver should really register ResourceProvider services for servlets including the servlet service's service ranking property, if available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE RESULT] Release Apache Sling Testing Tools 1.0.10
The vote passed with three binding +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-4656) ProviderHandler implements compareTo incorreclty
Felix Meschberger created SLING-4656: Summary: ProviderHandler implements compareTo incorreclty Key: SLING-4656 URL: https://issues.apache.org/jira/browse/SLING-4656 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Felix Meschberger The implementation of the ResourceResolver's compareTo method is wrong as it favors services registered later over services registered earlier, while older services should actually be preferred (assuming there sevice.ranking values are equal). While at it, the extraction of the service.ranking property is overly complex since it first checks for null and then for the correct type. This can be simplified by just checking for the correct type as a null value never matches any type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[
https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510524#comment-14510524
]
Felix Meschberger commented on SLING-4655:
--
Simple patch:
{noformat}
Index:
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
===
---
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
(Revision 1675785)
+++
src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java
(Arbeitskopie)
@@ -1000,6 +1000,12 @@
params.put(Constants.SERVICE_DESCRIPTION, ServletResourceProvider for
Servlets at
+ Arrays.asList(provider.getServletPaths()));
+// inherit service ranking
+Object rank = reference.getProperty(Constants.SERVICE_RANKING);
+if (rank instanceof Integer) {
+params.put(Constants.SERVICE_RANKING, rank);
+}
+
final ServiceRegistration reg = context.getBundleContext()
.registerService(ResourceProvider.SERVICE_NAME, provider,
params);
{noformat}
Servlet Resolver does not use registered servlet's service.ranking property
---
Key: SLING-4655
URL: https://issues.apache.org/jira/browse/SLING-4655
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Resolver 2.3.6
Reporter: Felix Meschberger
The Servlet Resolver registers a ResourceProvider for each Servlet service
registered and handled by the ServletResolver, that is, those with a Sling
servlet registration property.
As the ResourceResolver supports ranking of ResourceProviders with the same
root path, the ServletResolver should really register ResourceProvider
services for servlets including the servlet service's service ranking
property, if available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4655) Servlet Resolver does not use registered servlet's service.ranking property
[ https://issues.apache.org/jira/browse/SLING-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510531#comment-14510531 ] Carsten Ziegeler commented on SLING-4655: - lgtm Servlet Resolver does not use registered servlet's service.ranking property --- Key: SLING-4655 URL: https://issues.apache.org/jira/browse/SLING-4655 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.3.6 Reporter: Felix Meschberger The Servlet Resolver registers a ResourceProvider for each Servlet service registered and handled by the ServletResolver, that is, those with a Sling servlet registration property. As the ResourceResolver supports ranking of ResourceProviders with the same root path, the ServletResolver should really register ResourceProvider services for servlets including the servlet service's service ranking property, if available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4501) JarExecutor: new option to specify the JVM binary path
[ https://issues.apache.org/jira/browse/SLING-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4501. --- JarExecutor: new option to specify the JVM binary path -- Key: SLING-4501 URL: https://issues.apache.org/jira/browse/SLING-4501 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: org.apache.sling.testing.tools 1.0.8 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: org.apache.sling.testing.tools 1.0.10 Currently the testing tool's JarExecutor finds the path of the jvm to execute based on the java.home system property, so it's limited to using the same JVM that executes it. I'll add an option to use a specific JVM, by providing its path in a configuration property. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4249) Testing Tools: Refresh Packages should be called after installing or uninstalling bundles
[ https://issues.apache.org/jira/browse/SLING-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4249. --- Testing Tools: Refresh Packages should be called after installing or uninstalling bundles - Key: SLING-4249 URL: https://issues.apache.org/jira/browse/SLING-4249 Project: Sling Issue Type: Bug Components: Testing Affects Versions: org.apache.sling.testing.tools 1.0.8 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: org.apache.sling.testing.tools 1.0.10 for integration tests additional bundles can be installed using the WebconsoleClient in sling testing tools project. if bundles already exists they are uninstalled before new bundles are installed. but in this case it may happen that depending are still wired to the old uninstalled bundle. thus always a refreshPackages command should be called when all bundles are installed/uninstalled. see also http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#when-i-update-my-bundle-why-are-my-bundles-old-classes-still-being-used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4278) Add package info file to testing tools
[
https://issues.apache.org/jira/browse/SLING-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4278.
---
Add package info file to testing tools
--
Key: SLING-4278
URL: https://issues.apache.org/jira/browse/SLING-4278
Project: Sling
Issue Type: Task
Components: Testing
Affects Versions: org.apache.sling.testing.tools 1.0.8
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: org.apache.sling.testing.tools 1.0.10
Currently building the testing/tools module generates following warning
{noformat}
[WARNING] org.apache.sling.testing.tools.http: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.http: Version has been increased but
analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.jarexec: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.jarexec: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.junit: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.junit: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.retry: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.retry: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.serversetup: Excessive version
increase; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.serversetup: Version has been
increased but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.sling: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.sling: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
{noformat}
This is due to package export version being set to module version. Instead
version should be provided explicitly via package-info files
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-3813) Pax-Exam tests fail when executed under Java 8
[
https://issues.apache.org/jira/browse/SLING-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-3813.
---
Pax-Exam tests fail when executed under Java 8
--
Key: SLING-3813
URL: https://issues.apache.org/jira/browse/SLING-3813
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: org.apache.sling.testing.tools 1.0.8
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: org.apache.sling.testing.tools 1.0.10
The version of pax-exam in use probably doesn't use a version of the Felix
framework with Java 8 support. An example of the errors which pop up is
{code}ERROR: Bundle org.ops4j.pax.exam [1] Error starting
link:classpath:META-INF/links/org.ops4j.pax.exam.link
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.exam [1]: Unable to resolve 1.0: missing requirement [1.0]
package; ((package=org.ops4j.io)(version=1.4.0)(!(version=2.0.0))) [caused
by: Unable to resolve 6.0: missing requirement [6.0] package;
(package=javax.net.ssl)])
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.exam [1]: Unable to resolve 1.0: missing requirement [1.0]
package; ((package=org.ops4j.io)(version=1.4.0)(!(version=2.0.0))) [caused
by: Unable to resolve 6.0: missing requirement [6.0] package;
(package=javax.net.ssl)]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3564)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1797)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
at java.lang.Thread.run(Thread.java:745){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-3819) SlingTestBase.blockIfRequested always throws IllegalMonitorStateException
[
https://issues.apache.org/jira/browse/SLING-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-3819.
---
SlingTestBase.blockIfRequested always throws IllegalMonitorStateException
-
Key: SLING-3819
URL: https://issues.apache.org/jira/browse/SLING-3819
Project: Sling
Issue Type: Bug
Components: Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: org.apache.sling.testing.tools 1.0.10
The synchronized block is waiting on the {{this}} object, while locking on
the {{slingTestState}} object. The trivial fix is to call wait on the locked
{{slingTestState}} object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4567) Add synchronous execution option to JarExecutor
[ https://issues.apache.org/jira/browse/SLING-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4567. --- Add synchronous execution option to JarExecutor --- Key: SLING-4567 URL: https://issues.apache.org/jira/browse/SLING-4567 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: org.apache.sling.testing.tools 1.0.8 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: org.apache.sling.testing.tools 1.0.10 The JarExecutor's start() method should have an option to wait for the process that it executes, and check the process' exit status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
