RE: [VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
+1
[VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
Hi, Testing OSGi Mock 2.4.10 (2 issues) https://issues.apache.org/jira/browse/SLING/fixforversion/12345150 Testing Sling Mock 2.3.16 (2 issues) https://issues.apache.org/jira/browse/SLING/fixforversion/12345688 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2111/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2111 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. stefan
RE: [VOTE] Release Apache Sling distribution.journal.messages 0.1.2, distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
there is a problem in the journal.messages git repo [1]:
the 2nd commit of the release plugin ("prepare for next development iteration")
seems to be missing.
stefan
[1]
https://github.com/apache/sling-org-apache-sling-distribution-journal-messages/commits/master
>-Original Message-
>From: Christian Schneider [mailto:ch...@die-schneider.net]
>Sent: Tuesday, August 6, 2019 2:49 PM
>To: Sling dev List
>Subject: [VOTE] Release Apache Sling distribution.journal.messages 0.1.2,
>distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
>
>Hi,
>this is a release of the 3 journal distribution bundles.
>
>org.apache.sling.distribution.journal.messages-0.1.2
>https://issues.apache.org/jira/projects/SLING/versions/12345418
>
>org.apache.sling.distribution.journal-0.1.4
>https://issues.apache.org/jira/projects/SLING/versions/12345620
>
>org.apache.sling.distribution.journal.kafka-0.1.4
>https://issues.apache.org/jira/projects/SLING/versions/12345619
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-2110
>
>You can use this UNIX script to download the release and verify the
>signatures:
>https://gitbox.apache.org/repos/asf?p=sling-tooling-
>release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>
>Usage:
>sh check_staged_release.sh orgapachesling-2110 /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.
>
>-- -
>Christian Schneider
>http://www.liquid-reality.de
>
>Computer Scientist
>http://www.adobe.com
[jira] [Updated] (SLING-7284) Extend OsgiServiceUtil#invokeBindUnbindMethod to support more DS 1.3+ method signatures
[
https://issues.apache.org/jira/browse/SLING-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-7284:
--
Fix Version/s: (was: Testing OSGi Mock 2.4.10)
Testing OSGi Mock 2.4.12
> Extend OsgiServiceUtil#invokeBindUnbindMethod to support more DS 1.3+ method
> signatures
> ---
>
> Key: SLING-7284
> URL: https://issues.apache.org/jira/browse/SLING-7284
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 1.0.0
>Reporter: Radu Cotescu
>Priority: Major
> Fix For: Testing OSGi Mock 2.4.12
>
>
> The
> {{org.apache.sling.testing.mock.osgi.OsgiServiceUtil#invokeBindUnbindMethod}}
> should be extended to support more DS 1.3+ method signatures.
> For more details check
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/scr/src/main/java/org/apache/felix/scr/impl/inject/BindMethod.java#L86.
> The complete DS 1.4 spec related to this can be found at
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-method.injection.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
Re: [VOTE] Release Apache Sling distribution.journal.messages 0.1.2, distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
+1 (non-binding) - Andy P.S.: there script in usage seems to be wrong. This worked for me: sh check_staged_release.sh 2110 /tmp/sling-staging > On Aug 6, 2019, at 5:49 AM, Christian Schneider > wrote: > > Hi, > this is a release of the 3 journal distribution bundles. > > org.apache.sling.distribution.journal.messages-0.1.2 > https://issues.apache.org/jira/projects/SLING/versions/12345418 > > org.apache.sling.distribution.journal-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345620 > > org.apache.sling.distribution.journal.kafka-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345619 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2110 > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh orgapachesling-2110 /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. > > -- - > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com
Re: [VOTE] Release Apache Sling JCR Content Parser 1.2.8
+1 (non-binding) - Andy > On Aug 5, 2019, at 1:52 AM, Radu Cotescu wrote: > > Hi, > > We solved 1 issue in this release: > https://issues.apache.org/jira/browse/SLING/fixforversion/12343245 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2109/ > > You can use this UNIX script to download the release and verify the > signatures: > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2109 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards, > Radu Cotescu
[jira] [Comment Edited] (SLING-7927) JSON Content Loading errors out import on malformed json
[ https://issues.apache.org/jira/browse/SLING-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901344#comment-16901344 ] Eric Norman edited comment on SLING-7927 at 8/6/19 6:06 PM: [~jebailey] How would you anticipate dealing with dependencies between the JSON files? If loading a JSON file fails for some reason, how can you be sure the other JSON files do not depend on something loaded by the one that failed? For example, the failing file creates some users and then the other files try to assign permissions for those users? In other words, failing fast (and stopping the loading attempt) may be the safer approach for certain scenarios and attempting to load the other files could potentially be harmful and obscure the root reason for subsequent failures. was (Author: edn): [~jebailey] How would you anticipate dealing with dependencies between the JSON files? If loading a JSON file fails for some reason, how can you be sure the other JSON files do not depend on something loaded by the one that failed? For example, the failing file creates some users and then the other files try to assign permissions for those users? In other words, failing fast may be the safer approach for certain scenarios and attempting to load the other files could potentially be harmful and obscure the root reason for subsequent failures. > JSON Content Loading errors out import on malformed json > > > Key: SLING-7927 > URL: https://issues.apache.org/jira/browse/SLING-7927 > Project: Sling > Issue Type: Bug >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: JCR ContentLoader 2.3.2 > > > Current Behaviour: > During the importing of json content from a bundle. If one of the files > contains malformed json the load process is discontinued and exits. This > stops the loading of any other, correctly formatted, data. > > Expected Behaviour: > If a single file contains malformed content, that specific file should > discontinue, the error logged and then the process continues to import the > rest of the provided content. > As it is right now, it's possible to load the bundle and have the application > in an unworkable state. preventing the ability to trouble shoot and > investigate the root cause. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SLING-7927) JSON Content Loading errors out import on malformed json
[ https://issues.apache.org/jira/browse/SLING-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901344#comment-16901344 ] Eric Norman commented on SLING-7927: [~jebailey] How would you anticipate dealing with dependencies between the JSON files? If loading a JSON file fails for some reason, how can you be sure the other JSON files do not depend on something loaded by the one that failed? For example, the failing file creates some users and then the other files try to assign permissions for those users? In other words, failing fast may be the safer approach for certain scenarios and attempting to load the other files could potentially be harmful and obscure the root reason for subsequent failures. > JSON Content Loading errors out import on malformed json > > > Key: SLING-7927 > URL: https://issues.apache.org/jira/browse/SLING-7927 > Project: Sling > Issue Type: Bug >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: JCR ContentLoader 2.3.2 > > > Current Behaviour: > During the importing of json content from a bundle. If one of the files > contains malformed json the load process is discontinued and exits. This > stops the loading of any other, correctly formatted, data. > > Expected Behaviour: > If a single file contains malformed content, that specific file should > discontinue, the error logged and then the process continues to import the > rest of the provided content. > As it is right now, it's possible to load the bundle and have the application > in an unworkable state. preventing the ability to trouble shoot and > investigate the root cause. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SLING-7927) JSON Content Loading errors out import on malformed json
[ https://issues.apache.org/jira/browse/SLING-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901326#comment-16901326 ] Jason E Bailey commented on SLING-7927: --- This is definitely an issue with the Content Loader. Because this happened in AEM land. BTW the Content Loader does not use the Content Parser in the way that you would think. It embeds one or two specific files into the Content Loader bundle. > JSON Content Loading errors out import on malformed json > > > Key: SLING-7927 > URL: https://issues.apache.org/jira/browse/SLING-7927 > Project: Sling > Issue Type: Bug >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: JCR ContentLoader 2.3.2 > > > Current Behaviour: > During the importing of json content from a bundle. If one of the files > contains malformed json the load process is discontinued and exits. This > stops the loading of any other, correctly formatted, data. > > Expected Behaviour: > If a single file contains malformed content, that specific file should > discontinue, the error logged and then the process continues to import the > rest of the provided content. > As it is right now, it's possible to load the bundle and have the application > in an unworkable state. preventing the ability to trouble shoot and > investigate the root cause. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SLING-8592) Onboard content parser modules on SonarCloud
[ https://issues.apache.org/jira/browse/SLING-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901072#comment-16901072 ] Fabrice Bellingard commented on SLING-8592: --- Done [~radu.cotescu]! > Onboard content parser modules on SonarCloud > > > Key: SLING-8592 > URL: https://issues.apache.org/jira/browse/SLING-8592 > Project: Sling > Issue Type: Sub-task > Components: Content Parser >Reporter: Radu Cotescu >Priority: Major > > The following modules should be onboarded on SonarCloud: > # https://github.com/apache/sling-org-apache-sling-contentparser-api > # https://github.com/apache/sling-org-apache-sling-contentparser-json > # https://github.com/apache/sling-org-apache-sling-contentparser-xml > # https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr > # https://github.com/apache/sling-org-apache-sling-contentparser-testutils -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [VOTE] Release Apache Sling distribution.journal.messages 0.1.2, distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
+1 Regards, Timothee Le mar. 6 août 2019 à 14:49, Christian Schneider a écrit : > Hi, > this is a release of the 3 journal distribution bundles. > > org.apache.sling.distribution.journal.messages-0.1.2 > https://issues.apache.org/jira/projects/SLING/versions/12345418 > > org.apache.sling.distribution.journal-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345620 > > org.apache.sling.distribution.journal.kafka-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345619 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2110 > > You can use this UNIX script to download the release and verify the > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh orgapachesling-2110 /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. > > -- - > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com >
Re: [VOTE] Release Apache Sling distribution.journal.messages 0.1.2, distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
+1 On Tue, Aug 6, 2019 at 8:49 AM Christian Schneider wrote: > Hi, > this is a release of the 3 journal distribution bundles. > > org.apache.sling.distribution.journal.messages-0.1.2 > https://issues.apache.org/jira/projects/SLING/versions/12345418 > > org.apache.sling.distribution.journal-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345620 > > org.apache.sling.distribution.journal.kafka-0.1.4 > https://issues.apache.org/jira/projects/SLING/versions/12345619 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2110 > > You can use this UNIX script to download the release and verify the > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh orgapachesling-2110 /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. > > -- - > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com >
[jira] [Commented] (SLING-8616) Add basic extensibility model
[ https://issues.apache.org/jira/browse/SLING-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901044#comment-16901044 ] Robert Munteanu commented on SLING-8616: Syntax fix in [sling-org-apache-sling-starter-content commit 0d1e564|https://github.com/apache/sling-org-apache-sling-starter-content/commit/0d1e564] > Add basic extensibility model > - > > Key: SLING-8616 > URL: https://issues.apache.org/jira/browse/SLING-8616 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter Content 1.0.6 > > > It should be possible to extend the starter content with new links and > snippets. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (SLING-8616) Add basic extensibility model
[ https://issues.apache.org/jira/browse/SLING-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-8616. Resolution: Fixed Added the ability to add sidebar content in [sling-org-apache-sling-starter-content commit 449fd3b|https://github.com/apache/sling-org-apache-sling-starter-content/commit/449fd3b] > Add basic extensibility model > - > > Key: SLING-8616 > URL: https://issues.apache.org/jira/browse/SLING-8616 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter Content 1.0.6 > > > It should be possible to extend the starter content with new links and > snippets. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Release Validator Docker Image
Sorry for the slow turnaround on this. I updated to use OpenJDK and rejected the idea of running the integration tests as it makes the execution time extremely slow. Is this something we'd be interested in moving out of the Whiteboard? Unfortunately, it does have quite a different structure than the committer-cli due to being mostly bash scripts. On Mon, Jun 17, 2019 at 10:38 AM Robert Munteanu wrote: > On Thu, 2019-06-13 at 10:49 -0500, Daniel Klco wrote: > > Yeah, I've gone back and forth regarding the JDK RPM. On the one > > hand, it'd > > be better not not require the local RPM, on the other hand, to > > support > > validation it'd be good to be able (I would think) to compile against > > multiple JDK versions and VMs (e.g. Oracle, IBM, whatever) > > > > I guess it's a question to the overall team, is there any need to > > validate > > against OracleJDK or should I just base this off OpenDJK? > > I always used OpenJDK. > > Robert > > > > > On Thu, Jun 13, 2019 at 10:29 AM Robert Munteanu > > wrote: > > > > > Hi Dan, > > > > > > On Thu, 2019-06-13 at 10:20 -0500, Daniel Klco wrote: > > > > I've also been working on a docker image to validate and build > > > > releases: > > > > > > > > > https://github.com/apache/sling-whiteboard/tree/master/release-validator > > > > > > > > It's relatively easy to use > > > > > > That looks nice! One question - do you need to have the Java RPM > > > locally? If yes, have you considered using one of the OpenJDK > > > docker > > > images, which already do this for you? > > > > > > https://hub.docker.com/_/openjdk > > > > > > As a side note, I have some local scripts which do the following: > > > > > > - check the status of a release on Github > > > - builds a reactor of the whole > > > > > > I am a bit lazy but I'll attach them here, in case you want to pick > > > something up for the validator docker image feel free :-) > > > > > > Thanks, > > > > > > Robert > > > > >
[jira] [Created] (SLING-8617) GeneralAclTest: test session should be refreshed to reflect latest changes
angela created SLING-8617:
-
Summary: GeneralAclTest: test session should be refreshed to
reflect latest changes
Key: SLING-8617
URL: https://issues.apache.org/jira/browse/SLING-8617
Project: Sling
Issue Type: Bug
Components: Repoinit
Reporter: angela
the tests in {{GeneralAclTest}} obtain a session for the test-user in the
setup. the tests then make changes with an administrative session and
subsequently verify the result with the test session.
however, the tests never refresh the test-user session. that should is best
practice and usually required in an Oak repository. see
http://jackrabbit.apache.org/oak/docs/differences.html#Session_state_and_refresh_behaviour
for details.
reporting this as bug because it might be wrong in the test case due to a
misconception, which might cause bigger issues in the rest of the code base.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (SLING-8616) Add basic extensibility model
Robert Munteanu created SLING-8616: -- Summary: Add basic extensibility model Key: SLING-8616 URL: https://issues.apache.org/jira/browse/SLING-8616 Project: Sling Issue Type: Improvement Components: Starter Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Starter Content 1.0.6 It should be possible to extend the starter content with new links and snippets. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [DISCUSS] Switching o.a.s.starter-content to use scripts and resources?
On Tue, 2019-08-06 at 10:41 +0300, Robert Munteanu wrote: > On Mon, 2019-08-05 at 20:49 +0300, Robert Munteanu wrote: > > A quick check in the starter application shows that there at least > > the > > Felix HC bundle expects this file to be present (config snippet > > below) > > > > PID = > > org.apache.felix.hc.core.impl.filter.ServiceUnavailableFilter~start > > up > > andshutdown > > responseTextFor503 = > > classpath:org.apache.sling.starter.content:content/content/startup/ > > in > > dex.html > > Replying to myself here - the /content/startup/index.html file is > different from the /content/starter/index.html one, so no change is > required here. Filed and fixed https://issues.apache.org/jira/browse/SLING-8615 . Robert
[jira] [Resolved] (SLING-8615) Move to a resource-centric setup
[ https://issues.apache.org/jira/browse/SLING-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-8615. Resolution: Fixed Fixed with [sling-org-apache-sling-starter-content commit 9e2c3d7|https://github.com/apache/sling-org-apache-sling-starter-content/commit/9e2c3d7] > Move to a resource-centric setup > > > Key: SLING-8615 > URL: https://issues.apache.org/jira/browse/SLING-8615 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter Content 1.0.6 > > > As proposed on > https://lists.apache.org/thread.html/847538afdb43d82c7c4a2d59464897168ea1302a69c5b0863eddc360@%3Cdev.sling.apache.org%3E > , we should use the Sling way and base the starter-content bundle on scripts > and resources. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SLING-4075) Improve test coverage of SCD
[ https://issues.apache.org/jira/browse/SLING-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-4075: --- Fix Version/s: Content Distribution Core 0.4.2 > Improve test coverage of SCD > > > Key: SLING-4075 > URL: https://issues.apache.org/jira/browse/SLING-4075 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Tommaso Teofili >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Core 0.4.2 > > > Currently we moved lots of testing to the IT module but it'd be good to have > a better test coverage via unit testing in core module, at least to test > basic use cases and maybe some edge cases. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[VOTE] Release Apache Sling distribution.journal.messages 0.1.2, distribution.journal-0.1.4 and distribution.journal.kafka-0.1.4
Hi, this is a release of the 3 journal distribution bundles. org.apache.sling.distribution.journal.messages-0.1.2 https://issues.apache.org/jira/projects/SLING/versions/12345418 org.apache.sling.distribution.journal-0.1.4 https://issues.apache.org/jira/projects/SLING/versions/12345620 org.apache.sling.distribution.journal.kafka-0.1.4 https://issues.apache.org/jira/projects/SLING/versions/12345619 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2110 You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh orgapachesling-2110 /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. -- - Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
[jira] [Updated] (SLING-8446) assertTopic does not work with Azure Event Hubs
[ https://issues.apache.org/jira/browse/SLING-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-8446: --- Fix Version/s: (was: Content Distribution Journal Kafka 0.1.5) > assertTopic does not work with Azure Event Hubs > --- > > Key: SLING-8446 > URL: https://issues.apache.org/jira/browse/SLING-8446 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Kafka 0.1.0 >Reporter: Christian Schneider >Priority: Major > > There is one remaining issue with the Azure Event Hubs support. > The assetTopic method does not work correctly even if the topic exists. > During my evaluation of Event Hubs I was not able to dig more into it. So I > removed the assert code when did a demo. > For actual usage of Azure Event Hubs we either need a config to switch off > topic assertions or we need to solve how to check topics with event hubs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SLING-8446) assertTopic does not work with Azure Event Hubs
[ https://issues.apache.org/jira/browse/SLING-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-8446: --- Fix Version/s: (was: Content Distribution Journal Kafka 0.1.4) Content Distribution Journal Kafka 0.1.5 > assertTopic does not work with Azure Event Hubs > --- > > Key: SLING-8446 > URL: https://issues.apache.org/jira/browse/SLING-8446 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Kafka 0.1.0 >Reporter: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Kafka 0.1.5 > > > There is one remaining issue with the Azure Event Hubs support. > The assetTopic method does not work correctly even if the topic exists. > During my evaluation of Event Hubs I was not able to dig more into it. So I > removed the assert code when did a demo. > For actual usage of Azure Event Hubs we either need a config to switch off > topic assertions or we need to solve how to check topics with event hubs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #260 is FIXED
Please see https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/260/ for details. No further emails will be sent until the status of the build is changed.
[jira] [Commented] (SLING-7811) NPE when repository is starting up due to repository manager shutdown
[
https://issues.apache.org/jira/browse/SLING-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900949#comment-16900949
]
Robert Munteanu commented on SLING-7811:
Linked a couple of Oak issues that appear due to the repository service
restarting.
> NPE when repository is starting up due to repository manager shutdown
> -
>
> Key: SLING-7811
> URL: https://issues.apache.org/jira/browse/SLING-7811
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Oak Server 1.1.4, JCR Base 3.0.4
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: JCR Oak Server 1.2.4
>
>
> With the latest Sling Starter, the following NPE occurs in the logs. It seems
> to be harmless, nevertheless we should fix it:
> For now I assigned it to both, JCR Base and Oak Server, as it's unclear which
> one it is. Interestingly we've released Oak Server 1.2.0 but are not using it
> in the starter.
> {noformat}
> 06.08.2018 15:45:18.396 *ERROR* [Apache Sling Repository Startup Thread]
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start:
> Uncaught Throwable trying to access Repository, calling stopRepository()
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192)
> [com.google.guava:15.0.0]
> at org.apache.jackrabbit.oak.jcr.Jcr.with(Jcr.java:296)
> [org.apache.jackrabbit.oak-jcr:1.6.8]
> at
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:161)
> [org.apache.sling.jcr.oak.server:1.1.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:471)
> [org.apache.sling.jcr.base:3.0.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:85)
> [org.apache.sling.jcr.base:3.0.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:455)
> [org.apache.sling.jcr.base:3.0.4]
> {noformat}
> The stack trace points to a null workspace name ( see
> https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.8/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java#L296
> ).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #259 is BROKEN
org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.895 s
- in org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.MkdirTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 s
- in org.apache.sling.launchpad.webapp.integrationtest.MkdirTest
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] MappingEventsProxyTest.runWriteableResourcesTest:26 » JsonGeneration
write(par...
[INFO]
[ERROR] Tests run: 660, Failures: 0, Errors: 1, Skipped: 1
[INFO]
[INFO]
[INFO] --- slingstart-maven-plugin:1.7.16:stop (stop-container) @
org.apache.sling.launchpad.testing ---
[INFO] Stopping 1 Launchpad instances
[INFO] Stopping Launchpad '_-41000'
06.08.2019 11:42:48.969 *INFO * [Apache Sling Terminator] Java VM is shutting
down
06.08.2019 11:42:48.970 *INFO * [Apache Sling Terminator] Stopping Apache Sling
06.08.2019 11:42:54.949 *INFO * [Sling Notifier] Apache Sling has been stopped
[INFO]
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
org.apache.sling.launchpad.testing ---
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.CachedConstructor
(file:/home/jenkins/.m2/repository/org/codehaus/groovy/groovy-all-minimal/1.5.6/groovy-all-minimal-1.5.6.jar)
to constructor java.io.File(java.lang.String,java.io.File)
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.CachedConstructor
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO]
[INFO] --- apache-rat-plugin:0.11:check (default) @
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 7 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0
approved: 6 licence.
[INFO]
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @
org.apache.sling.launchpad.testing ---
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 03:56 min
[INFO] Finished at: 2019-08-06T11:42:56Z
[INFO]
[INFO] [jenkins-event-spy] Generated
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMavencf0401d0/maven-spy-20190806-113859-8087507513590622941434.log
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[withMaven] Publishers: Pipeline Graph Publisher: 3 ms, JGiven Publisher: 1 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext
[jira] [Resolved] (SLING-8614) Update to Oak 1.16
[ https://issues.apache.org/jira/browse/SLING-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-8614. Resolution: Fixed Fixed with [sling-org-apache-sling-starter commit c4f6e3b|https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b] > Update to Oak 1.16 > -- > > Key: SLING-8614 > URL: https://issues.apache.org/jira/browse/SLING-8614 > Project: Sling > Issue Type: Task > Components: Starter >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Labels: Sling-12-ReleaseNotes > Fix For: Starter 12 > > > We're lagging behind Oak releases, and Oak 1.16.0 was just released. We > should update now. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SLING-8615) Move to a resource-centric setup
Robert Munteanu created SLING-8615: -- Summary: Move to a resource-centric setup Key: SLING-8615 URL: https://issues.apache.org/jira/browse/SLING-8615 Project: Sling Issue Type: Improvement Components: Starter Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Starter Content 1.0.6 As proposed on https://lists.apache.org/thread.html/847538afdb43d82c7c4a2d59464897168ea1302a69c5b0863eddc360@%3Cdev.sling.apache.org%3E , we should use the Sling way and base the starter-content bundle on scripts and resources. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SLING-8607) AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
[
https://issues.apache.org/jira/browse/SLING-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900826#comment-16900826
]
angela commented on SLING-8607:
---
[~rombert], it's an implementation detail whether or not adding an entry will
change the policy (and thus potentially the effect). note that even if the
entry you are about to add was already present with the exact same values, it
doesn't necessarily mean that it has the same effect that adding it again.
that's essentially what tried to highlight when the repo-init feature was
introduced it's just not totally clear to me if the language describes the
desired outcome or if it describes the access control setup actions to be
performed. and i hope that everyone agrees that repo-init should not rely on
implementation details of a given JCR implementation... and doing the manual
testing essentially does that IMO.
take a simple example with the default implementation:
- a given, existing list contains with two entries: the first one grants read
access on /content and the second revokes read-access for some items in the
subtree.
- now repo-init contains a statement allow read permission on /content
questions:
- does the repo init statement want to make all of /content is readable (i.e.
is it an instruction about effective permissions)? the existing entry would
need to be reordered in order (essentially removing the effect of the second
entry
- does the repo init statement just describe the access control setup? in this
case the followup question was: do you care about the net effect at all? do you
want to append the entry to the list (potentially reordering an existing
entry)? if not: do you want to insert it? and if yes, at which position?
further more:
if a given node was checked-in or locked, you may end up with a similar
problem, that access control setup will fail for non-accesscontrol related
issues. for that matter, the JCR specifications has defined
{{Session.hasCapability}}.
so, i would suggest to adjust the implementation of t{{Session.hasCapability}}
support access control operations and also to respect immutable mounts... the
current implementation in Oak is limited for no other reason than
time-constraint and nobody asked for it.
> AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
> ---
>
> Key: SLING-8607
> URL: https://issues.apache.org/jira/browse/SLING-8607
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Reporter: angela
>Priority: Minor
>
> [~rombert], {{AclUtil.setAcl}} attempts to avoid adding redundant entries
> (and writing an unmodified policy back to the repository).
> however, it ignores the return value of
> {{JackrabbitAccessControlList.addEntry}}, which as far as i remember
> indicates if the given policy has been modified by the given call. i would
> recommend to take the return value into consideration instead of always
> setting 'changed = true'.
> in addition: i am not totally convinced that it is wise to 'manually' compare
> the existing entries with the ones to add and it might well lead to subtle
> inconsistencies. also, depending on the exact implementation of the
> {{JackrabbitAccessControlList}}, adding an entry (even if already contained)
> may effectively alter the policy (e.g. by appending the entry and thus
> affecting the overall outcome of the evaluation). in other words: IMO it
> would be better to rely on the capability of the
> {{JackrabbitAccessControlList}} to determine if an entry was added or not
> (also the {{expandPrivileges}} may be achieved in an optimized fashion with
> the acl-implementation).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (SLING-8614) Update to Oak 1.16
Robert Munteanu created SLING-8614: -- Summary: Update to Oak 1.16 Key: SLING-8614 URL: https://issues.apache.org/jira/browse/SLING-8614 Project: Sling Issue Type: Task Components: Starter Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Starter 12 We're lagging behind Oak releases, and Oak 1.16.0 was just released. We should update now. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SLING-8607) AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
[
https://issues.apache.org/jira/browse/SLING-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900783#comment-16900783
]
Robert Munteanu commented on SLING-8607:
Thanks for the report [~angela].
Without looking at the code right now, I can say that the checks were added
specifically for {{CompositeNodeStore}} setups where some paths are effectively
read-only. So I cannot rely on the return value of a method to check if the
access control entry was added, since the invocation would fail. Is there a
safer way of knowing if the access control entry is applied?
> AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
> ---
>
> Key: SLING-8607
> URL: https://issues.apache.org/jira/browse/SLING-8607
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Reporter: angela
>Priority: Minor
>
> [~rombert], {{AclUtil.setAcl}} attempts to avoid adding redundant entries
> (and writing an unmodified policy back to the repository).
> however, it ignores the return value of
> {{JackrabbitAccessControlList.addEntry}}, which as far as i remember
> indicates if the given policy has been modified by the given call. i would
> recommend to take the return value into consideration instead of always
> setting 'changed = true'.
> in addition: i am not totally convinced that it is wise to 'manually' compare
> the existing entries with the ones to add and it might well lead to subtle
> inconsistencies. also, depending on the exact implementation of the
> {{JackrabbitAccessControlList}}, adding an entry (even if already contained)
> may effectively alter the policy (e.g. by appending the entry and thus
> affecting the overall outcome of the evaluation). in other words: IMO it
> would be better to rely on the capability of the
> {{JackrabbitAccessControlList}} to determine if an entry was added or not
> (also the {{expandPrivileges}} may be achieved in an optimized fashion with
> the acl-implementation).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (SLING-8607) AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
[
https://issues.apache.org/jira/browse/SLING-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900783#comment-16900783
]
Robert Munteanu edited comment on SLING-8607 at 8/6/19 8:47 AM:
Thanks for the report [~angela].
These checks were added specifically for {{CompositeNodeStore}} setups where
some paths are effectively read-only. So I cannot rely on the return value of a
method to check if the access control entry was added, since the invocation
would fail. Is there a safer way of knowing if the access control entry is
applied?
(_edit_: I did look at the code after all ...)
was (Author: rombert):
Thanks for the report [~angela].
Without looking at the code right now, I can say that the checks were added
specifically for {{CompositeNodeStore}} setups where some paths are effectively
read-only. So I cannot rely on the return value of a method to check if the
access control entry was added, since the invocation would fail. Is there a
safer way of knowing if the access control entry is applied?
> AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
> ---
>
> Key: SLING-8607
> URL: https://issues.apache.org/jira/browse/SLING-8607
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Reporter: angela
>Priority: Minor
>
> [~rombert], {{AclUtil.setAcl}} attempts to avoid adding redundant entries
> (and writing an unmodified policy back to the repository).
> however, it ignores the return value of
> {{JackrabbitAccessControlList.addEntry}}, which as far as i remember
> indicates if the given policy has been modified by the given call. i would
> recommend to take the return value into consideration instead of always
> setting 'changed = true'.
> in addition: i am not totally convinced that it is wise to 'manually' compare
> the existing entries with the ones to add and it might well lead to subtle
> inconsistencies. also, depending on the exact implementation of the
> {{JackrabbitAccessControlList}}, adding an entry (even if already contained)
> may effectively alter the policy (e.g. by appending the entry and thus
> affecting the overall outcome of the evaluation). in other words: IMO it
> would be better to rely on the capability of the
> {{JackrabbitAccessControlList}} to determine if an entry was added or not
> (also the {{expandPrivileges}} may be achieved in an optimized fashion with
> the acl-implementation).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (SLING-8606) Wrong JIRA ticket ref contained in commit message to SLING-6398
[
https://issues.apache.org/jira/browse/SLING-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-8606.
Resolution: Fixed
Thanks [~angela], solved as proposed.
> Wrong JIRA ticket ref contained in commit message to SLING-6398
> ---
>
> Key: SLING-8606
> URL: https://issues.apache.org/jira/browse/SLING-8606
> Project: Sling
> Issue Type: Wish
> Components: Repoinit
>Reporter: angela
>Assignee: Robert Munteanu
>Priority: Minor
>
> [~rombert], when fixing SLING-6398 in
> https://svn.apache.org/repos/asf/sling/trunk@1774410 , the following commit
> message was added:
> {quote}
> SLING-6368 - Repoinit should not attempt to create access control entries
> when no changes are needed
> {quote}
> as you can see this references the wrong JIRA ticket, which makes i a bit
> hard to find out why the given changes was introduced you may already
> suspect, that i am not all convinced the code is behaving correctly (see
> separate ticket that will follow) ;)
>
> anyway: if there was any chance to fix the commit message, i would appreciate
> it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (SLING-6368) Eclipse IDE Publishing: Double backslashes are not correctly resolved in JCR attribute values
[
https://issues.apache.org/jira/browse/SLING-6368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6368:
---
Description:
Note: a commit reference was incorrectly made to this commit instead of
SLING-6398, you might want that issue instead.
If a .content.xml file contains a attribute like this
{code}
configjson="\{title: Resolved
Segments,icon:
coral-Icon--targeted,storeMapping:
{s: segmentation
},template: p
class=\\contexthub-module-line1\\>Resolved Segments/p>p
class=\\contexthub-module-line2\\>{{s.summary}}/p>,
clickable: true,listReference:
/store/segmentation/segments,listType:
custom,listItemTemplate:
span>{{label}}/span>,
itemOnClickNoop: true}"
{code}
the double "\" is not resolved correclty.
In the JCR its value is shown as
{code}
{
"title": "Resolved Segments",
"icon": "coral-Icon--targeted",
"storeMapping": {
"s": "segmentation"
},
"template": "Resolved Segments{{s.summary}}",
"clickable": true,
"listReference": "/store/segmentation/segments",
"listType": "custom",
"listItemTemplate": "{{label}}",
"itemOnClickNoop": true
}
{code}
(i.e. it contains double backslashes).
When being deployed through the content-package-maven-plugin the same attribute
is being stored in the JCR with value
{code}
{
"title": "Resolved Segments",
"icon": "coral-Icon--targeted",
"storeMapping": {
"s": "segmentation"
},
"template": "Resolved Segments{{s.summary}}",
"clickable": true,
"listReference": "/store/segmentation/segments",
"listType": "custom",
"listItemTemplate": "{{label}}",
"itemOnClickNoop": true
}
{code}
(i.e. only with single backslashes).
Attached is the full problematic {{.content.xml}} renamed to {{content.xml}}.
was:
If a .content.xml file contains a attribute like this
{code}
configjson="\{title: Resolved
Segments,icon:
coral-Icon--targeted,storeMapping:
{s: segmentation
},template: p
class=\\contexthub-module-line1\\>Resolved Segments/p>p
class=\\contexthub-module-line2\\>{{s.summary}}/p>,
clickable: true,listReference:
/store/segmentation/segments,listType:
custom,listItemTemplate:
span>{{label}}/span>,
itemOnClickNoop: true}"
{code}
the double "\" is not resolved correclty.
In the JCR its value is shown as
{code}
{
"title": "Resolved Segments",
"icon": "coral-Icon--targeted",
"storeMapping": {
"s": "segmentation"
},
"template": "Resolved Segments{{s.summary}}",
"clickable": true,
"listReference": "/store/segmentation/segments",
"listType": "custom",
"listItemTemplate": "{{label}}",
"itemOnClickNoop": true
}
{code}
(i.e. it contains double backslashes).
When being deployed through the content-package-maven-plugin the same attribute
is being stored in the JCR with value
{code}
{
"title": "Resolved Segments",
"icon": "coral-Icon--targeted",
"storeMapping": {
"s": "segmentation"
},
"template": "Resolved Segments{{s.summary}}",
"clickable": true,
"listReference": "/store/segmentation/segments",
"listType": "custom",
"listItemTemplate": "{{label}}",
"itemOnClickNoop": true
}
{code}
(i.e. only with single backslashes).
Attached is the full problematic {{.content.xml}} renamed to {{content.xml}}.
> Eclipse IDE Publishing: Double backslashes are not correctly resolved in JCR
> attribute values
> -
>
> Key: SLING-6368
> URL: https://issues.apache.org/jira/browse/SLING-6368
> Project: Sling
> Issue Type: Bug
> Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-6368-testv02.patch, SLING-6368-v01.patch,
> content.xml
>
>
> Note: a commit reference was incorrectly made to this commit instead of
> SLING-6398, you might want that issue instead.
> If a .content.xml file contains a attribute like this
> {code}
> configjson="\{title: Resolved
> Segments,icon:
> coral-Icon--targeted,storeMapping:
> {s: segmentation
> },template: p
> class=\\contexthub-module-line1\\>Resolved Segments/p>p
> class=\\contexthub-module-line2\\>{{s.summary}}/p>,
> clickable: true,listReference:
> /store/segmentation/segments,listType:
> custom,listItemTemplate:
> span>{{label}}/span>,
> itemOnClickNoop: true}"
> {code}
> the double "\" is not resolved correclty.
> In the JCR its value is shown as
> {code}
> {
> "title": "Resolved Segments",
>"icon": "coral-Icon--targeted",
> "storeMapping": {
> "s":
Re: [DISCUSS] Switching o.a.s.starter-content to use scripts and resources?
On Mon, 2019-08-05 at 20:49 +0300, Robert Munteanu wrote: > A quick check in the starter application shows that there at least > the > Felix HC bundle expects this file to be present (config snippet > below) > > PID = > org.apache.felix.hc.core.impl.filter.ServiceUnavailableFilter~startup > andshutdown > responseTextFor503 = > classpath:org.apache.sling.starter.content:content/content/startup/in > dex.html Replying to myself here - the /content/startup/index.html file is different from the /content/starter/index.html one, so no change is required here. Robert
[jira] [Commented] (SLING-8606) Wrong JIRA ticket ref contained in commit message to SLING-6398
[
https://issues.apache.org/jira/browse/SLING-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900664#comment-16900664
]
angela commented on SLING-8606:
---
[~rombert], fine with me. thanks a lot
> Wrong JIRA ticket ref contained in commit message to SLING-6398
> ---
>
> Key: SLING-8606
> URL: https://issues.apache.org/jira/browse/SLING-8606
> Project: Sling
> Issue Type: Wish
> Components: Repoinit
>Reporter: angela
>Assignee: Robert Munteanu
>Priority: Minor
>
> [~rombert], when fixing SLING-6398 in
> https://svn.apache.org/repos/asf/sling/trunk@1774410 , the following commit
> message was added:
> {quote}
> SLING-6368 - Repoinit should not attempt to create access control entries
> when no changes are needed
> {quote}
> as you can see this references the wrong JIRA ticket, which makes i a bit
> hard to find out why the given changes was introduced you may already
> suspect, that i am not all convinced the code is behaving correctly (see
> separate ticket that will follow) ;)
>
> anyway: if there was any chance to fix the commit message, i would appreciate
> it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
