Re: [PR] SLING-12312 add jakarta.servlet support in RequestLocaleResolve [sling-org-apache-sling-i18n]
enapps-enorman commented on PR #13: URL: https://github.com/apache/sling-org-apache-sling-i18n/pull/13#issuecomment-2099146151 > This way the package has a dependency on both javax.servlet and jakarta.servlet and will not work for older environments. Was that the intention? I would prefer to get rid of the javax.servlet (EE8) but that is not possible yet so both have to be there for now. Community support for all the versions of jetty that don't support EE9 or later have been [eol](https://endoflife.date/eclipse-jetty) for a while now. I guess I don't expect that people who don't upgrade anything and keep using eol software should get to decide what can be changed. Progress requires moving forward. org.apache.felix.http.jetty 5.x and org.apache.felix.http.jetty12 1.x both support servlets using either javax.servlet or jakarta.servlet Why can't the EE8 loyalists just stay on the old version of org.apache.sling.i18n? -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-12313 bump oak.version to 1.62.0 for compatibility [sling-org-apache-sling-jcr-oak-server]
enapps-enorman commented on PR #10: URL: https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2099118388 > Thanks for looking into this. I wonder though whether it makes more sense to extend the version range that we accept for the `org.apache.jackrabbit.guava.common.base`. and stay compatible with more Oak versions. > I don't have any way of knowing if that would be safe or not. It is probably ok, but it would just be a guess with each new release. A better solution would be for OAK to stop using guava in the code path that causes that import to exist. Why does anyone still use guava at this point? As far as I can tell it is the reference to "[org.apache.jackrabbit.oak.spi.security.authentication.AuthInfoImpl](https://github.com/apache/jackrabbit-oak/blob/trunk/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AuthInfoImpl.java)" in the OakSlingRepository class that drags guava into the required dependencies. And the usage of guava there seems trivial and could be replaced with standard java apis. -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
enapps-enorman commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2099081961 > Regarding the slf4j-api - could we not also register the capability ourselves, since we provide it and bypass the serviceloader? It seems like that would interfere with other usages of the serviceloader so I am not inclined to spend any time on that. > At this point I am wary of importing a large number of source files in the Sling Git repository I'm not sure what you mean by a "large number" of source files? There are only 4 files under src/main/java/ch/qos/logback and only 1 of those files copies any code blocks from the original vendor. The other three extend the original classes and add to it or override to provide a different implementation. Anyways with that said, I am not interested in spending any more time on solving this in another way. If you want to do that work then please go ahead and make a proposal to prove your theory. I'm perfectly happy just managing and using my own fork at this point since I don't anticipate it needing much maintenance in the future. -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update dependency org.apache.sling:org.apache.sling.distribution.api to v0.7.2 [sling-site]
cschneider merged PR #161: URL: https://github.com/apache/sling-site/pull/161 -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update dependency org.apache.sling:org.apache.sling.distribution.journal.messages to v0.5.10 [sling-site]
cschneider merged PR #162: URL: https://github.com/apache/sling-site/pull/162 -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update dependency org.apache.sling:org.apache.sling.distribution.journal to v0.3.0 [sling-site]
cschneider merged PR #163: URL: https://github.com/apache/sling-site/pull/163 -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
rombert commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2098321478 @enapps-enorman Regarding the slf4j-api - could we not also register the capability ourselves, since we provide it and bypass the serviceloader? Regarding the logback contribution - I am not sure if/how we can expedite the logback contribution. At this point I am wary of importing a large number of source files in the Sling Git repository; vendoring is not that easy and you can see on https://github.com/apache/sling-org-apache-sling-commons-json/tree/maintenance how we need to make changes and track them. I fully understand your desire to not do more work unless really required. I can think of alternative ways of approaching the logback issue, in case someone has the desire to explore them. We ended up using reflection in the Sling XSS bundle when upstream was unresponsive ( https://github.com/OWASP/java-html-sanitizer/issues/275 ) but we could also consider using Weaving Hooks ( https://docs.osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html ) . -- 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. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SLING-12314) Add pubName tag to metric
Christian Schneider created SLING-12314: --- Summary: Add pubName tag to metric Key: SLING-12314 URL: https://issues.apache.org/jira/browse/SLING-12314 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Christian Schneider Assignee: Christian Schneider Fix For: Content Distribution Journal Core 0.4.0 Normally we would add the publish agent name tag in the constructor of SubscriberMetrics. For BookKeeper we do not have the publish agent name there. So we add it in a the method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling JCR Resource 3.3.0
On Mon, 2024-05-06 at 16:19 +, Radu Cotescu wrote: > Please vote to approve this release: +1 FWIW, you probably did not want to tag https://issues.apache.org/jira/browse/SLING-12094 as being fixed for this release. Thanks, Robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Sling Hypermedia API client-side tools 1.0.2
Hi. The vote passed with 3 +1 binding votes. I'll finalize the release. - Andrei On Thu, May 2, 2024 at 9:43 AM Stefan Seifert wrote: > +1 > > stefan >
