[jira] [Resolved] (SLING-9859) Avoid import of package of o.a.felix.hc.generalchecks.util
[ https://issues.apache.org/jira/browse/SLING-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler resolved SLING-9859. -- Resolution: Fixed Fixed in [7c331cde0c821c|https://github.com/apache/sling-org-apache-sling-hc-support/commit/7c331cde0c821c35e60cd2c8e7323a4e765f5ba4] > Avoid import of package of o.a.felix.hc.generalchecks.util > -- > > Key: SLING-9859 > URL: https://issues.apache.org/jira/browse/SLING-9859 > Project: Sling > Issue Type: Improvement > Components: Health Check >Affects Versions: Health Check Support 1.0.6 >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > Fix For: Health Check Support 1.0.8 > > > Depending on setup, some Sling instances do not make > org.apache.felix.hc.generalchecks.util available to bundle > org.apache.sling.hc.support du to API region restrictions. To ensure > org.apache.sling.hc.support can be used in all setups, use > Conditional-Package to inline the util package -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9859) Avoid import of package of o.a.felix.hc.generalchecks.util
Georg Henzler created SLING-9859: Summary: Avoid import of package of o.a.felix.hc.generalchecks.util Key: SLING-9859 URL: https://issues.apache.org/jira/browse/SLING-9859 Project: Sling Issue Type: Improvement Components: Health Check Affects Versions: Health Check Support 1.0.6 Reporter: Georg Henzler Assignee: Georg Henzler Fix For: Health Check Support 1.0.8 Depending on setup, some Sling instances do not make org.apache.felix.hc.generalchecks.util available to bundle org.apache.sling.hc.support du to API region restrictions. To ensure org.apache.sling.hc.support can be used in all setups, use Conditional-Package to inline the util package -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-7246) Document changes for SLING-6855 and SLING-6946
[ https://issues.apache.org/jira/browse/SLING-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler closed SLING-7246. > Document changes for SLING-6855 and SLING-6946 > -- > > Key: SLING-7246 > URL: https://issues.apache.org/jira/browse/SLING-7246 > Project: Sling > Issue Type: Task > Components: Health Check >Reporter: Karl Pauls >Assignee: Georg Henzler >Priority: Major > > Moving out the pending documentation for SLING-6855 and SLING-6946 to this > issue. [~henzlerg], please follow-up wrt. the missing documentation (if any) > using this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-7246) Document changes for SLING-6855 and SLING-6946
[ https://issues.apache.org/jira/browse/SLING-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler updated SLING-7246: - Fix Version/s: (was: Health Check Core 1.2.12) > Document changes for SLING-6855 and SLING-6946 > -- > > Key: SLING-7246 > URL: https://issues.apache.org/jira/browse/SLING-7246 > Project: Sling > Issue Type: Task > Components: Health Check >Reporter: Karl Pauls >Assignee: Georg Henzler >Priority: Major > > Moving out the pending documentation for SLING-6855 and SLING-6946 to this > issue. [~henzlerg], please follow-up wrt. the missing documentation (if any) > using this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9800) Extract a service to be able to execute GraphQL queries directly
[
https://issues.apache.org/jira/browse/SLING-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221811#comment-17221811
]
Andreas Schaefer commented on SLING-9800:
-
[~bdelacretaz] I am working on the AEM GraphQL Persisted Queries and a client
is calling the PQ servlet instead of an GraphiQL endpoint. So the resource of
the request is the Servlet and using that resource is not working out
(DefaultSchemaProvider.getSchema() returns an empty string). When using a Mock
Resource with these values:
new MockResource(
"/apps/graphql-enablement/content/endpoint", /* path */
"graphql-enablement/components/endpoint", /* resourceType */
null, /* resourceSuperType */
null, /* metadata */
resourceResolver,
new ValueMapDecorator(new HashMap() {{
put("", "");
}}), /* properties */
null /* parent */
);
- Andy
> Extract a service to be able to execute GraphQL queries directly
>
>
> Key: SLING-9800
> URL: https://issues.apache.org/jira/browse/SLING-9800
> Project: Sling
> Issue Type: Improvement
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.8
>
>
> In the current implementation of the GraphQL Core bundle queries can only be
> executed via a GraphQL Servlet that needs to be configured or via server-side
> scripts. It would be good if the queries could also be executed directly,
> without the need for a request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [Discuss] - JCR ContentLoader Skip Runmode
Robert / Team, Any thoughts / concerns? I would like to get this fix in place. On Thu, Oct 22, 2020 at 2:34 PM Daniel Klco wrote: > Robert, > > I agree it could be misconfigured, however the intent is to only configure > it when needed and for the code to work the same as the current > functionality if not configured. > > The challenge I see with requiring the implementer to support separating > their content into two bundles is that it pushes the complexity of the > internal functionality of the repository onto the implementing team rather > than handling it inside the application. We know that /apps and /libs > shouldn't be written to at runtime, so why require the user to consider > this? Especially when the side-effect is that the entire bundle content > fails to install. > > I'm very much willing to look into other options, but I'm not a huge fan > of having users refactor their codebase to support internal implementation > details, especially when it's only required for certain setups. > > On Thu, Oct 22, 2020 at 10:12 AM Robert Munteanu > wrote: > >> On Wed, 2020-10-21 at 08:25 -0400, Daniel Klco wrote: >> > Seeding Setting: >> > - Includes Path: [ "^/apps/.*", "^/libs/.*", "^/oak:index/.*" ] >> > >> > Runtime Setting: >> > - Includes Path: [ "^/.*" ] >> > - Excludes Path: [ "^/apps/.*", "^/libs/.*", "^/oak:index/.*" ] >> > >> > The Bundle Content Loader would then filter out the path roots based >> > on the >> > include / exclude rules. I would only expect this to happen at the >> > path >> > root, not for the individual nodes being loaded. The configuration >> > would >> > not be required and in that case the Bundle Content Loader would load >> > all >> > content. >> >> I think this will work. I am wondering though whether we are not >> opening the door for surprising behaviours and misconfigurations. I >> think the only scenario where this is useful is: >> >> - bundle A is used in a composite node store setup >> - bundle A contains resources that belong to both the default mounnt >> and the non-default one ( /libs, /apps ) >> - bundle A installs content using the content loader >> >> I think that a better solution would be to avoid this problem >> altogether by separating 'code' bundles from 'content' bundles, and >> only installing the 'code' bundle when seeding. >> >> Thanks, >> Robert >> >>
[GitHub] [sling-org-apache-sling-models-impl] sonarcloud[bot] commented on pull request #22: SLING-9858 remove commons testing
sonarcloud[bot] commented on pull request #22: URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/22#issuecomment-717327935 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=SEC URITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-models-impl=22=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-models-impl=22=coverage=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-models-impl=22=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-models-impl=22=new_duplicated_lines_density=list) The version of Java (1.8.0_252) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11. Read more [here](https://sonarcloud.io/documentation/upcoming/) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-models-impl] kwin opened a new pull request #22: SLING-9858 remove commons testing
kwin opened a new pull request #22: URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/22 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SLING-9858) Get rid of commons testing dependency
[ https://issues.apache.org/jira/browse/SLING-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-9858: -- Assignee: Konrad Windszus > Get rid of commons testing dependency > - > > Key: SLING-9858 > URL: https://issues.apache.org/jira/browse/SLING-9858 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Affects Versions: Models Implementation 1.4.16 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Models Implementation 1.4.18 > > > Given that there are better alternatives for most packages in Commons Testing > (https://issues.apache.org/jira/browse/SLING-7166) we should get rid of the > dependency in Models Impl. > As only a mock for SlingHttpServletRequest is used from commons testing > AFAICS we should start using > https://github.com/apache/sling-org-apache-sling-servlet-helpers/blob/master/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9856) models-impl declares compile dependency to org.apache.sling.commons.testing
[
https://issues.apache.org/jira/browse/SLING-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221463#comment-17221463
]
Stefan Seifert commented on SLING-9856:
---
yes, makes sense!
> models-impl declares compile dependency to org.apache.sling.commons.testing
> ---
>
> Key: SLING-9856
> URL: https://issues.apache.org/jira/browse/SLING-9856
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Implementation 1.4.16
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.4.18
>
>
> SLING-9834 introduced a compile dependency to
> {{org.apache.sling.commons.testing}} which creates downstream problems when
> referencing this release in unit tests e.g. using Sling Mocks, as
> org.apache.sling.commons.testing pollutes the dependency tree with old
> versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9858) Get rid of commons testing dependency
[ https://issues.apache.org/jira/browse/SLING-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-9858: --- Description: Given that there are better alternatives for most packages in Commons Testing (https://issues.apache.org/jira/browse/SLING-7166) we should get rid of the dependency in Models Impl. As only a mock for SlingHttpServletRequest is used from commons testing AFAICS we should start using https://github.com/apache/sling-org-apache-sling-servlet-helpers/blob/master/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java instead. was:Given that there are better alternatives for most packages in Commons Testing (https://issues.apache.org/jira/browse/SLING-7166) we should get rid of the dependency in Models Impl. > Get rid of commons testing dependency > - > > Key: SLING-9858 > URL: https://issues.apache.org/jira/browse/SLING-9858 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Affects Versions: Models Implementation 1.4.16 >Reporter: Konrad Windszus >Priority: Major > Fix For: Models Implementation 1.4.18 > > > Given that there are better alternatives for most packages in Commons Testing > (https://issues.apache.org/jira/browse/SLING-7166) we should get rid of the > dependency in Models Impl. > As only a mock for SlingHttpServletRequest is used from commons testing > AFAICS we should start using > https://github.com/apache/sling-org-apache-sling-servlet-helpers/blob/master/src/main/java/org/apache/sling/servlethelpers/MockSlingHttpServletRequest.java > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9856) models-impl declares compile dependency to org.apache.sling.commons.testing
[
https://issues.apache.org/jira/browse/SLING-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221452#comment-17221452
]
Konrad Windszus commented on SLING-9856:
I think we should rather try to get rid of commons testing altogether, I
therefore created the follow up SLING-9858.
> models-impl declares compile dependency to org.apache.sling.commons.testing
> ---
>
> Key: SLING-9856
> URL: https://issues.apache.org/jira/browse/SLING-9856
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Implementation 1.4.16
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.4.18
>
>
> SLING-9834 introduced a compile dependency to
> {{org.apache.sling.commons.testing}} which creates downstream problems when
> referencing this release in unit tests e.g. using Sling Mocks, as
> org.apache.sling.commons.testing pollutes the dependency tree with old
> versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9858) Get rid of commons testing dependency
Konrad Windszus created SLING-9858: -- Summary: Get rid of commons testing dependency Key: SLING-9858 URL: https://issues.apache.org/jira/browse/SLING-9858 Project: Sling Issue Type: Improvement Components: Sling Models Affects Versions: Models Implementation 1.4.16 Reporter: Konrad Windszus Fix For: Models Implementation 1.4.18 Given that there are better alternatives for most packages in Commons Testing (https://issues.apache.org/jira/browse/SLING-7166) we should get rid of the dependency in Models Impl. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-analyser] sonarcloud[bot] removed a comment on pull request #26: Rework the analyser to report more context and improve the meta data …
sonarcloud[bot] removed a comment on pull request #26: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#issuecomment-717072162 SonarCloud Quality Gate failed. [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26 lved=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [20 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [42.9% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) The version of Java (1.8.0_252) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11. Read more [here](https://sonarcloud.io/documentation/upcoming/) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-analyser] sonarcloud[bot] commented on pull request #26: Rework the analyser to report more context and improve the meta data …
sonarcloud[bot] commented on pull request #26: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#issuecomment-717261583 SonarCloud Quality Gate failed. [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26 lved=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [20 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [42.9% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) The version of Java (1.8.0_252) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11. Read more [here](https://sonarcloud.io/documentation/upcoming/) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-analyser] karlpauls commented on a change in pull request #26: Rework the analyser to report more context and improve the meta data …
karlpauls commented on a change in pull request #26:
URL:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#discussion_r512711561
##
File path: src/main/java/org/apache/sling/feature/analyser/Analyser.java
##
@@ -236,29 +244,80 @@ public BundleDescriptor getFrameworkDescriptor() {
@Override
public void reportWarning(final String message) {
-warnings.add(message);
+if (analyserMetaDataExtension != null &&
analyserMetaDataExtension.reportWarning(feature.getId())) {
Review comment:
@cziegeler, good catch! This was supposed to be the other way around - I
fixed it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (SLING-9857) Intermediate path is ignored if user/group already exists
[
https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-9857:
Description:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
in jackrabbit-fvault. however, in a repository setup with many features, it
becomes increasingly difficult to manage and my personal preference would
rather be to keep it simple.
note though SLING-6423: the fvault ac-handling flags already found their way
into the parser (implementation still missing though). so, maybe this issue
here in combination with SLING-6423 could be used to make a conscious decision
about the future development of repo-init beyond this improvement and whether
or not additional flexibility is desirable/needed.
was:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on
[jira] [Updated] (SLING-9857) Intermediate path is ignored if user/group already exists
[
https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-9857:
Description:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
in jackrabbit-fvault. however, in a repository setup with many features, it
becomes increasingly difficult to manage and my personal preference would
rather be to keep it simple.
note though SLING-6423: the fvault ac-handling flags already found their way
into the parser (implementation still missing though). so, maybe this issue
here in combination with SLING-6423 could be used to make a conscious decision
about the future development of repo-init and whether or not additional
flexibility is desirable/needed.
was:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
[jira] [Created] (SLING-9857) Intermediate path is ignored if user/group already exists
Angela Schreiber created SLING-9857:
---
Summary: Intermediate path is ignored if user/group already exists
Key: SLING-9857
URL: https://issues.apache.org/jira/browse/SLING-9857
Project: Sling
Issue Type: Improvement
Components: Repoinit
Reporter: Angela Schreiber
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
in jackrabbit-fvault. however, in a repository setup with many features, it
becomes increasingly difficult to manage and my personal preference would be
rather be to keep it simple.
note though SLING-6423: the fvault ac-handling flags already found their way
into the parser (implementation still missing though). so, maybe this issue
here in combination with SLING-6423 could be used to make a conscious decision
about the future development of repo-init and whether or not additional
flexibility is desirable/needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: sling level package format
Carsten, great to hear I am not the only one that is interested in such a format Would be nice to collect a couple of use cases for such a format to make sure we end up with something useful for everybody my current need would be the ability to: - create users if they do not exist - create groups if they do not exist - set up a tenant if the tenant does not exist yet - turn off incremental processing of pages/assets - import pages and assets honoring their stored replication state and applying the correct permissions - run post processing on all loaded content Ruben On 10/24/2020 12:44 AM, Carsten Ziegeler wrote: Hi, sounds like an interesting idea. I think it makes sense to explore this Regards Carsten Am 21.10.2020 um 14:59 schrieb Ruben Reusser: Dear Sling Devs, currently we rely heavily on jcr filevalut packages to ingest content into our sling instances. While the filevault format is great to operate on the JCR level it unfortunately does not seem to be the best way to ingest some content. I have been wondering for a while if it would be a good idea to create a sling supported import format that operates at a higher level instead. Such an import format could for example solve issues like - ingest a page with all its versions - add/update a page and correctly manage the replication state of the page - turn off asset processing when ingesting processed assets It may be a good idea for sling to provide a basic infrastructure for such an import format where the actions one can take through the format is left to an implementation. Such a format could also be streamable. Unfortunately however such a format would not be able to support the bidirectional nature of the jcr filevault packages we currently enjoy. Would love to hear your thoughts on this and if it would make sense to start working on such a format. Ruben
[jira] [Resolved] (SLING-9856) models-impl declares compile dependency to org.apache.sling.commons.testing
[
https://issues.apache.org/jira/browse/SLING-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-9856.
---
Resolution: Fixed
fixed:
https://github.com/apache/sling-org-apache-sling-models-impl/commit/9f5d62b88b4716be5469f216b85f14b60760f13d
> models-impl declares compile dependency to org.apache.sling.commons.testing
> ---
>
> Key: SLING-9856
> URL: https://issues.apache.org/jira/browse/SLING-9856
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Models Implementation 1.4.16
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.4.18
>
>
> SLING-9834 introduced a compile dependency to
> {{org.apache.sling.commons.testing}} which creates downstream problems when
> referencing this release in unit tests e.g. using Sling Mocks, as
> org.apache.sling.commons.testing pollutes the dependency tree with old
> versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9856) models-impl declares compile dependency to org.apache.sling.commons.testing
Stefan Seifert created SLING-9856:
-
Summary: models-impl declares compile dependency to
org.apache.sling.commons.testing
Key: SLING-9856
URL: https://issues.apache.org/jira/browse/SLING-9856
Project: Sling
Issue Type: Bug
Components: Sling Models
Affects Versions: Models Implementation 1.4.16
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Models Implementation 1.4.18
SLING-9834 introduced a compile dependency to
{{org.apache.sling.commons.testing}} which creates downstream problems when
referencing this release in unit tests e.g. using Sling Mocks, as
org.apache.sling.commons.testing pollutes the dependency tree with old versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-analyser] cziegeler commented on a change in pull request #26: Rework the analyser to report more context and improve the meta data …
cziegeler commented on a change in pull request #26:
URL:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#discussion_r512545425
##
File path: src/main/java/org/apache/sling/feature/analyser/Analyser.java
##
@@ -236,29 +244,80 @@ public BundleDescriptor getFrameworkDescriptor() {
@Override
public void reportWarning(final String message) {
-warnings.add(message);
+if (analyserMetaDataExtension != null &&
analyserMetaDataExtension.reportWarning(feature.getId())) {
Review comment:
Why must analyserMetaDataExtension be available to report anything?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-analyser] karlpauls commented on pull request #26: Rework the analyser to report more context and improve the meta data …
karlpauls commented on pull request #26: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#issuecomment-717073031 @cziegeler, this PR tries to improve the caching in the analyser and is combining the 3 issues we had around it. The main idea is that we now have methods to report errors and warnings by extension and by artifact while the old way of just reporting a string now is called global. Furthermore, I made the reporting driven (optionally) by the meta data extension which can now switch it on or off by artifact id and by feature in general. Finally, artifacts are now retrieved more lazily for bundles and for content packages, at least the errors are delayed until they are really needed. Can you please have a look and let me know if that is going in the right direction? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-analyser] sonarcloud[bot] commented on pull request #26: Rework the analyser to report more context and improve the meta data …
sonarcloud[bot] commented on pull request #26: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26#issuecomment-717072162 SonarCloud Quality Gate failed. [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26 lved=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [20 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-analyser=26=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [42.9% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=26=new_duplicated_lines_density=list) The version of Java (1.8.0_252) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11. Read more [here](https://sonarcloud.io/documentation/upcoming/) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-feature-analyser] karlpauls opened a new pull request #26: Rework the analyser to report more context and improve the meta data …
karlpauls opened a new pull request #26: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/26 …caching extension. * SLING-9823 - Make analyzers report more context about issues and make it possible to filter reports. * SLING-9822 - Make artifact retrieval lazy for cached artifacts. * SLING-9805 - Add a method to create the metadata cache extension. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
