Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 Le lun. 5 oct. 2020 à 20:26, Daniel Klco a écrit : > +1 > > On Mon, Oct 5, 2020 at 8:34 AM Carsten Ziegeler > wrote: > > > +1 > > > > Carsten > > > > Am 05.10.2020 um 13:33 schrieb Justin Edelson: > > > Hi, > > > > > > We solved 3 issues in this release: > > > https://issues.apache.org/jira/projects/SLING/versions/12346492 > > > > > > There are still some outstanding issues: > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349142 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2348 > > > > > > 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_plain;f=check_staged_release.sh;hb=HEAD > > > > > > Usage: > > > sh check_staged_release.sh 2348 /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. > > > > > > > -- > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > >
Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 On Mon, Oct 5, 2020 at 8:34 AM Carsten Ziegeler wrote: > +1 > > Carsten > > Am 05.10.2020 um 13:33 schrieb Justin Edelson: > > Hi, > > > > We solved 3 issues in this release: > > https://issues.apache.org/jira/projects/SLING/versions/12346492 > > > > There are still some outstanding issues: > > https://issues.apache.org/jira/browse/SLING/fixforversion/12349142 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2348 > > > > 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_plain;f=check_staged_release.sh;hb=HEAD > > > > Usage: > > sh check_staged_release.sh 2348 /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. > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208168#comment-17208168 ] Michael Osipov commented on SLING-7534: --- Here is a lot of fuzz and non-sense going on. I think I need to break a stab here: First of all, a Maven 2 repo always includes MD5 and SHA-1 checksums. You cannot remove it. This is enforced and mandated by Nexus. I have talked with Brian Fox about this (see dev@maven some time ago), this is also not so easy to solve for Maven Central. Sonatype is analyzing the issue, but SHA-256 and SHA-512 are not required in Central. SHA-2 and SHA-3 perform really really slow compared to Blake. I am quite certain that this will lead to issues in the future and must be considered to allow Blake3 hashes as well for maximum perf. Now the important thing: You are completely mixing Apache release process requirements and Maven transport of artifacts: * Release: you must upload source-release.zip with SHA-2 family hash for dist. Period. How you generate it is completely your problem. * maven-install-plugin: It's sole task to copy all artifacts in the reactor to the local Maven repo. That's it. * maven-deploy-plugin: It's sole task is to copy all artifacts in the reactor which are locally installed to a remote location by using Maven Artifact Transfer which uses Maven Resolver. No checksums are generated by maven-deploy-plugin or Maven Artifact Transfer. Excourse: What are hashes used for with Maven? It is used to detect bitrot during transfer, i.e., has the file being corrupt by some transport mechanism. By no means to verify its authenticity (hello signatures). Maven Resolver generates those checksums and hands them off to a transport implementation to avoid bitrot. No more, no less. All checksums are opaque and an implementation detail of Maven Resolver, they are not and must not be exposed to any upper level. Maven does not care where an artifact came from, all it cares its integerity has been verified by some means and it is available in the local repo. When you configure Resolver to generate SHA-256 for the transport it will do on all requests files (artifacts), if not file an issue. You will *not* have access to those checksums. If you need checksums for your disposal at release time go exactly here: https://github.com/apache/maven/blob/master/apache-maven/pom.xml#L310-L336 > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8742) Allow overriding the extension when using the RequestDispatcher
[
https://issues.apache.org/jira/browse/SLING-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208117#comment-17208117
]
Roy Teeuwen commented on SLING-8742:
[~rombert] [~bdelacretaz] any update on this ticket? Is there any workaround I
can already do at this moment that you know of that allows me to remove / alter
an extension when using the request dispatcher?
> Allow overriding the extension when using the RequestDispatcher
> ---
>
> Key: SLING-8742
> URL: https://issues.apache.org/jira/browse/SLING-8742
> Project: Sling
> Issue Type: Improvement
> Components: API
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: API 2.23.2
>
>
> It is sometimes useful to be able to include another resource and override
> the extension at the same time.
> My scenario is that I am routing all requests through an entry point
> {{/content/maven.html}} and then serving resources based on the suffix.
> If I a binary file is requested, it should be downloaded ( by forcing the
> extension to be null ), but instead the html extension is used, which means
> the HTML Renderer kicks in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[
https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092
]
Andrea Tarocchi edited comment on SLING-7534 at 10/5/20, 1:58 PM:
--
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use {{net.nicoulaj.maven.plugins:checksum-maven-plugin}} to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
was (Author: valdar):
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use `net.nicoulaj.maven.plugins:checksum-maven-plugin` to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
> Issue Type: Task
> Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 40
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD
> no longer provide MD5 checksums for new releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[
https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092
]
Andrea Tarocchi edited comment on SLING-7534 at 10/5/20, 1:58 PM:
--
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use `net.nicoulaj.maven.plugins:checksum-maven-plugin` to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
was (Author: valdar):
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use {net.nicoulaj.maven.plugins:checksum-maven-plugin} to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
> Issue Type: Task
> Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 40
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD
> no longer provide MD5 checksums for new releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[
https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092
]
Andrea Tarocchi edited comment on SLING-7534 at 10/5/20, 1:57 PM:
--
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use {net.nicoulaj.maven.plugins:checksum-maven-plugin} to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
was (Author: valdar):
[~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need
to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate
sha512/256 checksum, but then those checksum files are md5/sha1 checked again
during upload to nexus?
> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
> Issue Type: Task
> Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 40
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD
> no longer provide MD5 checksums for new releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092 ] Andrea Tarocchi edited comment on SLING-7534 at 10/5/20, 1:57 PM: -- [~kwin] If I got all this correctly: MRESOLVER-56 has been reverted so we need to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate sha512/256 checksum, but then those checksum files are md5/sha1 checked again during upload to nexus? was (Author: valdar): [~kwin] If I got all this correctly: https://issues.apache.org/jira/browse/MRESOLVER-56 has been reverted so we need to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate sha512/256 checksum, but then those checksum files are md5/sha1 checked again during upload to nexus? > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092 ] Andrea Tarocchi edited comment on SLING-7534 at 10/5/20, 1:56 PM: -- [~kwin] If I got all this correctly: https://issues.apache.org/jira/browse/MRESOLVER-56 has been reverted so we need to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate sha512/256 checksum, but then those checksum files are md5/sha1 checked again during upload to nexus? was (Author: valdar): [~kwin] If I got all this correctly: https://issues.apache.org/jira/browse/MRESOLVER-140 has been reverted so we need to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate sha512/256 checksum, but then those checksum files are md5/sha1 checked again during upload to nexus? > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208092#comment-17208092 ] Andrea Tarocchi commented on SLING-7534: [~kwin] If I got all this correctly: https://issues.apache.org/jira/browse/MRESOLVER-140 has been reverted so we need to use `net.nicoulaj.maven.plugins:checksum-maven-plugin``` to generate sha512/256 checksum, but then those checksum files are md5/sha1 checked again during upload to nexus? > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208086#comment-17208086 ] Konrad Windszus commented on SLING-7534: Due to performance reasons SHA512/256 won't ever be generated/uploaded by default in Maven (MRESOLVER-130). Therefore we have to use a dedicated plugin to generate SHA512, but currently this has poor support for uploading it to the Stage repository. For details look at https://github.com/apache/sling-parent/pull/10 > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums
[ https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208086#comment-17208086 ] Konrad Windszus edited comment on SLING-7534 at 10/5/20, 1:39 PM: -- Due to performance reasons SHA512/256 won't ever be generated/uploaded by default in Maven (MRESOLVER-140). Therefore we have to use a dedicated plugin to generate SHA512, but currently this has poor support for uploading it to the Stage repository. For details look at https://github.com/apache/sling-parent/pull/10 was (Author: kwin): Due to performance reasons SHA512/256 won't ever be generated/uploaded by default in Maven (MRESOLVER-130). Therefore we have to use a dedicated plugin to generate SHA512, but currently this has poor support for uploading it to the Stage repository. For details look at https://github.com/apache/sling-parent/pull/10 > Release policy - stop providing MD5 and start providing SHA-512 checksums > - > > Key: SLING-7534 > URL: https://issues.apache.org/jira/browse/SLING-7534 > Project: Sling > Issue Type: Task > Components: Tooling >Reporter: Robert Munteanu >Assignee: Konrad Windszus >Priority: Major > Fix For: Parent 40 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD > no longer provide MD5 checksums for new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 Carsten Am 05.10.2020 um 13:33 schrieb Justin Edelson: Hi, We solved 3 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12346492 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12349142 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2348 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_plain;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2348 /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. -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 regards, Karl On Mon, Oct 5, 2020 at 2:24 PM Radu Cotescu wrote: > > +1 > > > On 5 Oct 2020, at 13:33, Justin Edelson wrote: > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Models Impl Version 1.4.14
+1 > On 5 Oct 2020, at 13:33, Justin Edelson wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
[GitHub] [sling-org-apache-sling-models-impl] cjelger edited a comment on pull request #20: SLING-9781 - [Sling Models] Caching doesn't work with Wrapped requests
cjelger edited a comment on pull request #20: URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/20#issuecomment-703574960 @justinedelson Thank you for the merge. It would be great if you could also release a new version since this issue pretty much prevents caching from working with HTL scripts. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [sling-org-apache-sling-models-impl] cjelger commented on pull request #20: SLING-9781 - [Sling Models] Caching doesn't work with Wrapped requests
cjelger commented on pull request #20: URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/20#issuecomment-703574960 @justinedelson Thank you for the merge. It would be great if you could also release a new version since this issue pretty much prevents caching from working with HTL scripts? Thanks. 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
[VOTE] Release Apache Sling Models Impl Version 1.4.14
Hi, We solved 3 issues in this release: https://issues.apache.org/jira/projects/SLING/versions/12346492 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12349142 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2348 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_plain;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2348 /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] [Updated] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
[
https://issues.apache.org/jira/browse/SLING-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9674:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Allow SlingHttpServletRequest based adaptations for ChildResourceInjector
> -
>
> Key: SLING-9674
> URL: https://issues.apache.org/jira/browse/SLING-9674
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> The {{ChildResourceInjector}} always returns one/multiple Resource objects
> which makes it impossible to use those return values with another Sling Model
> requiring the adaptable {{SlingHttpServletRequest}}.
> A solution from ACS Commons introduced
> https://adobe-consulting-services.github.io/acs-aem-commons/features/sling-model-injectors/child-resource-from-request/index.html
> in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1920.
> There should be a solution built into Sling which allows for easier Sling
> Model aggregation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
[
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-8079:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Returning false in a model PostConstruct causes an
> java.lang.IllegalStateException
> --
>
> Key: SLING-8079
> URL: https://issues.apache.org/jira/browse/SLING-8079
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.6
>Reporter: Santiago García Pimentel
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> I was just trying the exporter framework and the feature from SLING-7124,
> where you can return false in a post construct to prevent a model to being
> returned.
> Unfortunately I found myself with an IllegalStateException:
>
> {quote}java.lang.IllegalStateException: No throwable available at
> org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
> at
> org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
> at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
> It seems like the ModelAdapterFactory assumes that there should be an
> exception if a model was not returned, which is no longer the case. I don't
> think this exception should be thrown.
> The easiest solution I think is to make o.a.s.models.impl.Result not throw
> that exception and let the ModelAdapterFactory handle it, but Im not sure
> that would the be most appropriate way.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9478) Expose the full stack trace for PostConstruct exceptions
[
https://issues.apache.org/jira/browse/SLING-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9478:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Expose the full stack trace for PostConstruct exceptions
>
>
> Key: SLING-9478
> URL: https://issues.apache.org/jira/browse/SLING-9478
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> Currently any InvocationTargetException is stripped in
> https://github.com/apache/sling-org-apache-sling-models-impl/blob/80b1dea63615ea5be8252241d6147bce9552fa8e/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L756
> as it is replaced by the more generic PostConstruct exception stripping the
> the reflection part of the call stack.
> That may lead to exceptions like
> {code}
> Caused by: org.apache.sling.scripting.sightly.SightlyException:
> org.apache.sling.api.SlingException: Cannot get DefaultSlingScript:
> Identifier cannot be correctly instantiated by the Use API
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:227)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> com.adobe.cq.sightly.internal.extensions.IncludeExtension.call(IncludeExtension.java:72)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.header_html.render(header_html.java:41)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 198 common frames omitted
> Caused by: org.apache.sling.api.SlingException: Cannot get
> DefaultSlingScript: Identifier cannot be correctly instantiated by
> the Use API
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:510)
> [org.apache.sling.scripting.core:2.0.56]
> at
> com.adobe.cq.sightly.WCMScriptHelper.includeScript(WCMScriptHelper.java:222)
> [com.adobe.cq.sightly.cq-wcm-sightly-extension:1.6.0]
> ... 206 common frames omitted
> Caused by: org.apache.sling.scripting.sightly.SightlyException: Identifier
> cannot be correctly instantiated by the Use API
> at
> org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:77)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.sightly.apps.bruker.components.structure.header.content_html.render(content_html.java:43)
> at
> org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:50)
> [org.apache.sling.scripting.sightly.runtime:1.1.0.1_4_0]
> at
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:60)
> [org.apache.sling.scripting.sightly:1.1.2.1_4_0]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
> [org.apache.sling.scripting.core:2.0.56]
> at
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
> [org.apache.sling.scripting.core:2.0.56]
> ... 207 common frames omitted
> Caused by: org.apache.sling.models.factory.PostConstructException:
> Post-construct method has thrown an exception for model class
> at
> org.apache.sling.models.impl.ModelAdapterFact
[jira] [Updated] (SLING-8923) Jackson Sling Model Exporter for application/xml needs correct character encoding
[ https://issues.apache.org/jira/browse/SLING-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-8923: -- Fix Version/s: (was: Sling Models Impl 1.4.14) Sling Models Impl 1.4.16 > Jackson Sling Model Exporter for application/xml needs correct character > encoding > - > > Key: SLING-8923 > URL: https://issues.apache.org/jira/browse/SLING-8923 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Sumanth >Priority: Major > Fix For: Sling Models Impl 1.4.16 > > Attachments: image-2019-12-17-09-18-52-797.png > > > Incorrect Character encoding was identified in the below issue > https://issues.apache.org/jira/browse/SLING-7344 > and the fix was provided only for application/json Content-type. > This issue needs to be fixed even for application/xml type > > Currently, this is being set to iso-8859-1, which would be problem with > Special Characters. > > !image-2019-12-17-09-18-52-797.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9036) Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
[
https://issues.apache.org/jira/browse/SLING-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-9036:
--
Fix Version/s: (was: Sling Models Impl 1.4.14)
Sling Models Impl 1.4.16
Sling Models Impl 1.4.16
> Sling Models: SlingHttpServletRequestWrapper.adaptTo() unwraps before adapting
> --
>
> Key: SLING-9036
> URL: https://issues.apache.org/jira/browse/SLING-9036
> Project: Sling
> Issue Type: New Feature
> Components: Sling Models
>Reporter: Henry Kuijpers
>Priority: Major
> Fix For: Sling Models Impl 1.4.16
>
>
> Sling Model:
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> MySlingModel.class)
> class MySlingModel {
> @Inject
> public MySlingModel(@Self SlingHttpServletRequest req) {
> logger.log(req.getResourceBundle().getClass().getName());
> }
> }
> {code}
> Calling code:
> {code:java}
> // req obtained via JSP/HTL
> final SlingHttpServletRequest myWrappedReq = new
> SlingHttpServletRequestWrapper(req) {
> @Override
> public ResourceBundle getResourceBundle() {
> return new MyCustomResourceBundle();
> }
> };
>
> final MySlingModel myModel = myWrappedReq.adaptTo(MySlingModel.class);
> {code}
> I would expect the log file to contain "MyCustomResourceBundle". Instead it
> contains "NullResourceBundle".
> This is because the request is being "unwrapped" when doing the adaptTo()
> call: It keeps on delegating to the wrapped request. This should not have
> happened, i.e. how can we otherwise overwrite (parts of) requests and
> resources?
> See also:
> [https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/wrappers/SlingHttpServletRequestWrapper.java#L147]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SLING-9781) [Sling Models] Caching doesn't work with Wrapped requests
[
https://issues.apache.org/jira/browse/SLING-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-9781.
---
Resolution: Fixed
Fixed with 73cae5875cc47c76991d0a58e4fb2351595eb146
> [Sling Models] Caching doesn't work with Wrapped requests
> -
>
> Key: SLING-9781
> URL: https://issues.apache.org/jira/browse/SLING-9781
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Sling Models Impl 1.4.12
>Reporter: Christophe Jelger
>Assignee: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The caching of Sling models doesn't work when the original
> {{SlingHttpServletRequest}} is wrapped in a request wrapper, like this is
> typically done in HTL scripts with the {{OnDemandReaderRequest}} wrapper.
> The solution is to use the original request when caching models so that any
> wrapping does not interfere with the caching. When someone enables caching
> for a model adapted from request, I think the expectation is that caching
> does happen whenever the original request is wrapped.
> I'll provide a PR with a fix.
> cc: [~justinedelson] [~radu] as discussed in Slack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-models-impl] justinedelson merged pull request #20: SLING-9781 - [Sling Models] Caching doesn't work with Wrapped requests
justinedelson merged pull request #20: URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/20 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
Re: [VOTE] Release Apache Sling Scripting FreeMarker 1.0.4
+1 Le lun. 5 oct. 2020 à 12:30, Karl Pauls a écrit : > +1 > > regards, > > Karl > > On Monday, October 5, 2020, Radu Cotescu wrote: > > > +1 > > > > > On 3 Oct 2020, at 15:49, Oliver Lietz wrote: > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > > > -- > Karl Pauls > karlpa...@gmail.com >
Re: [VOTE] Release Apache Sling Scripting FreeMarker 1.0.4
+1 regards, Karl On Monday, October 5, 2020, Radu Cotescu wrote: > +1 > > > On 3 Oct 2020, at 15:49, Oliver Lietz wrote: > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Scripting FreeMarker 1.0.4
+1 > On 3 Oct 2020, at 15:49, Oliver Lietz wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
[jira] [Created] (SLING-9793) Jackson exporter alphabetical sorting
Jasper Simon created SLING-9793: --- Summary: Jackson exporter alphabetical sorting Key: SLING-9793 URL: https://issues.apache.org/jira/browse/SLING-9793 Project: Sling Issue Type: Improvement Components: Sling Models Reporter: Jasper Simon It would be nice to have JSON properties sorted alphabetically by default when using the jackson exporter. If that is not possible, an OSGi configuration for the jackson exporter where you can define the default behaviour of the jackson exporter for your project.(org.apache.sling.models.jacksonexporter.impl.JacksonExporter) Now we need to add the sorting option for every exported class, while it would be beneficial to have this configured project-wide. -- This message was sent by Atlassian Jira (v8.3.4#803005)
