Re: [VOTE] Release Apache Sling Rewriter 1.3.0
Stefan, I verified by reproducing and fixing the test on Windows 10. The issue is the test expects a line ending of \n when checking the output from printing the doctype. Changing the test resolved the issue and otherwise there seem to be no issues with the implementation code. I will fix the test to work for \r\n and \n line endings after this release. In the meantime, here's my: +1 On Mon, Jan 18, 2021 at 2:21 AM Stefan Seifert wrote: > hallo daniel. > > it's likely only a problem in the unit tests, but maybe also a problem in > the production code itself? in the first case it would be fine for me to > continue with the release, in the latter we should cancel it. > > stefan > > > >-Original Message- > >From: Daniel Klco > >Sent: Saturday, January 16, 2021 6:14 PM > >To: dev@sling.apache.org > >Subject: Re: [VOTE] Release Apache Sling Rewriter 1.3.0 > > > >Thanks for the note and catch Stefan. Are you a -1 or okay with fixing the > >test post-release? > > > >On Sat, Jan 16, 2021 at 2:43 AM Stefan Seifert > > wrote: > > > >> i've a problem running the unit test on windows - seems to be a line > >> ending issue (see below). > >> another cosmetic remark: please put the SLING ticket number in the git > >> commit messages, otherwise it's difficult to associate it. > >> > >> stefan > >> > >> > >> > - > >-- > >> Test set: org.apache.sling.rewriter.impl.components.Html5SerializerTest > >> > >> > - > >-- > >> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.177 s > >> <<< FAILURE! - in > >> org.apache.sling.rewriter.impl.components.Html5SerializerTest > >> > > >org.apache.sling.rewriter.impl.components.Html5SerializerTest.testStartDocu > >ment > >> Time elapsed: 0.147 s <<< FAILURE! > >> org.junit.ComparisonFailure: > >> expected:<[] > >> > but was:<[ > >> ] > >> > > >> at > >> > > >org.apache.sling.rewriter.impl.components.Html5SerializerTest.testStartDocu > >ment(Html5SerializerTest.java:113) > >> > >> > >> > >> > >> >-Original Message- > >> >From: Daniel Klco > >> >Sent: Friday, January 15, 2021 6:40 PM > >> >To: dev@sling.apache.org > >> >Subject: [VOTE] Release Apache Sling Rewriter 1.3.0 > >> > > >> >Hi, > >> > > >> >We solved 9 issues in this release: > >> >https://issues.apache.org/jira/projects/SLING/versions/12342644 > >> > > >> >I bumped to 1.3 due to the HTM5 serializer support which is backwards > >> >compatible. > >> > > >> >Staging repository: > >> > > https://repository.apache.org/content/repositories/orgapachesling-2399/ > >> > > >> >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 2399 /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. > >> >
[jira] [Commented] (SLING-10069) The generated features target dir is created in the wrong place
[
https://issues.apache.org/jira/browse/SLING-10069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267567#comment-17267567
]
Eric Norman commented on SLING-10069:
-
I've created a PR at:
[https://github.com/apache/sling-slingfeature-maven-plugin/pull/67]
If there is no negative feedback to the changes in a few days then I will merge
the PR to the mainline.
> The generated features target dir is created in the wrong place
> ---
>
> Key: SLING-10069
> URL: https://issues.apache.org/jira/browse/SLING-10069
> Project: Sling
> Issue Type: Bug
>Affects Versions: slingfeature-maven-plugin 1.4.22
>Reporter: Eric Norman
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.4.24
>
>
> After switching to the 1.4.22 release version of the plugin, I noticed that
> the change for SLING-10035 appears to be creating a set of empty folders in
> the wrong place in my linux environment.
> Using a debugger, I see that the targetDir File object is constructed at
> AbstractFeatureMojo line 244 with the "child" second argument already
> resolved to be an absolute path. This appears to append the absolute child
> path to the parent path rather than checking if "child" is relative or
> absolute to resolve it.
> [https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/AbstractFeatureMojo.java#L244]
>
> Expect the targetDir resolution to properly resolve the path with something
> like this:
> {code:java}
> final File targetDir =
> this.project.getBasedir().toPath().resolve(this.project.getBuild().getDirectory()).toFile();
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-slingfeature-maven-plugin] sonarcloud[bot] commented on pull request #67: SLING-10069 The generated features target dir is created in the wrong place
sonarcloud[bot] commented on pull request #67: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/67#issuecomment-762512824 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=67=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=67=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=67=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=67=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=67=new_coverage=list) [70.0% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=67=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=67=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=67=new_duplicated_lines_density=list) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-slingfeature-maven-plugin] enapps-enorman opened a new pull request #67: SLING-10069 The generated features target dir is created in the wrong place
enapps-enorman opened a new pull request #67: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/67 After switching to the 1.4.22 release version of the plugin, I noticed that the change for SLING-10035 appears to be creating a set of empty folders in the wrong place in my linux environment. Using a debugger, I see that the targetDir File object is constructed at AbstractFeatureMojo line 244 with the "child" second argument already resolved to be an absolute path. This appears to append the absolute child path to the parent path rather than checking if "child" is relative or absolute to resolve it. Expect the targetDir resolution to properly resolve the path when the child is an absolute path. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SLING-10035) Sling Feature fails when Generated Features Directory is missing
[
https://issues.apache.org/jira/browse/SLING-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266330#comment-17266330
]
Eric Norman edited comment on SLING-10035 at 1/18/21, 9:40 PM:
---
FYI: After switching to the newly release version of the plugin, I just noticed
that this change appears to be creating a set of empty folders in the wrong
place in my linux environment.
Using a debugger, I see that the targetDir File object is constructed at
AbstractFeatureMojo line 244 with the "child" second argument already resolved
to be an absolute path. This appears to append the absolute child path to the
parent path rather than checking if "child" is relative or absolute to resolve
it.
[https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/AbstractFeatureMojo.java#L244]
Any objections to changing that line to something like below to properly
resolve the 2 paths?
{code:java}
final File targetDir =
this.project.getBasedir().toPath().resolve(this.project.getBuild().getDirectory()).toFile();
{code}
UPDATE: I've created SLING-10069 for tracking the problem.
was (Author: enorman):
FYI: After switching to the newly release version of the plugin, I just noticed
that this change appears to be creating a set of empty folders in the wrong
place in my linux environment.
Using a debugger, I see that the targetDir File object is constructed at
AbstractFeatureMojo line 244 with the "child" second argument already resolved
to be an absolute path. This appears to append the absolute child path to the
parent path rather than checking if "child" is relative or absolute to resolve
it.
[https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/AbstractFeatureMojo.java#L244]
Any objections to changing that line to something like below to properly
resolve the 2 paths?
{code:java}
final File targetDir =
this.project.getBasedir().toPath().resolve(this.project.getBuild().getDirectory()).toFile();
{code}
> Sling Feature fails when Generated Features Directory is missing
>
>
> Key: SLING-10035
> URL: https://issues.apache.org/jira/browse/SLING-10035
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.4.20
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.4.22
>
>
> When I want to aggregate a Feature Model in another module like 'all' and
> there is not attachment or other FM generation task beforehand the Sling
> Feature Maven Plugin fails in handleGeneratedFeatures() method. This can be
> fixed by copying the target folder from the resources but that is a lot of
> unnecessary work.
>
> I added code to that method that tries to create the folder if it does not
> exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-10069) The generated features target dir is created in the wrong place
Eric Norman created SLING-10069:
---
Summary: The generated features target dir is created in the wrong
place
Key: SLING-10069
URL: https://issues.apache.org/jira/browse/SLING-10069
Project: Sling
Issue Type: Bug
Affects Versions: slingfeature-maven-plugin 1.4.22
Reporter: Eric Norman
Fix For: slingfeature-maven-plugin 1.4.24
After switching to the 1.4.22 release version of the plugin, I noticed that the
change for SLING-10035 appears to be creating a set of empty folders in the
wrong place in my linux environment.
Using a debugger, I see that the targetDir File object is constructed at
AbstractFeatureMojo line 244 with the "child" second argument already resolved
to be an absolute path. This appears to append the absolute child path to the
parent path rather than checking if "child" is relative or absolute to resolve
it.
[https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/AbstractFeatureMojo.java#L244]
Expect the targetDir resolution to properly resolve the path with something
like this:
{code:java}
final File targetDir =
this.project.getBasedir().toPath().resolve(this.project.getBuild().getDirectory()).toFile();
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-10060) Substitutions for the "replacePropertyVariables" values should prefer the system property value
[ https://issues.apache.org/jira/browse/SLING-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman resolved SLING-10060. - Resolution: Fixed Fixed at: https://github.com/apache/sling-slingfeature-maven-plugin/commit/0fa01064594c92801bd871882172227728ecda49 > Substitutions for the "replacePropertyVariables" values should prefer the > system property value > --- > > Key: SLING-10060 > URL: https://issues.apache.org/jira/browse/SLING-10060 > Project: Sling > Issue Type: Bug >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: slingfeature-maven-plugin 1.4.24 > > > Substitutions for the "replacePropertyVariables" values should prefer the > system property value (if available) over the project property value. > For example, the use case of a parameterized jenkins job where the users > choice should be passed along to maven and used to configure/prepare the > environment to run a set of tests against. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-slingfeature-maven-plugin] enapps-enorman merged pull request #66: SLING-10060 Substitutions for the "replacePropertyVariables" values should prefer the system property value
enapps-enorman merged pull request #66: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/66 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267450#comment-17267450
]
Timothee Maret commented on SLING-10066:
Thanks [~joerghoh], I merged your PR.
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Assignee: Timothée Maret
>Priority: Major
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
> package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
> [8343]
> 15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
> MessagingCacheCallback$$Lambda$532/0x00080108fc40]
> org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing
> message
> package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
> offset=1023083
> 15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
> Sending distributed notifications for pub agent publish queue item
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
> 15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
> [null] Succesfully applied package with id
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
> [/content/something]
> {code}
> While they are technically perfectly ok, I think that 4 messages are a bit
> too much. I would suggest to change the loglevel for message 3 to DEBUG,
> because it does not offer any useful information, which should be logged on
> INFO.
> I would also suggest to change message 4 to DEBUG (the fact that the package
> is successfully distributed is implicit, because otherwise there would be an
> error message), but I am indeed interested into the path which is
> distributed. So it would be great if we could log that path(s) in either in
> message 1 or 2.
> Overall this could reduce the noise in the logs if distribution is heavily
> used.
> WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-10066.
Fix Version/s: Content Distribution Journal Core 0.1.18
Resolution: Fixed
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Assignee: Timothée Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.18
>
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
> package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
> [8343]
> 15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
> MessagingCacheCallback$$Lambda$532/0x00080108fc40]
> org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing
> message
> package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
> offset=1023083
> 15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
> Sending distributed notifications for pub agent publish queue item
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
> 15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
> [null] Succesfully applied package with id
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
> [/content/something]
> {code}
> While they are technically perfectly ok, I think that 4 messages are a bit
> too much. I would suggest to change the loglevel for message 3 to DEBUG,
> because it does not offer any useful information, which should be logged on
> INFO.
> I would also suggest to change message 4 to DEBUG (the fact that the package
> is successfully distributed is implicit, because otherwise there would be an
> error message), but I am indeed interested into the path which is
> distributed. So it would be great if we could log that path(s) in either in
> message 1 or 2.
> Overall this could reduce the noise in the logs if distribution is heavily
> used.
> WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned SLING-10066:
--
Assignee: Timothée Maret
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Assignee: Timothée Maret
>Priority: Major
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
> package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
> [8343]
> 15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
> MessagingCacheCallback$$Lambda$532/0x00080108fc40]
> org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing
> message
> package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
> offset=1023083
> 15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
> Sending distributed notifications for pub agent publish queue item
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
> 15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
> [null] Succesfully applied package with id
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
> [/content/something]
> {code}
> While they are technically perfectly ok, I think that 4 messages are a bit
> too much. I would suggest to change the loglevel for message 3 to DEBUG,
> because it does not offer any useful information, which should be logged on
> INFO.
> I would also suggest to change message 4 to DEBUG (the fact that the package
> is successfully distributed is implicit, because otherwise there would be an
> error message), but I am indeed interested into the path which is
> distributed. So it would be great if we could log that path(s) in either in
> message 1 or 2.
> Overall this could reduce the noise in the logs if distribution is heavily
> used.
> WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9999) Remove cyclic dependency between scripting and servlets features
[
https://issues.apache.org/jira/browse/SLING-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267234#comment-17267234
]
Oliver Lietz commented on SLING-:
-
[~radu], [~karlpauls], Again, the new dependency added prevents the
update/upgrade of bundles in Sling's Karaf Features (the core features are
stable for years and are live in production). Therefore I'm interested in
getting it fixed in a timely manner.
I did NOT change any implementation, just moved the API parts (mainly from
Servlets Resolver to Scripting API) around and adjusted the imports – still I
do not understand why you see an issue including the new Bundle API in
Scripting API (as I said Sling API would also work – no additional dependencies
– but the bundle is already "fat").
So we just have to find the final location for Bundle API and adjust the
imports.
When you look into the classes and javadoc it should be clear why I would
locate the Bundle API below Scripting namespace, right? No references to
servlet/script resolvers:
{noformat}
/**
*
* A {@code BundledRenderUnit} represents a pre-packaged script or precompiled
script (Java class) that will be executed in order to
* render a {@link org.apache.sling.api.SlingHttpServletRequest}.
*
*
* The {@code BundledRenderUnit} provider module is responsible for defining
how a unit is executed. However, when executing the unit in the
* context of a {@link javax.script.ScriptEngine}, the provider module should
add the current executing unit into the {@link
* javax.script.ScriptEngine}'s {@link javax.script.ScriptContext} using the
{@link #VARIABLE} key.
*
*/
{noformat}
So I suggest to have a new bundle/package {{o.a.s.scripting.bundle.spi}} or
just {{o.a.s.scripting.bundle}}.
But now after reading and reading your comments again and pushing for reverting
keeping the (unfortunate) API namespace unchanged in the last comments... Does
it mean you already depend in your product on the namespace and are not willing
to change? And did I miss a discussion on dev@ around adding the new Bundle API
to Servlets Resolver?
> Remove cyclic dependency between scripting and servlets features
>
>
> Key: SLING-
> URL: https://issues.apache.org/jira/browse/SLING-
> Project: Sling
> Issue Type: Improvement
> Components: API, Karaf, Scripting, Servlets, Starter
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> Before {{org.apache.sling.scripting.core.impl.bundled}} and
> {{org.apache.sling.servlets.resolver.bundle}} were added the dependency
> chains were e.g.
> {{sling-servlets}} → {{sling-scripting}} → {{sling}}
> {{sling-scripting-jsp}} → {{sling-scripting}} → {{sling}}
> Currently several _scripting_ modules depend on
> {{org.apache.sling.servlets.resolver.bundle.tracker}}.
> h2. Move _Bundle_ API to Scripting and Resource packages (modules)
> ||Actual Package (Module)||Target Package (Module)||
> |*{{org.apache.sling.servlets.resolver.bundle.tracker.BundledRenderUnit}}*
> ({{org.apache.sling.servlets.resolver}})|*{{org.apache.sling.scripting.api.bundle.BundledRenderUnit}}*
> ({{org.apache.sling.scripting.api}})|
> |*{{org.apache.sling.servlets.resolver.bundle.tracker.
> BundledRenderUnitCapability}}*
> ({{org.apache.sling.servlets.resolver}})|*{{org.apache.sling.scripting.api.bundle.BundledRenderUnitCapability}}*
> ({{org.apache.sling.scripting.api}})|
> |*{{org.apache.sling.servlets.resolver.bundle.tracker.BundledRenderUnitFinder}}*
>
> ({{org.apache.sling.servlets.resolver}})|*{{org.apache.sling.scripting.api.bundle.BundledRenderUnitFinder}}*
> ({{org.apache.sling.scripting.api}})|
> |*{{org.apache.sling.servlets.resolver.bundle.tracker.ResourceType}}*
> ({{org.apache.sling.servlets.resolver}})|*{{org.apache.sling.api.resource.type.ResourceType}}*
> ({{org.apache.sling.api}})|
> |*{{org.apache.sling.servlets.resolver.bundle.tracker.TypeProvider}}*
> ({{org.apache.sling.servlets.resolver}})|*{{org.apache.sling.scripting.api.bundle.TypeProvider}}*
> (_*{color:#ff8b00}class name?{color}*_) ({{org.apache.sling.scripting.api}})|
>
> ||Module||Commits||Status||
> |{{org.apache.sling.api}}|[02cb7f1|https://github.com/apache/sling-org-apache-sling-api/commit/02cb7f1bbc4836865afd7e9964d3be1380daf734]|(/)|
> |{{org.apache.sling.scripting.api}}|[d38759d|https://github.com/apache/sling-org-apache-sling-scripting-api/commit/d38759dbd3d4159f70ea54bff23b037be8d07cd6]|(/)|
> |{{org.apache.sling.scripting.core}}|[b2f368a|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/b2f368a90a087979c34d8072fe529675971234fe],
>
> [1467cfa|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/1467cfa6a3fe4c77a628d078f9d944ce4cc42eb1]|(/)|
>
[jira] [Commented] (SLING-9983) Add support for predefined date format styles
[ https://issues.apache.org/jira/browse/SLING-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267148#comment-17267148 ] Konrad Windszus commented on SLING-9983: [~radu] Any comments from your side on the PRs? > Add support for predefined date format styles > - > > Key: SLING-9983 > URL: https://issues.apache.org/jira/browse/SLING-9983 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting HTL Engine 1.4.6-1.4.0 >Reporter: Konrad Windszus >Assignee: Radu Cotescu >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > SLING-6399 introduced possibilities to format dates as mandated by the spec: > https://github.com/adobe/htl-spec/blob/1.3/SPECIFICATION.md#122-format. > The problem is that date patterns patterns in general (even if a locale is > passed) differ a lot between countries and languages. For that reason Java > defines some [standard formats > |https://docs.oracle.com/javase/tutorial/i18n/format/dateFormat.html] which > work for all languages/countries. The special strings "DEFAULT", "SHORT", > "MEDIUM", "LONG", and "FULL" should be accepted as values which should lead > to using > https://docs.oracle.com/javase/8/docs/api/java/text/DateFormat.html#getDateInstance-int-java.util.Locale- > as formatter. They are also defined by Unicode CLDR: > http://cldr.unicode.org/translation/date-time-1/date-time-patterns#TOC-Basic-Date-Formats -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267063#comment-17267063
]
Jörg Hoh edited comment on SLING-10066 at 1/18/21, 8:14 AM:
Hi Timothee,
ok, then it will be message 2 and 3.
https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/62
was (Author: joerghoh):
Hi Timothee,
ok, then it will be message 2 and 3. I will open a PR.
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Priority: Major
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
> package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
> [8343]
> 15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
> MessagingCacheCallback$$Lambda$532/0x00080108fc40]
> org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing
> message
> package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
> offset=1023083
> 15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
> Sending distributed notifications for pub agent publish queue item
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
> 15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
> [null] Succesfully applied package with id
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
> [/content/something]
> {code}
> While they are technically perfectly ok, I think that 4 messages are a bit
> too much. I would suggest to change the loglevel for message 3 to DEBUG,
> because it does not offer any useful information, which should be logged on
> INFO.
> I would also suggest to change message 4 to DEBUG (the fact that the package
> is successfully distributed is implicit, because otherwise there would be an
> error message), but I am indeed interested into the path which is
> distributed. So it would be great if we could log that path(s) in either in
> message 1 or 2.
> Overall this could reduce the noise in the logs if distribution is heavily
> used.
> WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267063#comment-17267063
]
Jörg Hoh commented on SLING-10066:
--
Hi Timothee,
ok, then it will be message 2 and 3. I will open a PR.
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Priority: Major
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
> package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
> [8343]
> 15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
> MessagingCacheCallback$$Lambda$532/0x00080108fc40]
> org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing
> message
> package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
> offset=1023083
> 15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
> Sending distributed notifications for pub agent publish queue item
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
> 15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
> org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
> [null] Succesfully applied package with id
> dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
> [/content/something]
> {code}
> While they are technically perfectly ok, I think that 4 messages are a bit
> too much. I would suggest to change the loglevel for message 3 to DEBUG,
> because it does not offer any useful information, which should be logged on
> INFO.
> I would also suggest to change message 4 to DEBUG (the fact that the package
> is successfully distributed is implicit, because otherwise there would be an
> error message), but I am indeed interested into the path which is
> distributed. So it would be great if we could log that path(s) in either in
> message 1 or 2.
> Overall this could reduce the noise in the logs if distribution is heavily
> used.
> WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-10066) cleanup logging for content distribution
[
https://issues.apache.org/jira/browse/SLING-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Hoh updated SLING-10066:
-
Description:
When submitting content for distribution I get these 4 log entries for a single
submission (using the package-id as identifier):
{code:java}
15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
/bin/replicate.json HTTP/1.1]
org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
[8343]
15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
MessagingCacheCallback$$Lambda$532/0x00080108fc40]
org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing message
package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
offset=1023083
15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
Sending distributed notifications for pub agent publish queue item
dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
[null] Succesfully applied package with id
dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
[/content/something]
{code}
While they are technically perfectly ok, I think that 4 messages are a bit too
much. I would suggest to change the loglevel for message 3 to DEBUG, because it
does not offer any useful information, which should be logged on INFO.
I would also suggest to change message 4 to DEBUG (the fact that the package
is successfully distributed is implicit, because otherwise there would be an
error message), but I am indeed interested into the path which is distributed.
So it would be great if we could log that path(s) in either in message 1 or 2.
Overall this could reduce the noise in the logs if distribution is heavily used.
WDYT?
was:
When submitting content for distribution I get these 4 log entries for a single
submission (using the package-id as identifier):
{code:java}
15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
/bin/replicate.json HTTP/1.1]
org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
Creating package binary with id [f4fce37b-f160-40b0-9284-7b696a954630] for
package [dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483], length
[8343]
15.01.2021 14:30:05.243 *INFO* [Message Poller PackageMessage handled by
MessagingCacheCallback$$Lambda$532/0x00080108fc40]
org.apache.sling.distribution.journal.queue.impl.PubQueueCache Queueing message
package-id=dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483,
offset=1023083
15.01.2021 14:30:17.716 *INFO* [sling-default-1-Registered Service.5223]
org.apache.sling.distribution.journal.impl.publisher.PackageDistributedNotifier
Sending distributed notifications for pub agent publish queue item
dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483
15.01.2021 14:30:17.779 *INFO* [sling-default-1-Registered Service.5223]
org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher
[null] Succesfully applied package with id
dstrpck-1610721005168-00bd582b-1f91-4abc-82b6-a80afa2a0483, type ADD, paths
[/content/something]
{code}
While they are technically perfectly ok, I think that 4 messages are a bit too
much. I would suggest to change the loglevel for message 3 do DEBUG, because it
does not offer any useful information, which should be logged on INFO.
I would also suggest to change message 4 to DEBUG (the fact that the package
is successfully distributed is implicit, because otherwise there would be an
error message), but I am indeed interested into the path which is distributed.
So it would be great if we could log that path(s) in either in message 1 or 2.
Overall this could reduce the noise in the logs if distribution is heavily used.
WDYT?
> cleanup logging for content distribution
>
>
> Key: SLING-10066
> URL: https://issues.apache.org/jira/browse/SLING-10066
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.16
>Reporter: Jörg Hoh
>Priority: Major
>
> When submitting content for distribution I get these 4 log entries for a
> single submission (using the package-id as identifier):
> {code:java}
> 15.01.2021 14:30:05.168 *INFO* [192.147.128.10 [1610721005131] POST
> /bin/replicate.json HTTP/1.1]
> org.apache.sling.distribution.journal.impl.publisher.PackageMessageFactory
> Creating package
