Re: [VOTE] Release Apache Sling Servlet Helpers 1.1.8, Testing JCR Mock 1.3.4, Testing OSGi Mock 2.3.10, Testing Sling Mock 2.2.20
+1 Stefan Seifert wrote > Hi, > > Apache Sling Servlet Helpers 1.1.8 (1 issue) > https://issues.apache.org/jira/browse/SLING/fixforversion/12343277 > > Apache Sling Testing JCR Mock 1.3.4 (1 issue) > https://issues.apache.org/jira/browse/SLING/fixforversion/12341767 > > Apache Sling Testing OSGi Mock 2.3.10 (3 issues) > https://issues.apache.org/jira/browse/SLING/fixforversion/12342970 > > Apache Sling Testing Sling Mock 2.2.20 (3 issues) > https://issues.apache.org/jira/browse/SLING/fixforversion/12342831 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1928/ > > 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 1928 /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: Upgrade a site to a new version of Sling
Theoretically, sling is a sum of the installed bundles so you could create a Jackrabbit package that updates the bundle versions on an existing instance. It would really be up to the end application developer to support such an upgrade mechanism. I'm not sure this would work for all version updates (ex: breaking changes like going from Jackrabbit 2.0 to Oak) but it should work for most. On Jul 31, 2018 7:10 PM, "Andreas Schaefer" wrote: Hi there I was just wondering if there is a way to upgrade to a new version of sling like 9 to 10 without having to export and import my content / configuration. If I have a blog like Slick or a website using Peregrine and I want to upgrade to a newer release of Sling exporting all my content might be an end user nightmare. For example I can easily upgrade my Wordpress site to a newer version. Thanks - Andreas Schaefer
Re: New Repository for Project Archetype
Hi I wanted to rekindle this discussion as my project-archetype (in the sling-whiteboard git repo) is still open and nothing has happened for the past 5 months. Someone mentioned that we should start a discussion about which archetypes should be part of Sling and maybe merged and which one should be retired. Headwire’s Peregrine CMS is using this archetype to generate user packages but for the IDE Tooling (the last time I checked) content can only be edited if it is part of a package rather than a bundle. Cheers - Andy Schaefer > On Jan 22, 2018, at 2:13 AM, Robert Munteanu wrote: > > On Sun, 2018-01-21 at 14:08 -0800, Andreas Schaefer wrote: >> Hi >> >> I added the project-archetype to the Sling Whiteboard under a branch >> feature/sling-7276. >> >> It should deploy just fine on the latest Sling (Sling Starter from >> GitHub). >> >> Let me know if I should merge this into ‘master’ or if you want to >> keep the code >> in that branch for the review. > > I personally don't see a point for having different branches in the > whiteboard - it's by definition a staging ground, so feel free to merge > to master. > > Robert
Upgrade a site to a new version of Sling
Hi there I was just wondering if there is a way to upgrade to a new version of sling like 9 to 10 without having to export and import my content / configuration. If I have a blog like Slick or a website using Peregrine and I want to upgrade to a newer release of Sling exporting all my content might be an end user nightmare. For example I can easily upgrade my Wordpress site to a newer version. Thanks - Andreas Schaefer
Re: /etc/map with Placeholders for farms / dev stack
Hi Ruben,
... may not be the best solution as it would imply a package install
every time a change to the configs are necessary
Updating upon changes is an whole own challenge for your approach -
if resource change listeners only react on changes of placeholder
strings (e.g. 'mystr-${myVar}') because that's the only thing saved
in the JCR and replacement is done across various Sling modules,
there needs to be a new mechanism to listen to changes to property
changes (for the case the value of ${myVar} changes in the previous
example).
Not sure if maybe this would need a bigger spec to continue the work
and alignment on what everybody would like to see
I think this would be good. Maybe best to collect goals and non-goals
on a wiki page at [1]
-Georg
[1] https://cwiki.apache.org/confluence/display/SLING
Re: /etc/map with Placeholders for farms / dev stack
Hi George > On Jul 30, 2018, at 4:29 PM, Georg Henzler wrote: > > Hi Andreas, > >> Install Hooks have their own issues like that they do not work for >> replication > > Install Hooks work flawlessly with replication since around two years > (AEM 6.3) Cool. I probably ran into that a little bit before that. > >>> ... allowing external URLs is dangerous... >> I do agree with that and I will remove that from my POC. > > A property file should still be possible... so if we do this > in Sling, I think the following is needed: > > Property Sources to be supported at minimum: > > * An OSGi configuration > * A local properties file > * OS Env variables > * Java System Properties All but the local properties file I wanted to support. I cannot tell about the security implication of allowing a local properties file to avoid hackers to inject code. > > There should be an Felix console plugin to show what is active > from what source and where the value is used. It should live in > a bundle named like e.g. org.apache.sling.systemenv and provide > a simple interface to perform string interpolation on any > string. This service can then be used by > > * Resource resolver > * Sling distribution > * Context-Aware Configuration The StringInterpolationProvider should not reside inside the Resource Resolver but in its own or a commons package. For my POC I just kept it there for convenience. > > a product like AEM can also use this interface in > > * AEM replication config > * externaliser config > > To have this mechanism properly rolled out it will take some > time (until all listed modules properly use the to-defined > interface) > > IMHO it is not an option to do it locally in resourceresolver > because I started with the etc-mapping as this was the initial use case to move the ball forward. > > a) it would result in quite a bit of duplicated code across the > modules listed above (once we actually start implement it) > b) if additional sources need to be added in the future (think > ZooKeeper as one interesting option to receive those env-specific > values), all consumers would have to be updated (unlikely to > happen, more likely is to have inconsistent behaviour over time) The String Interpolation should be not be in the Resource Resolver and hence can be easily used from other modules. Creating a separate module / git repo for just one class this seems to be a little bit of an overkill. Is there any place where we can place that? > > Since the described above is quite a bit of effort, I opt for > pushing a lower-level approach forward (something like [1] or > maybe even something on oak level). Then there is only one > implementation needed and it's available immediately, everywhere. The ticket below is closed with ‘won’t fix’. So I am not sure if Jackrabbit wants to do that. > > -Georg > > [1] https://issues.apache.org/jira/browse/JCRVLT-254 > > >
RE: [VOTE] Release Apache Sling Servlet Helpers 1.1.8, Testing JCR Mock 1.3.4, Testing OSGi Mock 2.3.10, Testing Sling Mock 2.2.20
+1
[VOTE] Release Apache Sling Servlet Helpers 1.1.8, Testing JCR Mock 1.3.4, Testing OSGi Mock 2.3.10, Testing Sling Mock 2.2.20
Hi, Apache Sling Servlet Helpers 1.1.8 (1 issue) https://issues.apache.org/jira/browse/SLING/fixforversion/12343277 Apache Sling Testing JCR Mock 1.3.4 (1 issue) https://issues.apache.org/jira/browse/SLING/fixforversion/12341767 Apache Sling Testing OSGi Mock 2.3.10 (3 issues) https://issues.apache.org/jira/browse/SLING/fixforversion/12342970 Apache Sling Testing Sling Mock 2.2.20 (3 issues) https://issues.apache.org/jira/browse/SLING/fixforversion/12342831 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1928/ 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 1928 /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] [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.3.10)
Testing OSGi Mock 2.3.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.3.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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: /etc/map with Placeholders for farms / dev stack
Georg, I think this is a good discussion - looks like the sling team has to make some decisions here and I am glad the etc/map work Andreas did is at least sparking a bigger discussion. From my point of view using packages and install hooks may work but may not be the best solution as it would imply a package install every time a change to the configs are necessary. Not sure if maybe this would need a bigger spec to continue the work and alignment on what everybody would like to see Ruben On 7/30/2018 4:29 PM, Georg Henzler wrote: Hi Andreas, Install Hooks have their own issues like that they do not work for replication Install Hooks work flawlessly with replication since around two years (AEM 6.3) and they requires to changes whatever the customer has / provides in order to add the place holders. not sure what you mean with this? ... allowing external URLs is dangerous... I do agree with that and I will remove that from my POC. A property file should still be possible... so if we do this in Sling, I think the following is needed: Property Sources to be supported at minimum: * An OSGi configuration * A local properties file * OS Env variables * Java System Properties There should be an Felix console plugin to show what is active from what source and where the value is used. It should live in a bundle named like e.g. org.apache.sling.systemenv and provide a simple interface to perform string interpolation on any string. This service can then be used by * Resource resolver * Sling distribution * Context-Aware Configuration a product like AEM can also use this interface in * AEM replication config * externaliser config To have this mechanism properly rolled out it will take some time (until all listed modules properly use the to-defined interface) IMHO it is not an option to do it locally in resourceresolver because a) it would result in quite a bit of duplicated code across the modules listed above (once we actually start implement it) b) if additional sources need to be added in the future (think ZooKeeper as one interesting option to receive those env-specific values), all consumers would have to be updated (unlikely to happen, more likely is to have inconsistent behaviour over time) Since the described above is quite a bit of effort, I opt for pushing a lower-level approach forward (something like [1] or maybe even something on oak level). Then there is only one implementation needed and it's available immediately, everywhere. -Georg [1] https://issues.apache.org/jira/browse/JCRVLT-254
[jira] [Updated] (SLING-7785) Sling Dynamic Include: Allow Caching of Synthetic Resources
[
https://issues.apache.org/jira/browse/SLING-7785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-7785:
---
Fix Version/s: Dynamic Include 3.1.2
> Sling Dynamic Include: Allow Caching of Synthetic Resources
> ---
>
> Key: SLING-7785
> URL: https://issues.apache.org/jira/browse/SLING-7785
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Andreas
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.1.2
>
>
> Due to the need to append the resource type as a suffix for virtual
> resources, AEMs Dispatcher is not able to cache those requests. The
> Dispatcher interprets the URL as having no extension, which makes it
> uncachable. Example:
> {code}
> {code}
> Since Sling also [allows dots in the
> suffix|https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html#examples]
> adding a fake extension is possible to make it cacheable. Allowing to
> configure the extension makes it flexible enough to either use TTL or AEM
> Dispatchers Invalidation with different rules per extension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rombert commented on issue #6: Allow caching of virtual resources
rombert commented on issue #6: Allow caching of virtual resources URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/6#issuecomment-409280544 Looks good to me, thanks for the updates @AndreasWurm . One final request - I applied #5 as i finished its review first. Can you please rebase your commit? After that there should be no issue in applying your PR and starting a release since the other open PRs are kind of stale. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Resolved] (SLING-7742) Sling Dynamic Include Duplicates Selectors When Components are Nested
[
https://issues.apache.org/jira/browse/SLING-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-7742.
Resolution: Fixed
Fixed, thanks a lot [~tomasz.k.niedzwi...@gmail.com] for your contribution!
> Sling Dynamic Include Duplicates Selectors When Components are Nested
> -
>
> Key: SLING-7742
> URL: https://issues.apache.org/jira/browse/SLING-7742
> Project: Sling
> Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Tomasz Niedźwiedź
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Dynamic Include 3.1.2
>
>
>
> I'm using Sling Dynamic Include to optimise the caching of a static site.
> Certain parts of our site are shared across all pages. For example, the
> header is created in one place in the repository and every page that need it,
> includes it using a special component.
> We have configured SDI so that the component is replaced with an SSI tag.
> This works fine and allows us to cache the header as a separate bit of HTML
> on the AEM dispatcher.
> {code:java}
> --SSIncludes> {code}
> In the SDI configuration, we use the {{shared}} selector as the
> {{include-filter.config.selector}} for the particular resource type so when
> the header is included, we get a request to
> {{/content/mysite/en_gb/content/snippets/header.shared.html}}, so far so good.
>
> However, when we introduce another reusable bit of HTML and us it inside the
> header (therefore introducing nested components that are handled by SDI)
> {code:java}
> SSIncludes--> ---SSIncludes---> navigation html>{code}
> the {{shared}} selector is added twice. The page still renders correctly but
> in the request log, as well as the dispatcher cache, we can see
> {{/content/mysite/en_gb/content/snippets/header.shared.html}} (this is fine)
> and
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html}}
> (for instances where the {{mainNavigation}} snippet is used in the header),
> as well as
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.html}} (for
> instances where the {{mainNavigation}} snippet is included by a page
> directly).
>
> This leads to unnecessary caching of the same markup.
>
> While SDI is primarily intended for dynamic components, I think this is a
> valid use case for it.
>
> Before appending the selector determined by the {{filter.config.selector}}
> property, SDI could check if the selector's already present in the selector
> string. That way, we could nest our components, cache them in one spot and
> make the invalidation quite simple.
>
> I've had a stab at solving this in
> [https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5/files],
> the unit tests might actually be a bit clearer than my description above.
> Please let me know what you think.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rombert commented on issue #5: Feature/stop selector duplication
rombert commented on issue #5: Feature/stop selector duplication URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5#issuecomment-409279442 Applied with minor modifications, thanks @toniedzwiedz ! This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[GitHub] rombert closed pull request #5: Feature/stop selector duplication
rombert closed pull request #5: Feature/stop selector duplication
URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/pom.xml b/pom.xml
index 66534c3..5f49db3 100644
--- a/pom.xml
+++ b/pom.xml
@@ -29,7 +29,7 @@
org.apache.sling.dynamic-include
-3.1.1-SNAPSHOT
+3.2.0-SNAPSHOT
bundle
Apache Sling Dynamic Include
diff --git
a/src/main/java/org/apache/sling/dynamicinclude/IncludeTagFilter.java
b/src/main/java/org/apache/sling/dynamicinclude/IncludeTagFilter.java
index c8e33ca..62b64c3 100644
--- a/src/main/java/org/apache/sling/dynamicinclude/IncludeTagFilter.java
+++ b/src/main/java/org/apache/sling/dynamicinclude/IncludeTagFilter.java
@@ -39,11 +39,11 @@
import org.apache.felix.scr.annotations.sling.SlingFilter;
import org.apache.felix.scr.annotations.sling.SlingFilterScope;
import org.apache.sling.api.SlingHttpServletRequest;
-import org.apache.sling.api.request.RequestPathInfo;
import org.apache.sling.api.resource.Resource;
import org.apache.sling.api.resource.ResourceUtil;
import org.apache.sling.dynamicinclude.generator.IncludeGenerator;
import org.apache.sling.dynamicinclude.generator.IncludeGeneratorWhiteboard;
+import org.apache.sling.dynamicinclude.impl.UrlBuilder;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -160,24 +160,9 @@ private String getUrl(Configuration config,
SlingHttpServletRequest request) {
}
private String buildUrl(Configuration config, SlingHttpServletRequest
request) {
-final boolean synthetic =
ResourceUtil.isSyntheticResource(request.getResource());
final Resource resource = request.getResource();
-final StringBuilder builder = new StringBuilder();
-final RequestPathInfo pathInfo = request.getRequestPathInfo();
-
-final String resourcePath = pathInfo.getResourcePath();
-builder.append(resourcePath);
-if (pathInfo.getSelectorString() != null) {
-builder.append('.').append(sanitize(pathInfo.getSelectorString()));
-}
-builder.append('.').append(config.getIncludeSelector());
-builder.append('.').append(pathInfo.getExtension());
-if (synthetic) {
-builder.append('/').append(resource.getResourceType());
-} else {
-builder.append(sanitize(pathInfo.getSuffix()));
-}
-return builder.toString();
+final boolean synthetic =
ResourceUtil.isSyntheticResource(request.getResource());
+return UrlBuilder.buildUrl(config.getIncludeSelector(),
resource.getResourceType(), synthetic, request.getRequestPathInfo());
}
private static String sanitize(String path) {
diff --git a/src/main/java/org/apache/sling/dynamicinclude/impl/UrlBuilder.java
b/src/main/java/org/apache/sling/dynamicinclude/impl/UrlBuilder.java
new file mode 100644
index 000..79338b9
--- /dev/null
+++ b/src/main/java/org/apache/sling/dynamicinclude/impl/UrlBuilder.java
@@ -0,0 +1,54 @@
+/*-
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.sling.dynamicinclude.impl;
+
+import org.apache.commons.lang.StringUtils;
+import org.apache.sling.api.request.RequestPathInfo;
+
+import java.util.Arrays;
+
+public final class UrlBuilder {
+
+
+public static String buildUrl(String includeSelector, String resourceType,
boolean synthetic, RequestPathInfo pathInfo) {
+final StringBuilder builder = new StringBuilder();
+
+final String resourcePath = pathInfo.getResourcePath();
+builder.append(resourcePath);
+String currentSelectorString =
StringUtils.defaultString(pathInfo.getSelectorString());
+if (pathInfo.getSelectorString() != null) {
+builder.append('.').append(currentSelectorString);
+}
+if (includeSelectorNotAlreadyPresent(pathInfo.getSelectors(),
includeSelector)) {
+
[jira] [Updated] (SLING-7742) Sling Dynamic Include Duplicates Selectors When Components are Nested
[
https://issues.apache.org/jira/browse/SLING-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-7742:
---
Fix Version/s: Dynamic Include 3.1.2
> Sling Dynamic Include Duplicates Selectors When Components are Nested
> -
>
> Key: SLING-7742
> URL: https://issues.apache.org/jira/browse/SLING-7742
> Project: Sling
> Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Tomasz Niedźwiedź
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Dynamic Include 3.1.2
>
>
>
> I'm using Sling Dynamic Include to optimise the caching of a static site.
> Certain parts of our site are shared across all pages. For example, the
> header is created in one place in the repository and every page that need it,
> includes it using a special component.
> We have configured SDI so that the component is replaced with an SSI tag.
> This works fine and allows us to cache the header as a separate bit of HTML
> on the AEM dispatcher.
> {code:java}
> --SSIncludes> {code}
> In the SDI configuration, we use the {{shared}} selector as the
> {{include-filter.config.selector}} for the particular resource type so when
> the header is included, we get a request to
> {{/content/mysite/en_gb/content/snippets/header.shared.html}}, so far so good.
>
> However, when we introduce another reusable bit of HTML and us it inside the
> header (therefore introducing nested components that are handled by SDI)
> {code:java}
> SSIncludes--> ---SSIncludes---> navigation html>{code}
> the {{shared}} selector is added twice. The page still renders correctly but
> in the request log, as well as the dispatcher cache, we can see
> {{/content/mysite/en_gb/content/snippets/header.shared.html}} (this is fine)
> and
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html}}
> (for instances where the {{mainNavigation}} snippet is used in the header),
> as well as
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.html}} (for
> instances where the {{mainNavigation}} snippet is included by a page
> directly).
>
> This leads to unnecessary caching of the same markup.
>
> While SDI is primarily intended for dynamic components, I think this is a
> valid use case for it.
>
> Before appending the selector determined by the {{filter.config.selector}}
> property, SDI could check if the selector's already present in the selector
> string. That way, we could nest our components, cache them in one spot and
> make the invalidation quite simple.
>
> I've had a stab at solving this in
> [https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5/files],
> the unit tests might actually be a bit clearer than my description above.
> Please let me know what you think.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7742) Sling Dynamic Include Duplicates Selectors When Components are Nested
[
https://issues.apache.org/jira/browse/SLING-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-7742:
---
Affects Version/s: (was: Dynamic Include 3.1.2)
Dynamic Include 3.1.0
> Sling Dynamic Include Duplicates Selectors When Components are Nested
> -
>
> Key: SLING-7742
> URL: https://issues.apache.org/jira/browse/SLING-7742
> Project: Sling
> Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Tomasz Niedźwiedź
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Dynamic Include 3.1.2
>
>
>
> I'm using Sling Dynamic Include to optimise the caching of a static site.
> Certain parts of our site are shared across all pages. For example, the
> header is created in one place in the repository and every page that need it,
> includes it using a special component.
> We have configured SDI so that the component is replaced with an SSI tag.
> This works fine and allows us to cache the header as a separate bit of HTML
> on the AEM dispatcher.
> {code:java}
> --SSIncludes> {code}
> In the SDI configuration, we use the {{shared}} selector as the
> {{include-filter.config.selector}} for the particular resource type so when
> the header is included, we get a request to
> {{/content/mysite/en_gb/content/snippets/header.shared.html}}, so far so good.
>
> However, when we introduce another reusable bit of HTML and us it inside the
> header (therefore introducing nested components that are handled by SDI)
> {code:java}
> SSIncludes--> ---SSIncludes---> navigation html>{code}
> the {{shared}} selector is added twice. The page still renders correctly but
> in the request log, as well as the dispatcher cache, we can see
> {{/content/mysite/en_gb/content/snippets/header.shared.html}} (this is fine)
> and
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html}}
> (for instances where the {{mainNavigation}} snippet is used in the header),
> as well as
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.html}} (for
> instances where the {{mainNavigation}} snippet is included by a page
> directly).
>
> This leads to unnecessary caching of the same markup.
>
> While SDI is primarily intended for dynamic components, I think this is a
> valid use case for it.
>
> Before appending the selector determined by the {{filter.config.selector}}
> property, SDI could check if the selector's already present in the selector
> string. That way, we could nest our components, cache them in one spot and
> make the invalidation quite simple.
>
> I've had a stab at solving this in
> [https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5/files],
> the unit tests might actually be a bit clearer than my description above.
> Please let me know what you think.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7742) Sling Dynamic Include Duplicates Selectors When Components are Nested
[
https://issues.apache.org/jira/browse/SLING-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned SLING-7742:
--
Assignee: Robert Munteanu
> Sling Dynamic Include Duplicates Selectors When Components are Nested
> -
>
> Key: SLING-7742
> URL: https://issues.apache.org/jira/browse/SLING-7742
> Project: Sling
> Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Tomasz Niedźwiedź
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Dynamic Include 3.1.2
>
>
>
> I'm using Sling Dynamic Include to optimise the caching of a static site.
> Certain parts of our site are shared across all pages. For example, the
> header is created in one place in the repository and every page that need it,
> includes it using a special component.
> We have configured SDI so that the component is replaced with an SSI tag.
> This works fine and allows us to cache the header as a separate bit of HTML
> on the AEM dispatcher.
> {code:java}
> --SSIncludes> {code}
> In the SDI configuration, we use the {{shared}} selector as the
> {{include-filter.config.selector}} for the particular resource type so when
> the header is included, we get a request to
> {{/content/mysite/en_gb/content/snippets/header.shared.html}}, so far so good.
>
> However, when we introduce another reusable bit of HTML and us it inside the
> header (therefore introducing nested components that are handled by SDI)
> {code:java}
> SSIncludes--> ---SSIncludes---> navigation html>{code}
> the {{shared}} selector is added twice. The page still renders correctly but
> in the request log, as well as the dispatcher cache, we can see
> {{/content/mysite/en_gb/content/snippets/header.shared.html}} (this is fine)
> and
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.shared.html}}
> (for instances where the {{mainNavigation}} snippet is used in the header),
> as well as
> {{/content/mysite/en_gb/content/snippets/mainNavigation.shared.html}} (for
> instances where the {{mainNavigation}} snippet is included by a page
> directly).
>
> This leads to unnecessary caching of the same markup.
>
> While SDI is primarily intended for dynamic components, I think this is a
> valid use case for it.
>
> Before appending the selector determined by the {{filter.config.selector}}
> property, SDI could check if the selector's already present in the selector
> string. That way, we could nest our components, cache them in one spot and
> make the invalidation quite simple.
>
> I've had a stab at solving this in
> [https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/5/files],
> the unit tests might actually be a bit clearer than my description above.
> Please let me know what you think.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7785) Sling Dynamic Include: Allow Caching of Synthetic Resources
[
https://issues.apache.org/jira/browse/SLING-7785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned SLING-7785:
--
Assignee: Robert Munteanu
> Sling Dynamic Include: Allow Caching of Synthetic Resources
> ---
>
> Key: SLING-7785
> URL: https://issues.apache.org/jira/browse/SLING-7785
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Dynamic Include 3.1.0
>Reporter: Andreas
>Assignee: Robert Munteanu
>Priority: Major
>
> Due to the need to append the resource type as a suffix for virtual
> resources, AEMs Dispatcher is not able to cache those requests. The
> Dispatcher interprets the URL as having no extension, which makes it
> uncachable. Example:
> {code}
> {code}
> Since Sling also [allows dots in the
> suffix|https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html#examples]
> adding a fake extension is possible to make it cacheable. Allowing to
> configure the extension makes it flexible enough to either use TTL or AEM
> Dispatchers Invalidation with different rules per extension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations
Thanks Tommaso for your feedback, very appreciated! I forgot to mention that @SlingFilter is also already supported, it can be helpful let people (developers/managers/testers/...) know what's going on the system, WDYT... could it be interesting also for debugging purposes, making people aware what happens to requests? TIA! ~Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 31, 2018 at 5:51 PM Tommaso Teofili wrote: > Thanks Simo, > > I think the idea is very interesting! > When browsing source code, especially on github, that should help people > better understand what components / services / etc. are doing. > Being Sling a big project I think this is especially useful when browsing > through portions of the code / bundles you are not using / developing > frequently. > > My 2 cents, > Tommaso > > > Il giorno mar 31 lug 2018 alle ore 17:10 Robert Munteanu < > romb...@apache.org> > ha scritto: > > > Hi Simo, > > > > On Tue, 2018-07-31 at 14:06 +0200, Simone Tripodi wrote: > > > Hi all, > > > due to a private need I implemented a tool that, as a Sling > > > committer, I > > > would like to promote inside this community in order to have it as a > > > public > > > domain. > > > > > > The basic idea is to automate the production of documentation, > > > providing to > > > both developers and customers a centralised documentation of all HTTP > > > entry > > > points and Metatype configurations. > > > > This looks nice, thanks for bringing it up for discussion. I think we > > could use a tool to enhance documentation for Sling. > > > > A couple of notes/questions: > > > > 1. The sample markdown output is wrapped, it would be more useful if > > attached as a plain-text file. > > > > 2. Is there any support for removing certain classes or properties from > > the output? I can see situations where we don't want to expose > > something, based on whether it's deprecated or internal. > > > > 3. Is there support (or planned support) for adding additional data to > > the output? I think a plain descriptive output for a certain component > > is good, but it might be useful to complement it with other > > information, such as a free-text description. > > > > 4. Does this tool depend on Sling in any matter? Briefly looking over > > your email it looks like it builds on top of the OSGi annotations ( + > > Felix/Sling specific ones ) so it could also potentially find a home in > > the Felix project. > > > > Thanks! > > > > Robert > > > > >
Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations
Thanks Simo, I think the idea is very interesting! When browsing source code, especially on github, that should help people better understand what components / services / etc. are doing. Being Sling a big project I think this is especially useful when browsing through portions of the code / bundles you are not using / developing frequently. My 2 cents, Tommaso Il giorno mar 31 lug 2018 alle ore 17:10 Robert Munteanu ha scritto: > Hi Simo, > > On Tue, 2018-07-31 at 14:06 +0200, Simone Tripodi wrote: > > Hi all, > > due to a private need I implemented a tool that, as a Sling > > committer, I > > would like to promote inside this community in order to have it as a > > public > > domain. > > > > The basic idea is to automate the production of documentation, > > providing to > > both developers and customers a centralised documentation of all HTTP > > entry > > points and Metatype configurations. > > This looks nice, thanks for bringing it up for discussion. I think we > could use a tool to enhance documentation for Sling. > > A couple of notes/questions: > > 1. The sample markdown output is wrapped, it would be more useful if > attached as a plain-text file. > > 2. Is there any support for removing certain classes or properties from > the output? I can see situations where we don't want to expose > something, based on whether it's deprecated or internal. > > 3. Is there support (or planned support) for adding additional data to > the output? I think a plain descriptive output for a certain component > is good, but it might be useful to complement it with other > information, such as a free-text description. > > 4. Does this tool depend on Sling in any matter? Briefly looking over > your email it looks like it builds on top of the OSGi annotations ( + > Felix/Sling specific ones ) so it could also potentially find a home in > the Felix project. > > Thanks! > > Robert > >
Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations
Hi there Rob, thank you so much for your interest, very appreciated! Please read my inline replies, in order to have a better readability. Have a great day, all the best! ~Simo http://people.apache.org/~simonetripodi/ On Tue, Jul 31, 2018 at 5:10 PM Robert Munteanu wrote: > Hi Simo, > > On Tue, 2018-07-31 at 14:06 +0200, Simone Tripodi wrote: > > Hi all, > > due to a private need I implemented a tool that, as a Sling > > committer, I > > would like to promote inside this community in order to have it as a > > public > > domain. > > > > The basic idea is to automate the production of documentation, > > providing to > > both developers and customers a centralised documentation of all HTTP > > entry > > points and Metatype configurations. > > This looks nice, thanks for bringing it up for discussion. I think we > could use a tool to enhance documentation for Sling. > > A couple of notes/questions: > > 1. The sample markdown output is wrapped, it would be more useful if > attached as a plain-text file. > please have a look at the following public gists! * created output files: https://gist.github.com/simonetripodi/7f4d0ecaf697c222afc1ec89dac55f47 * a Metatype sample file: https://gist.github.com/simonetripodi/7664657ff3b00577b0c7bc78f6b20492 * servlet sample file: https://gist.github.com/simonetripodi/1b8f57f27b6b5f7c2792b3540d8c0230 > > 2. Is there any support for removing certain classes or properties from > the output? I can see situations where we don't want to expose > something, based on whether it's deprecated or internal. > > Properties marked as "private" are skipped already and not shown in the final report, I did not added a way to skip classes - guess I am still in time in order to add such support! :P > 3. Is there support (or planned support) for adding additional data to > the output? I think a plain descriptive output for a certain component > is good, but it might be useful to complement it with other > information, such as a free-text description. > I think it wouldn't be hard adding such feature - please take also in consideration that description field is present to almost all supported annotations, but adding an additional input where getting extra text is something we can integrate > > 4. Does this tool depend on Sling in any matter? Briefly looking over > your email it looks like it builds on top of the OSGi annotations ( + > Felix/Sling specific ones ) so it could also potentially find a home in > the Felix project. > > There is no direct dependency to Sling in any way, excluding the @SlingServlet annotation, the tool imports just a couple of utility dependencies. I have no karma in Felix but, given a wider general purpose of this tool -it can potentially include other stuff- I would suggest to Sling having a home to host the "docgen", while Felix is more OSGi-focused, WDYT? I have a couple of questions from my side: * do I need to publish the sourcecode to a public personal or Apache repo? * does my company needs to sign the CLA for this component? TIA! ~Simo > Thanks! > > Robert > >
Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations
Hi Simo, On Tue, 2018-07-31 at 14:06 +0200, Simone Tripodi wrote: > Hi all, > due to a private need I implemented a tool that, as a Sling > committer, I > would like to promote inside this community in order to have it as a > public > domain. > > The basic idea is to automate the production of documentation, > providing to > both developers and customers a centralised documentation of all HTTP > entry > points and Metatype configurations. This looks nice, thanks for bringing it up for discussion. I think we could use a tool to enhance documentation for Sling. A couple of notes/questions: 1. The sample markdown output is wrapped, it would be more useful if attached as a plain-text file. 2. Is there any support for removing certain classes or properties from the output? I can see situations where we don't want to expose something, based on whether it's deprecated or internal. 3. Is there support (or planned support) for adding additional data to the output? I think a plain descriptive output for a certain component is good, but it might be useful to complement it with other information, such as a free-text description. 4. Does this tool depend on Sling in any matter? Briefly looking over your email it looks like it builds on top of the OSGi annotations ( + Felix/Sling specific ones ) so it could also potentially find a home in the Felix project. Thanks! Robert
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.4 and JCR Resource 3.0.14
+1 On Tue, Jul 31, 2018 at 10:19 AM Robert Munteanu wrote: > On Tue, 2018-07-31 at 14:32 +0200, Carsten Ziegeler wrote: > > Please vote to approve this release: > > +1 > > Robert >
[jira] [Resolved] (SLING-7699) Add ability to stream a Resource tree to Sling
[ https://issues.apache.org/jira/browse/SLING-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey resolved SLING-7699. --- Resolution: Fixed > Add ability to stream a Resource tree to Sling > -- > > Key: SLING-7699 > URL: https://issues.apache.org/jira/browse/SLING-7699 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: Resource Filter 1.0.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Add an ability to stream a Resource tree starting from a specific resource -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.4 and JCR Resource 3.0.14
On Tue, 2018-07-31 at 14:32 +0200, Carsten Ziegeler wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[GitHub] kwin closed pull request #2: SLING-7744: Allow Setting Suffix Resource
kwin closed pull request #2: SLING-7744: Allow Setting Suffix Resource
URL: https://github.com/apache/sling-org-apache-sling-servlet-helpers/pull/2
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/servlethelpers/MockRequestPathInfo.java
b/src/main/java/org/apache/sling/servlethelpers/MockRequestPathInfo.java
index d14034c..9179b94 100644
--- a/src/main/java/org/apache/sling/servlethelpers/MockRequestPathInfo.java
+++ b/src/main/java/org/apache/sling/servlethelpers/MockRequestPathInfo.java
@@ -33,6 +33,7 @@
private String resourcePath;
private String selectorString;
private String suffix;
+private Resource suffixResource;
@Override
public String getExtension() {
@@ -79,10 +80,13 @@ public void setSuffix(final String suffix) {
this.suffix = suffix;
}
-// --- unsupported operations ---
+public void setSuffixResource(final Resource suffixResource) {
+this.suffixResource = suffixResource;
+}
+
@Override
public Resource getSuffixResource() {
-throw new UnsupportedOperationException();
+return this.suffixResource;
}
}
diff --git
a/src/test/java/org/apache/sling/servlethelpers/MockRequestPathInfoTest.java
b/src/test/java/org/apache/sling/servlethelpers/MockRequestPathInfoTest.java
index 4a6b15b..15737a3 100644
--- a/src/test/java/org/apache/sling/servlethelpers/MockRequestPathInfoTest.java
+++ b/src/test/java/org/apache/sling/servlethelpers/MockRequestPathInfoTest.java
@@ -21,7 +21,10 @@
import static org.junit.Assert.assertArrayEquals;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertSame;
+import static org.mockito.Mockito.mock;
+import org.apache.sling.api.resource.Resource;
import org.junit.Before;
import org.junit.Test;
@@ -65,4 +68,12 @@ public void testSuffix() {
assertEquals("/suffix", this.requestPathInfo.getSuffix());
}
+@Test
+public void testSuffixResource() {
+assertNull(this.requestPathInfo.getSuffixResource());
+Resource mockResource = mock(Resource.class);
+this.requestPathInfo.setSuffixResource(mockResource);
+assertSame(mockResource, this.requestPathInfo.getSuffixResource());
+}
+
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
[GitHub] kwin commented on issue #2: SLING-7744: Allow Setting Suffix Resource
kwin commented on issue #2: SLING-7744: Allow Setting Suffix Resource URL: https://github.com/apache/sling-org-apache-sling-servlet-helpers/pull/2#issuecomment-409227205 This has been implemented in a slightly different way in https://github.com/apache/sling-org-apache-sling-servlet-helpers/commit/825f4486404944a41a7f552945a346cee8bfe2cf. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Resolved] (SLING-7795) Get Servlets - JsonGenerator may not close properly on exception
[ https://issues.apache.org/jira/browse/SLING-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey resolved SLING-7795. --- Resolution: Fixed > Get Servlets - JsonGenerator may not close properly on exception > > > Key: SLING-7795 > URL: https://issues.apache.org/jira/browse/SLING-7795 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: Servlets Get 2.1.34 > > > During the json rendering an exception may cause the JsonGenerator to never > close. This could occur in the SlingInfoServlet and the JsonRenderer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7795) Get Servlets - JsonGenerator may not close properly on exception
[ https://issues.apache.org/jira/browse/SLING-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey updated SLING-7795: -- Issue Type: Bug (was: Improvement) > Get Servlets - JsonGenerator may not close properly on exception > > > Key: SLING-7795 > URL: https://issues.apache.org/jira/browse/SLING-7795 > Project: Sling > Issue Type: Bug >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: Servlets Get 2.1.34 > > > During the json rendering an exception may cause the JsonGenerator to never > close. This could occur in the SlingInfoServlet and the JsonRenderer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7795) Get Servlets - JsonGenerator may not close properly on exception
Jason E Bailey created SLING-7795: - Summary: Get Servlets - JsonGenerator may not close properly on exception Key: SLING-7795 URL: https://issues.apache.org/jira/browse/SLING-7795 Project: Sling Issue Type: Improvement Reporter: Jason E Bailey Assignee: Jason E Bailey Fix For: Servlets Get 2.1.34 During the json rendering an exception may cause the JsonGenerator to never close. This could occur in the SlingInfoServlet and the JsonRenderer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [VOTE] Release Apache Sling Resource Resolver 1.6.4 and JCR Resource 3.0.14
+1
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.4 and JCR Resource 3.0.14
+1 Carsten Ziegeler wrote > This release updates the two modules to the recently released API 2.18.2 > > We solved two issues in JCR Resource 3.0.14 > https://issues.apache.org/jira/projects/SLING/versions/12343800 > > We solved two issues in Resource Resolver 1.6.4 > https://issues.apache.org/jira/projects/SLING/versions/12343077 > (There are still two open issues which are moved to 1.6.6, these issues > already existed in 1.6.0) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1927/ > > 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 1927 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards > Carsten > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Sling Resource Resolver 1.6.4 and JCR Resource 3.0.14
This release updates the two modules to the recently released API 2.18.2 We solved two issues in JCR Resource 3.0.14 https://issues.apache.org/jira/projects/SLING/versions/12343800 We solved two issues in Resource Resolver 1.6.4 https://issues.apache.org/jira/projects/SLING/versions/12343077 (There are still two open issues which are moved to 1.6.6, these issues already existed in 1.6.0) Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1927/ 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 1927 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE CANCEL] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
Sure, reverted in c11a78e155e3eddc963423e199fbbd8566d6a9b7 . Thanks, Robert On Tue, 2018-07-31 at 14:14 +0200, Carsten Ziegeler wrote: > Thanks Robert, > > I didn't realize this either - so let's cancel the vote. > > Could you please take care of reverting? > > Thanks > > Carsten > > > Robert Munteanu wrote > > Hi Carsten, > > > > On Tue, 2018-07-31 at 08:06 +0200, Carsten Ziegeler wrote: > > > We solved two issues in Resource Resolver 1.6.2 > > > https://issues.apache.org/jira/projects/SLING/versions/12343077 > > > (There are still two open issues which are moved to 1.6.4, these > > > issues > > > already existed in 1.6.0) > > > > I realise I have overlooked > > https://issues.apache.org/jira/browse/SLING-7544 , which introduces > > "a > > potential race when new aliases get added while the intialization > > was > > still running" . This did not exist in previous relelases. > > > > Unfortunately I failed to either: > > > > a) revert the commit > > b) find the time to review/propose a solution for the race > > condition > > > > But I'm not sure if we should go through with a release like this > > or > > revert the initial commit and then re-run the release. > > > > Sorry about the complications, > > > > Robert > >
[jira] [Commented] (SLING-7792) Resource Resolver should return more than one resolved path if available
[
https://issues.apache.org/jira/browse/SLING-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563563#comment-16563563
]
Carsten Ziegeler commented on SLING-7792:
-
Sounds good to me and I agree a separate service makes sense.
In that case we should probably put it into a separate package which will
allows us to evolve it easier
> Resource Resolver should return more than one resolved path if available
>
>
> Key: SLING-7792
> URL: https://issues.apache.org/jira/browse/SLING-7792
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.6.0
>Reporter: Alex COLLIGNON
>Priority: Major
>
> The current {{ResourceResolver#map}} methods return a single "path mapped
> from the (resource) path". However, it is possible than a given path can be
> mapped to multiple others while using features such as {{sling:alias}} and
> {{sling:vanityUrl}}.
> In order to support that scenario, it is require to implement new maps method
> for {{ResourceResolver}} which returns a collection of "resolved path". This
> collection must contain the resources mapped through {{/etc/map}},
> {{sling:alias}} and {{sling:vanityUrl}}.
> The current API suggests to implement a second method to be
> consistent/symmetric with the existing map operations
> {quote}
> @Nonnull java.util.Collection maps(@Nonnull
> java.lang.String resourcePath)
> @Nonnull java.util.Collection maps(@Nonnull
> javax.servlet.http.HttpServletRequest request, @Nonnull java.lang.String
> resourcePath)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[VOTE CANCEL] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
Thanks Robert, I didn't realize this either - so let's cancel the vote. Could you please take care of reverting? Thanks Carsten Robert Munteanu wrote > Hi Carsten, > > On Tue, 2018-07-31 at 08:06 +0200, Carsten Ziegeler wrote: >> We solved two issues in Resource Resolver 1.6.2 >> https://issues.apache.org/jira/projects/SLING/versions/12343077 >> (There are still two open issues which are moved to 1.6.4, these >> issues >> already existed in 1.6.0) > > I realise I have overlooked > https://issues.apache.org/jira/browse/SLING-7544 , which introduces "a > potential race when new aliases get added while the intialization was > still running" . This did not exist in previous relelases. > > Unfortunately I failed to either: > > a) revert the commit > b) find the time to review/propose a solution for the race condition > > But I'm not sure if we should go through with a release like this or > revert the initial commit and then re-run the release. > > Sorry about the complications, > > Robert > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[PROPOSAL] Donating a tool able to generate markdown documentation from annotations
Hi all, due to a private need I implemented a tool that, as a Sling committer, I would like to promote inside this community in order to have it as a public domain. The basic idea is to automate the production of documentation, providing to both developers and customers a centralised documentation of all HTTP entry points and Metatype configurations. Advantages are: * for an internal use, having such catalogue could reduce the development efforts, maybe there are services already available for certain operations that don’t need to be re-implemented; moreover, it can improve/simplify heterogeneous teams integration work. * from customers point of view, it would be good to know what solutions are already offered, to develop their solution on top of our framework; moreover, under a security PoV, admins have to be aware which are potential entry-points that can be attacked. How it works: it is a plain Java8 annotations processor, able to generate documentations for: * SlingServlet annotated components; * (Deprecated) Felix SCR annotations (we still have lot of components in the repo which use such annotations, i.e. Apache Sling Distribution Core) * OSGi Component/Metatype annotations All documentations are produced in Markdown format (intermediate metadata formats are produced already by existing Maven plugins, so no XML/JSON/YAML/...) and I tested initially in the org-apache-sling-distribution-core[1], producing the output below: sling-org-apache-sling-distribution-core stripodi$ tree target/docgen/ target/docgen/ ├── metatype │ └── org │ └── apache │ └── sling │ └── distribution │ ├── agent │ │ └── impl │ │ ├── ForwardDistributionAgentFactory.md │ │ ├── PrivilegeDistributionRequestAuthorizationStrategyFactory.md │ │ ├── QueueDistributionAgentFactory.md │ │ ├── ReverseDistributionAgentFactory.md │ │ ├── SimpleDistributionAgentFactory.md │ │ └── SyncDistributionAgentFactory.md │ ├── component │ │ └── impl │ │ ├── DefaultDistributionComponentProvider.md │ │ ├── DefaultDistributionConfigurationManager.md │ │ └── DistributionComponentFactoryMap.md │ ├── event │ │ └── impl │ │ └── DefaultDistributionEventFactory.md │ ├── impl │ │ └── DefaultDistributor.md │ ├── monitor │ │ └── DistributionQueueHealthCheck.md │ ├── packaging │ │ └── impl │ │ ├── exporter │ │ │ ├── AgentDistributionPackageExporterFactory.md │ │ │ ├── LocalDistributionPackageExporterFactory.md │ │ │ └── RemoteDistributionPackageExporterFactory.md │ │ └── importer │ │ ├── LocalDistributionPackageImporterFactory.md │ │ ├── RemoteDistributionPackageImporterFactory.md │ │ └── RepositoryDistributionPackageImporterFactory.md │ ├── resources │ │ └── impl │ │ ├── DistributionConfigurationResourceProviderFactory.md │ │ └── DistributionServiceResourceProviderFactory.md │ ├── serialization │ │ └── impl │ │ ├── DefaultDistributionPackageBuilderProvider.md │ │ ├── DistributionPackageBuilderFactory.md │ │ └── vlt │ │ └── VaultDistributionPackageBuilderFactory.md │ ├── servlet │ │ └── DistributionAgentCreationFilter.md │ ├── transport │ │ └── impl │ │ └── UserCredentialsDistributionTransportSecretProvider.md │ └── trigger │ └── impl │ ├── DistributionEventDistributeDistributionTriggerFactory.md │ ├── JcrEventDistributionTriggerFactory.md │ ├── PersistedJcrEventDistributionTriggerFactory.md │ ├── RemoteEventDistributionTriggerFactory.md │ ├── ResourceEventDistributionTriggerFactory.md │ └── ScheduledDistributionTriggerFactory.md └── servlets └── org └── apache └── sling └── distribution └── servlet ├── DistributionAgentLogServlet.md ├── DistributionAgentQueueServlet.md
[jira] [Resolved] (SLING-7712) sling-mock: make register Sling Models from classpath optional
[
https://issues.apache.org/jira/browse/SLING-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7712.
---
Resolution: Fixed
Fix Version/s: Testing Sling Mock 2.2.20
i've added a new flag to the SlingContextBuilder which allows to disable
automatic registration of sling models from the classpath - example:
{code:java}
@Rule
public SlingContext context = new SlingContextBuilder()
.registerSlingModelsFromClassPath(false)
.build();
{code}
implemented in
https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/8415c24609e6c40b59d2227038b9a8e5766f7a21
> sling-mock: make register Sling Models from classpath optional
> --
>
> Key: SLING-7712
> URL: https://issues.apache.org/jira/browse/SLING-7712
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing Sling Mock 1.9.12, Testing Sling Mock 2.2.18
>Reporter: Andrey Bardashevsky
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing Sling Mock 2.2.20
>
>
> Registering all sling models from classpath leads to slow down tests
> dramatically.
> Steps to reproduce:
> # Register several models.
> # In context.afterSetup() register several custom injetors that implements
> StaticInjectAnnotationProcessorFactory
> Each injector registration leads to update every model (ModelAdapterFactory)
> that slow downs test dramatically, when you have 300+ models and 5-6
> injectors that register in setup method before each test.
> Workaround is to register injectors before models.
> Please implement optional registration all sling models from classpath.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
Hi Carsten, On Tue, 2018-07-31 at 08:06 +0200, Carsten Ziegeler wrote: > We solved two issues in Resource Resolver 1.6.2 > https://issues.apache.org/jira/projects/SLING/versions/12343077 > (There are still two open issues which are moved to 1.6.4, these > issues > already existed in 1.6.0) I realise I have overlooked https://issues.apache.org/jira/browse/SLING-7544 , which introduces "a potential race when new aliases get added while the intialization was still running" . This did not exist in previous relelases. Unfortunately I failed to either: a) revert the commit b) find the time to review/propose a solution for the race condition But I'm not sure if we should go through with a release like this or revert the initial commit and then re-run the release. Sorry about the complications, Robert
[jira] [Assigned] (SLING-7712) sling-mock: make register Sling Models from classpath optional
[ https://issues.apache.org/jira/browse/SLING-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-7712: - Assignee: Stefan Seifert Summary: sling-mock: make register Sling Models from classpath optional (was: slig-mock: make register Sling Models from classpath optionaly) wouldn't it be better to register the custom injectors in context.beforeSetup()? nevertheless i makes sense to make the automatic registration of models from the classpath configurable (default: activated) when they are huge number of models. > sling-mock: make register Sling Models from classpath optional > -- > > Key: SLING-7712 > URL: https://issues.apache.org/jira/browse/SLING-7712 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 1.9.12, Testing Sling Mock 2.2.18 >Reporter: Andrey Bardashevsky >Assignee: Stefan Seifert >Priority: Major > > Registering all sling models from classpath leads to slow down tests > dramatically. > Steps to reproduce: > # Register several models. > # In context.afterSetup() register several custom injetors that implements > StaticInjectAnnotationProcessorFactory > Each injector registration leads to update every model (ModelAdapterFactory) > that slow downs test dramatically, when you have 300+ models and 5-6 > injectors that register in setup method before each test. > Workaround is to register injectors before models. > Please implement optional registration all sling models from classpath. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7204) OSGi R6 annotations: default value of an empty array is propagated as null
[
https://issues.apache.org/jira/browse/SLING-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7204.
---
Resolution: Won't Fix
yes
> OSGi R6 annotations: default value of an empty array is propagated as null
> --
>
> Key: SLING-7204
> URL: https://issues.apache.org/jira/browse/SLING-7204
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.4
>Reporter: Robert Munteanu
>Priority: Major
>
> I'm conferting some of the Oak code to use the OSGi R6 annotations. I have a
> config that declares a String[] property which defaults to empty, along the
> lines of:
> {code:java}
> @Component(configurationPolicy = ConfigurationPolicy.REQUIRE)
> public class CompositeNodeStoreService {
> static @interface Configuration {
>
> /**
> * Writes to these read-only paths won't fail the commit
> */
> String[] ignoreReadOnlyWrites() default {};
> }
> @Activate
> protected void activate(Configuration cfg, ComponentContext context)
> throws IOException, CommitFailedException {
> ignoreReadOnlyWritePaths = cfg.ignoreReadOnlyWrites()
> {code}
> In a unit test this should default to an empty array, but instead it is null.
> I checked the generated SCR descriptors, and the property is missing. If I
> add a property to the default value, the property appears in the SCR
> descriptor. Maybe a behaviour change in newer revisions of SCR?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7744) MockRequestPathInfo: Implement getSuffixResource()
[
https://issues.apache.org/jira/browse/SLING-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7744.
---
Resolution: Fixed
Fix Version/s: Servlet Helpers 1.1.8
> MockRequestPathInfo: Implement getSuffixResource()
> --
>
> Key: SLING-7744
> URL: https://issues.apache.org/jira/browse/SLING-7744
> Project: Sling
> Issue Type: Improvement
> Components: Servlets, Testing
>Affects Versions: Servlet Helpers 1.1.6
>Reporter: Jens Lauterbach
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Servlet Helpers 1.1.8
>
> Attachments: SLING-7744.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The {{org.apache.sling.servlethelpers.MockRequestPathInfo}} allows consumers
> to set almost every field except the {{suffixResource}}. Currently, the
> {{getSuffixResource()}} just throws a {{UnsupportedOperationException}}.
> *I propose implementing a {{setSuffixResource}} method equivalent to all the
> other setters in this mock.*
> As far as I can tell this can be easily implemented (see attached patch) and
> would improve usability of this mock a little bit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7744) MockRequestPathInfo: Add Setter for SuffixResource
[
https://issues.apache.org/jira/browse/SLING-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-7744:
-
Assignee: Stefan Seifert
i've added an implementation for getSuffixResource() to fetch the resource
based on the suffix via resource resolver (as it is the case for the real
implementation)
https://github.com/apache/sling-org-apache-sling-servlet-helpers/commit/825f4486404944a41a7f552945a346cee8bfe2cf
> MockRequestPathInfo: Add Setter for SuffixResource
> --
>
> Key: SLING-7744
> URL: https://issues.apache.org/jira/browse/SLING-7744
> Project: Sling
> Issue Type: Improvement
> Components: Servlets, Testing
>Affects Versions: Servlet Helpers 1.1.6
>Reporter: Jens Lauterbach
>Assignee: Stefan Seifert
>Priority: Minor
> Attachments: SLING-7744.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The {{org.apache.sling.servlethelpers.MockRequestPathInfo}} allows consumers
> to set almost every field except the {{suffixResource}}. Currently, the
> {{getSuffixResource()}} just throws a {{UnsupportedOperationException}}.
> *I propose implementing a {{setSuffixResource}} method equivalent to all the
> other setters in this mock.*
> As far as I can tell this can be easily implemented (see attached patch) and
> would improve usability of this mock a little bit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7687) Some Adapters don't work during service deactivation
[
https://issues.apache.org/jira/browse/SLING-7687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7687.
---
Resolution: Fixed
Fix Version/s: Testing Sling Mock 2.2.20
patch applied
https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/944c00112bc64a103715d06c3bbb53723fe57020
> Some Adapters don't work during service deactivation
>
>
> Key: SLING-7687
> URL: https://issues.apache.org/jira/browse/SLING-7687
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing Sling Mock 2.2.18
>Reporter: Arneh Jain
>Assignee: Stefan Seifert
>Priority: Major
> Labels: mocks
> Fix For: Testing Sling Mock 2.2.20
>
> Attachments: patch.txt
>
>
> If we have an AdapterFactory and a Service registered by the following code:
>
> {code:java}
> // code placeholder
> SlingContext context = new SlingContext();
> context.registerInjectActivateService(new TestAdapterFactory());
> context.registerInjectActivateService(new TestService());{code}
> it turns out that adapting a Resource to another Class (defined by the
> TestAdapterFactory) returns null when done in the deactivate method of the
> TestService, i.e.
>
> {code:java}
> resource.adaptTo(TestClass.class) // returns null in the deactivate method.
> resource.adaptTo(TestClass.class) // works correctly in any other
> method.{code}
>
> Reason:
> It looks like the registered adapters are cleaned up before registered
> services are deactivated in the tearDown method of SlingContextImpl.
>
> {code:java}
> // SlingContextImpl
> void tearDown() {
> ...
> MockSling.clearAdapterManagerBundleContext();
> ...
> super.tearDown(); // calls the deactivate of the registered services.
> }{code}
>
>
> Cleaning up the registered adapters after deactivating the services seems to
> solve the issue.
> {code:java}
> // SlingContextImpl
> void tearDown() {
> ...
> super.tearDown();
> MockSling.clearAdapterManagerBundleContext();
> }
> {code}
> but I'm not sure about any other potential impacts of this change (attached
> patch).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7687) Some Adapters don't work during service deactivation
[
https://issues.apache.org/jira/browse/SLING-7687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-7687:
-
Assignee: Stefan Seifert
> Some Adapters don't work during service deactivation
>
>
> Key: SLING-7687
> URL: https://issues.apache.org/jira/browse/SLING-7687
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing Sling Mock 2.2.18
>Reporter: Arneh Jain
>Assignee: Stefan Seifert
>Priority: Major
> Labels: mocks
> Attachments: patch.txt
>
>
> If we have an AdapterFactory and a Service registered by the following code:
>
> {code:java}
> // code placeholder
> SlingContext context = new SlingContext();
> context.registerInjectActivateService(new TestAdapterFactory());
> context.registerInjectActivateService(new TestService());{code}
> it turns out that adapting a Resource to another Class (defined by the
> TestAdapterFactory) returns null when done in the deactivate method of the
> TestService, i.e.
>
> {code:java}
> resource.adaptTo(TestClass.class) // returns null in the deactivate method.
> resource.adaptTo(TestClass.class) // works correctly in any other
> method.{code}
>
> Reason:
> It looks like the registered adapters are cleaned up before registered
> services are deactivated in the tearDown method of SlingContextImpl.
>
> {code:java}
> // SlingContextImpl
> void tearDown() {
> ...
> MockSling.clearAdapterManagerBundleContext();
> ...
> super.tearDown(); // calls the deactivate of the registered services.
> }{code}
>
>
> Cleaning up the registered adapters after deactivating the services seems to
> solve the issue.
> {code:java}
> // SlingContextImpl
> void tearDown() {
> ...
> super.tearDown();
> MockSling.clearAdapterManagerBundleContext();
> }
> {code}
> but I'm not sure about any other potential impacts of this change (attached
> patch).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
RE: [VOTE] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
+1
[jira] [Resolved] (SLING-7794) osgi-mock: Dynamic reference properties
[
https://issues.apache.org/jira/browse/SLING-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7794.
---
Resolution: Fixed
thanks for the contribution! - i've applied the PR with a cosmetic modification
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/dbfffe91d6e2a1b640a19d73cfae62826690129d
> osgi-mock: Dynamic reference properties
> ---
>
> Key: SLING-7794
> URL: https://issues.apache.org/jira/browse/SLING-7794
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 2.3.10
>
>
> [PR
> #3|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/3]
> from [badfish69|https://github.com/badfish69]:
> {quote}
> This is a pull request to add support for correct resolution of SCR
> references where the target filter is provided via service properties rather
> than being hard-coded into the metadata.
> e.g. if you have code like this
> {code:java}
> @reference
> MyClass myClass
> {code}
> The OSGI spec allows for the target service to be filtered via a property:
> myClass.target, which provides a runtime equivalent to the
> @reference(target=filter) static way of doing it.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] stefanseifert closed pull request #3: Dynamic reference properties
stefanseifert closed pull request #3: Dynamic reference properties
URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/3
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java
b/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java
index 0340a55..02836f4 100644
--- a/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java
+++ b/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java
@@ -37,6 +37,7 @@
import org.apache.commons.io.FileUtils;
import org.apache.commons.lang3.StringUtils;
import org.apache.felix.framework.FilterImpl;
+import org.apache.sling.testing.mock.osgi.OsgiMetadataUtil.DynamicReference;
import org.apache.sling.testing.mock.osgi.OsgiMetadataUtil.Reference;
import org.apache.sling.testing.mock.osgi.OsgiServiceUtil.ReferenceInfo;
import org.apache.sling.testing.mock.osgi.OsgiServiceUtil.ServiceInfo;
@@ -142,6 +143,11 @@ private void
handleRefsUpdateOnRegister(MockServiceRegistration registration) {
List affectedDynamicReferences =
OsgiServiceUtil.getMatchingDynamicReferences(registeredServices, registration);
for (ReferenceInfo referenceInfo : affectedDynamicReferences) {
Reference reference = referenceInfo.getReference();
+// Look for a target override
+Object o =
referenceInfo.getServiceRegistration().getProperties().get(reference.getName()
+ ".target");
+if (o != null && o instanceof String) {
+reference = new DynamicReference(reference,(String)o);
+}
if (reference.matchesTargetFilter(registration.getReference())) {
switch (reference.getCardinality()) {
case MANDATORY_UNARY:
diff --git a/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java
b/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java
index 7c07578..4d22717 100644
--- a/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java
+++ b/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java
@@ -145,7 +145,20 @@ public static LogService newLogService(final Class
loggerContext) {
* @return true if all dependencies could be injected, false if the
service has no dependencies.
*/
public static boolean injectServices(Object target, BundleContext
bundleContext) {
-return OsgiServiceUtil.injectServices(target, bundleContext);
+return MockOsgi.injectServices(target, bundleContext, (Map)null);
+}
+
+/**
+ * Simulate OSGi service dependency injection. Injects direct references
and
+ * multiple references. If a some references could not be injected no error
+ * is thrown.
+ * @param target Service instance
+ * @param bundleContext Bundle context from which services are fetched to
inject.
+ * @param properties Service properties (used to resolve dynamic reference
properties)
+ * @return true if all dependencies could be injected, false if the
service has no dependencies.
+ */
+public static boolean injectServices(Object target, BundleContext
bundleContext, Map properties) {
+return OsgiServiceUtil.injectServices(target, bundleContext,
properties);
}
/**
diff --git
a/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java
b/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java
index 1fca7a5..1e0b8d3 100644
--- a/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java
+++ b/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java
@@ -470,20 +470,20 @@ public String getModifiedMethodName() {
static class Reference {
-private final Class clazz;
-private final String name;
-private final String interfaceType;
-private final ReferenceCardinality cardinality;
-private final ReferencePolicy policy;
-private final ReferencePolicyOption policyOption;
-private final String bind;
-private final String unbind;
-private final String field;
-private final FieldCollectionType fieldCollectionType;
-private final String target;
-private final Filter targetFilter;
-
-private Reference(Class clazz, Node node) {
+protected final Class clazz;
+protected final String name;
+protected final String interfaceType;
+protected final ReferenceCardinality cardinality;
+protected final ReferencePolicy policy;
+protected final ReferencePolicyOption policyOption;
+protected final String bind;
+protected final String unbind;
+protected final String field;
+
[jira] [Created] (SLING-7794) osgi-mock: Dynamic reference properties
Stefan Seifert created SLING-7794:
-
Summary: osgi-mock: Dynamic reference properties
Key: SLING-7794
URL: https://issues.apache.org/jira/browse/SLING-7794
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing OSGi Mock 2.3.8
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Testing OSGi Mock 2.3.10
[PR
#3|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/3]
from [badfish69|https://github.com/badfish69]:
{quote}
This is a pull request to add support for correct resolution of SCR references
where the target filter is provided via service properties rather than being
hard-coded into the metadata.
e.g. if you have code like this
{code:java}
@reference
MyClass myClass
{code}
The OSGI spec allows for the target service to be filtered via a property:
myClass.target, which provides a runtime equivalent to the
@reference(target=filter) static way of doing it.
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] stefanseifert commented on issue #3: Dynamic reference properties
stefanseifert commented on issue #3: Dynamic reference properties URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/3#issuecomment-409171425 thanks for the contribution - i've created a JIRA ticket for it: https://issues.apache.org/jira/browse/SLING-7794 This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
Re: Sling Hackathon Sept. 13th, 2018 in Berlin
I would like to join as well. Konrad > On 18. May 2018, at 15:07, Stefan Seifert wrote: > > same as last year, we have the possibility to host a "Sling Hackathon" in > berlin in september. > > the date is thursday 13.09.18 which is directly after the adaptTo() which > takes place 10-12.9.18 in potsdam (20min with train to our office). > > the hackathon will take place in the office of pro!vision GmbH, > Berlin-Charlottenburg. > > we should be at least 4 or 5 participants and have room for up to 20 people. > > if you are interested and want to participate: please send me a private mail > or a reply on this list! > > stefan > > p.s. we will again reserve a time slot for a "sling committer round table" on > the tuesday 11.9. evening during the adaptTo(). > >
[jira] [Resolved] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
[
https://issues.apache.org/jira/browse/SLING-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-7788.
---
Resolution: Fixed
Fix Version/s: Testing OSGi Mock 2.3.10
thanks - i've applied the PR
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/bf71f40288c140b9206b1e55b9e90b21431a29a5
> registerInjectActivateService() causes non-conform ServiceRegistration
> --
>
> Key: SLING-7788
> URL: https://issues.apache.org/jira/browse/SLING-7788
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Dirk Rudolph
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 2.3.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> According to the OSGI R6 Spec 5.2.3 the framework has to automatically set
> the {{objectClass}} property to the service registration for the types the
> service is registered for.
> {quote}The service interface names under which a service object has been
> successfully registered are automatically added to the service's properties
> under the key objectClass. This value must be set automatically by the
> Framework and any value provided by the bundle must be overridden.
> {quote}
> This is correctly implemented in
> [MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
> by using the passed array of full qualified class names given to it from the
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> and
> [MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
> respectively.
> On the other hand the the execution flow of
> [registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
> always causes
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> to be called with {{null}} as service class and so the array of services
> provided by the given object is missing for that registration.
> This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
> not work properly as the Filter it creates internally is referring to
> objectClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
[
https://issues.apache.org/jira/browse/SLING-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-7788:
-
Assignee: Stefan Seifert
> registerInjectActivateService() causes non-conform ServiceRegistration
> --
>
> Key: SLING-7788
> URL: https://issues.apache.org/jira/browse/SLING-7788
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Dirk Rudolph
>Assignee: Stefan Seifert
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> According to the OSGI R6 Spec 5.2.3 the framework has to automatically set
> the {{objectClass}} property to the service registration for the types the
> service is registered for.
> {quote}The service interface names under which a service object has been
> successfully registered are automatically added to the service's properties
> under the key objectClass. This value must be set automatically by the
> Framework and any value provided by the bundle must be overridden.
> {quote}
> This is correctly implemented in
> [MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
> by using the passed array of full qualified class names given to it from the
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> and
> [MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
> respectively.
> On the other hand the the execution flow of
> [registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
> always causes
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> to be called with {{null}} as service class and so the array of services
> provided by the given object is missing for that registration.
> This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
> not work properly as the Filter it creates internally is referring to
> objectClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] stefanseifert closed pull request #4: SLING-7788 Create Spec conform ServiceRegistration from DS Metadata
stefanseifert closed pull request #4: SLING-7788 Create Spec conform
ServiceRegistration from DS Metadata
URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/4
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java
b/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java
index cd93b0b..94c3cec 100644
---
a/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java
+++
b/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java
@@ -61,14 +61,14 @@ public MockServiceRegistration(final Bundle bundle, final
String[] clazzes, fina
else {
this.service = service;
}
-
+
+readOsgiMetadata();
+
this.properties = properties != null ? properties : new
Hashtable();
this.properties.put(Constants.SERVICE_ID, this.serviceId);
-this.properties.put(Constants.OBJECTCLASS, clazzes);
+this.properties.put(Constants.OBJECTCLASS, this.clazzes.toArray(new
String[0]));
this.serviceReference = new MockServiceReference(bundle, this);
this.bundleContext = bundleContext;
-
-readOsgiMetadata();
}
@Override
diff --git
a/src/test/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImplTest.java
b/src/test/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImplTest.java
index 36fd122..174c6a1 100644
---
a/src/test/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImplTest.java
+++
b/src/test/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImplTest.java
@@ -34,8 +34,12 @@
import
org.apache.sling.testing.mock.osgi.OsgiServiceUtilTest.ServiceInterface2;
import org.junit.After;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
+import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
+import org.osgi.service.component.annotations.Component;
+import org.osgi.util.tracker.ServiceTracker;
public class OsgiContextImplTest {
@@ -161,4 +165,34 @@ public void testRegisterInjectActivateInvalid() {
context.registerInjectActivateService(new Object());
}
+@Test
+public void testServiceTracker() {
+BundleContext bundleContext = context.bundleContext();
+ServiceTracker tracker = new
ServiceTracker<>(bundleContext, MyService.class, null);
+tracker.open();
+
+context.registerInjectActivateService(new MyComponent());
+
+assertNotNull(tracker.getServiceReferences());
+assertEquals(1, tracker.getServiceReferences().length);
+
+tracker.close();
+}
+
+@Component(
+service = MyService.class
+)
+public static class MyComponent implements MyService {
+
+@Override
+public String foo() {
+return "bar";
+}
+}
+
+public interface MyService {
+
+String foo();
+
+}
}
diff --git
a/src/test/resources/OSGI-INF/org.apache.sling.testing.mock.osgi.context.OsgiContextImplTest.xml
b/src/test/resources/OSGI-INF/org.apache.sling.testing.mock.osgi.context.OsgiContextImplTest.xml
new file mode 100644
index 000..d6b9d1c
--- /dev/null
+++
b/src/test/resources/OSGI-INF/org.apache.sling.testing.mock.osgi.context.OsgiContextImplTest.xml
@@ -0,0 +1,27 @@
+
+
+http://www.osgi.org/xmlns/scr/v1.3.0;>
+
+
+
+
+
+
+
\ No newline at end of file
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
[GitHub] AndreasWurm commented on issue #6: Allow caching of virtual resources
AndreasWurm commented on issue #6: Allow caching of virtual resources URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/6#issuecomment-409151317 done This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Commented] (SLING-7792) Resource Resolver should return more than one resolved path if available
[
https://issues.apache.org/jira/browse/SLING-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563273#comment-16563273
]
Julian Sedding commented on SLING-7792:
---
I think providing this information is valuable. I'm reluctant to just add it to
{{ResourceResolver}}, however. It doesn't seem like a method that would get
used a lot. Maybe we could introduce a {{Mapper}} interface (better names
welcome!), which can provide detailed information about mappings and
resolutions. The methods {{ResourceResolver#map}} and
{{ResourceResolver#resolve}} would then become mere convenience methods, but
the canonical source of truth for mappings would be the {{Mapper}}.
Background: for quite some time I have come to the conclusion that the
{{ResourceResolver}} conflates two responsibilities:
- accessing the {{Resource}} tree
- mapping/resolving URLs to/from the {{Resource}} tree
The current implementation shows that these ideas are conflated, which IMHO is
why the mapping/resolution code is not very modular. In an ideal future, we
could get to a point where mapping/resolution is pluggable (via OSGi services)
and the current implementations (i.e. /etc/maps, sling:alias,
sling:vanityPaths) are hooked into this extension point. The {{Mapper}} would
be the service that provides a compound view of all applied
mappings/resolutions.
> Resource Resolver should return more than one resolved path if available
>
>
> Key: SLING-7792
> URL: https://issues.apache.org/jira/browse/SLING-7792
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.6.0
>Reporter: Alex COLLIGNON
>Priority: Major
>
> The current {{ResourceResolver#map}} methods return a single "path mapped
> from the (resource) path". However, it is possible than a given path can be
> mapped to multiple others while using features such as {{sling:alias}} and
> {{sling:vanityUrl}}.
> In order to support that scenario, it is require to implement new maps method
> for {{ResourceResolver}} which returns a collection of "resolved path". This
> collection must contain the resources mapped through {{/etc/map}},
> {{sling:alias}} and {{sling:vanityUrl}}.
> The current API suggests to implement a second method to be
> consistent/symmetric with the existing map operations
> {quote}
> @Nonnull java.util.Collection maps(@Nonnull
> java.lang.String resourcePath)
> @Nonnull java.util.Collection maps(@Nonnull
> javax.servlet.http.HttpServletRequest request, @Nonnull java.lang.String
> resourcePath)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
+1 Carsten Ziegeler wrote > This release updates the two modules to the recently released API 2.18.2 > > We solved two issues in JCR Resource 3.0.12 > https://issues.apache.org/jira/projects/SLING/versions/12343800 > > We solved two issues in Resource Resolver 1.6.2 > https://issues.apache.org/jira/projects/SLING/versions/12343077 > (There are still two open issues which are moved to 1.6.4, these issues > already existed in 1.6.0) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1926/ > > 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 1926 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards > Carsten > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release JCR Resource 3.0.12 and Resource Resolver 1.6.2
This release updates the two modules to the recently released API 2.18.2 We solved two issues in JCR Resource 3.0.12 https://issues.apache.org/jira/projects/SLING/versions/12343800 We solved two issues in Resource Resolver 1.6.2 https://issues.apache.org/jira/projects/SLING/versions/12343077 (There are still two open issues which are moved to 1.6.4, these issues already existed in 1.6.0) Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1926/ 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 1926 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
