[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=16902340#comment-16902340 ] Eric Norman edited comment on SLING-7927 at 8/7/19 5:42 PM: [~jebailey] In your proposal, may I ask who would make the decision on how to handle errors? In other words, how it would be pre-determined whether to call `load(content)` versus a 'loadQuietly(content)`? Also, I am curious how these new skipped errors would impact the existing content loading 'retry' logic. Would the quiet content loading errors trigger an attempt to re-try content loading later or would that bundle content loading be considered complete with no retries? Alternatively, perhaps a better solution would be to create a new maven plugin to parse and validate that your JSON files are well formed? This should catch malformed content problems earlier at build time so you wouldn't have to try to debug the troubles later in the runtime? I'm imagining something similar to how the syntax of htl files are validated at build time by [https://sling.apache.org/components/htl-maven-plugin/] was (Author: edn): [~jebailey] In your proposal, may I ask who would make the decision on how to handle errors? In other words, how it would be pre-determined whether do call `load(content)` versus a 'loadQuietly(content)`? Also, I am curious how these new skipped errors would impact the existing content loading 'retry' logic. Would the quiet content loading errors trigger an attempt to re-try content loading later or would that bundle content loading be considered complete with no retries? Alternatively, perhaps a better solution would be to create a new maven plugin to parse and validate that your JSON files are well formed? This should catch malformed content problems earlier at build time so you wouldn't have to try to debug the troubles later in the runtime? I'm imagining something similar to how the syntax of htl files are validated at build time by [https://sling.apache.org/components/htl-maven-plugin/] > 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] [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=16902340#comment-16902340 ] Eric Norman edited comment on SLING-7927 at 8/7/19 5:41 PM: [~jebailey] In your proposal, may I ask who would make the decision on how to handle errors? In other words, how it would be pre-determined whether do call `load(content)` versus a 'loadQuietly(content)`? Also, I am curious how these new skipped errors would impact the existing content loading 'retry' logic. Would the quiet content loading errors trigger an attempt to re-try content loading later or would that bundle content loading be considered complete with no retries? Alternatively, perhaps a better solution would be to create a new maven plugin to parse and validate that your JSON files are well formed? This should catch malformed content problems earlier at build time so you wouldn't have to try to debug the troubles later in the runtime? I'm imagining something similar to how the syntax of htl files are validated at build time by [https://sling.apache.org/components/htl-maven-plugin/] was (Author: edn): [~jebailey] In your proposal, may I ask who would make the decision on how to handle errors? In other words, how it would be pre-determined whether do call `load(content)` versus a 'loadQuietly(content)`? Also, I am curious how these new skipped errors would impact the existing content loading 'retry' logic. Would the quiet content loading errors trigger an attempt to re-try content loading later or would that bundle content loading be considered complete with no retries? Alternatively, perhaps a better solution would be to create a new maven plugin to parse and validate that your JSON files are well formed? This should catch malformed content problems earlier at build time so you wouldn't have to try to debug the troubles later in the runtime? I'm imagining something similar to how htl files are validated at build time by [https://sling.apache.org/components/htl-maven-plugin/] > 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=16902340#comment-16902340 ] Eric Norman commented on SLING-7927: [~jebailey] In your proposal, may I ask who would make the decision on how to handle errors? In other words, how it would be pre-determined whether do call `load(content)` versus a 'loadQuietly(content)`? Also, I am curious how these new skipped errors would impact the existing content loading 'retry' logic. Would the quiet content loading errors trigger an attempt to re-try content loading later or would that bundle content loading be considered complete with no retries? Alternatively, perhaps a better solution would be to create a new maven plugin to parse and validate that your JSON files are well formed? This should catch malformed content problems earlier at build time so you wouldn't have to try to debug the troubles later in the runtime? I'm imagining something similar to how htl files are validated at build time by [https://sling.apache.org/components/htl-maven-plugin/] > 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] [Updated] (SLING-8619) RepoInitGrammer: Add repository-level marker to pathsList
[
https://issues.apache.org/jira/browse/SLING-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated SLING-8619:
--
Description:
In order to be able to cover repository level access control entrieswith the
{{PrincipalAccessControlList}} (see SLING-8602), i would like to expand the
{{RepoInitGrammer.pathsList()}} such that it not only handles absolute paths
but in addition a marker for the repository level permissions (in JCR marked
with a _null_ path).
essentially this would also create an alternative way to edit policies for the
_null_ path (today covered with _set repository ACL ..._).
will provide a proposed patch and tests later this week.
was:
In order to be able to cover repository level access control entrieswith the
{{PrincipalAccessControlList}} (see SLING-8602), i would like to expand the
{{RepoInitGrammer.pathsList()}} such that it not only handles absolute paths
but in addition a marker for the repository level permissions (in JCR marked
with a _null_ path).
essentially this would also create an alternative way to edit policies for the
_null_ path (today covered with _set repository ACL ..._)
> RepoInitGrammer: Add repository-level marker to pathsList
> -
>
> Key: SLING-8619
> URL: https://issues.apache.org/jira/browse/SLING-8619
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
>Reporter: angela
>Priority: Major
>
> In order to be able to cover repository level access control entrieswith the
> {{PrincipalAccessControlList}} (see SLING-8602), i would like to expand the
> {{RepoInitGrammer.pathsList()}} such that it not only handles absolute paths
> but in addition a marker for the repository level permissions (in JCR marked
> with a _null_ path).
> essentially this would also create an alternative way to edit policies for
> the _null_ path (today covered with _set repository ACL ..._).
> will provide a proposed patch and tests later this week.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (SLING-8619) RepoInitGrammer: Add repository-level marker to pathsList
angela created SLING-8619:
-
Summary: RepoInitGrammer: Add repository-level marker to pathsList
Key: SLING-8619
URL: https://issues.apache.org/jira/browse/SLING-8619
Project: Sling
Issue Type: Improvement
Components: Repoinit
Reporter: angela
In order to be able to cover repository level access control entrieswith the
{{PrincipalAccessControlList}} (see SLING-8602), i would like to expand the
{{RepoInitGrammer.pathsList()}} such that it not only handles absolute paths
but in addition a marker for the repository level permissions (in JCR marked
with a _null_ path).
essentially this would also create an alternative way to edit policies for the
_null_ path (today covered with _set repository ACL ..._)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
+1 (non-binding) - Andy > On Aug 6, 2019, at 12:28 PM, Stefan Seifert wrote: > > 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 >
[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=16902083#comment-16902083 ] Jason E Bailey commented on SLING-7927: --- [~edn] you're absolutely right, there are situations where we want to fail and then there's situations where we want it to log and proceed. So a good solution would be to come up with a way of handling both scenarios. May a `load(content)` versus a 'loadQuietly(content)` > 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)
Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
+1 Le mer. 7 août 2019 à 09:28, David Bosschaert a écrit : > +1 > > David > > On Wed, 7 Aug 2019 at 07:13, Carsten Ziegeler > wrote: > > > +1 > > > > > > Carsten > > > > > > Stefan Seifert wrote > > > 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 > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > >
[jira] [Updated] (SLING-8234) Feature launcher does not specify which content package requires a missing dependency
[
https://issues.apache.org/jira/browse/SLING-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated SLING-8234:
--
Fix Version/s: (was: Feature Model Launcher 1.0.6)
Feature Model Launcher 1.0.8
> Feature launcher does not specify which content package requires a missing
> dependency
> -
>
> Key: SLING-8234
> URL: https://issues.apache.org/jira/browse/SLING-8234
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Feature Model Launcher 1.0.8
>
>
> When trying to run an application which depends on a missing content package,
> an uncaught exception stops the application, but does not explain which
> content package is missing a dependency, making troubleshooting difficult:
> {noformat}[ERROR] Error while assembling launcher: Package has unresolved
> dependencies: day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
> shaded.org.apache.jackrabbit.vault.packaging.DependencyException: Package has
> unresolved dependencies:
> day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
> at
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.resolveInstall(ExecutionPlanBuilderImpl.java:257)
> at
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate(ExecutionPlanBuilderImpl.java:239)
> at
> org.apache.sling.feature.extension.content.ContentHandler.buildExecutionPlan(ContentHandler.java:79)
> at
> org.apache.sling.feature.extension.content.ContentHandler.handle(ContentHandler.java:121)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.prepareLauncher(FeatureProcessor.java:159)
> at
> org.apache.sling.feature.launcher.impl.Main.main(Main.java:250){noformat}
> It would be very helpful if the package missing dependencies would be
> included in the message as well.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (SLING-8618) Add method to scan a bundle
[ https://issues.apache.org/jira/browse/SLING-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-8618. - Resolution: Fixed Added new method scanBundle in rev 3075497 > Add method to scan a bundle > --- > > Key: SLING-8618 > URL: https://issues.apache.org/jira/browse/SLING-8618 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Analyser 1.0.8 > > > The scanner has a method to scan a bundle, but this takes an artifact and a > start level. On the other hand, Artifact has already support for the start > order, so the second argument to the scan method is superfluous and misleading -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SLING-8618) Add method to scan a bundle
[ https://issues.apache.org/jira/browse/SLING-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-8618: Fix Version/s: (was: Feature Model Analyser 1.0.6) Feature Model Analyser 1.0.8 > Add method to scan a bundle > --- > > Key: SLING-8618 > URL: https://issues.apache.org/jira/browse/SLING-8618 > Project: Sling > Issue Type: Improvement > Components: Feature Model Analyser >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Analyser 1.0.8 > > > The scanner has a method to scan a bundle, but this takes an artifact and a > start level. On the other hand, Artifact has already support for the start > order, so the second argument to the scan method is superfluous and misleading -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SLING-8618) Add method to scan a bundle
Carsten Ziegeler created SLING-8618: --- Summary: Add method to scan a bundle Key: SLING-8618 URL: https://issues.apache.org/jira/browse/SLING-8618 Project: Sling Issue Type: Improvement Components: Feature Model Analyser Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Feature Model Analyser 1.0.6 The scanner has a method to scan a bundle, but this takes an artifact and a start level. On the other hand, Artifact has already support for the start order, so the second argument to the scan method is superfluous and misleading -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
+1 David On Wed, 7 Aug 2019 at 07:13, Carsten Ziegeler wrote: > +1 > > > Carsten > > > Stefan Seifert wrote > > 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 > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.4.10, Testing Sling Mock 2.3.16
+1 Carsten Stefan Seifert wrote 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 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
