sonarcloud[bot] commented on PR #51:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/51#issuecomment-2109187204
## [ and bundle c (in
[
https://issues.apache.org/jira/browse/SLING-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845989#comment-17845989
]
Joerg Hoh commented on SLING-12316:
---
https://github.com/apache/sling-org-apache-sling-engine/pull/43
[
https://issues.apache.org/jira/browse/SLING-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh reassigned SLING-12316:
-
Assignee: Joerg Hoh
> Servlet Name might be set incorrectly after an exception
>
Joerg Hoh created SLING-12316:
-
Summary: Servlet Name might be set incorrectly after an exception
Key: SLING-12316
URL: https://issues.apache.org/jira/browse/SLING-12316
Project: Sling
Issue
reschke commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107970625
Yes, indeed.
So it seems we we missed the case implementation objects leak the
dependency. For now we should open tickets for each that we encounter, we
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845977#comment-17845977
]
Stefan Seifert commented on SLING-12302:
for 1.: this looks like a bug, i assume that it
rombert commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107641629
> Yes, that's why we have removed Oak from the public Oak API.
I think you meant 'removed Guava', right? At any rate, for closely
integrated bundles like
reschke commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107614606
Yes, that's why we have removed Oak from the public Oak API.
--
This is an automated message from the Apache Git Service.
To respond to the message, please
rombert commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107549956
> Oak's shaded Guava lib should be treated just as any other Oak component,
such as [oak-core](https://issues.apache.org/jira/browse/OAK-core). I'm not
sure
reschke commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107533908
Oak's shaded Guava lib should be treated just as any other Oak component,
such as oak-core. I'm not sure what's different?
--
This is an automated message
rombert commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107526113
@reschke - the problem is that there seems to be no way to have a
SlingRepository implementation without pulling in Guava transitively. If you do
see a way of
reschke commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107521572
And no, by all means do not inline internal Oak classes!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on
reschke commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107516285
The goal definitively way for Oak not to leak any Guava-ish stuff in the
public APIs. AFAICT, this has been the case for approximately one year now.
That
rombert commented on PR #18:
URL:
https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2107505437
> 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
rombert commented on PR #10:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/10#issuecomment-2107499868
@enapps-enorman - good catch with the `AuthInfoImpl`. I hand-rolled a
different implementation (which does not seem to work, not sure why). But we
still have
Hi,
In https://github.com/apache/sling-org-apache-sling-i18n/pull/13 a
discussion was started regarding javax.servlet / jakarta.servlet
support.
The PR as it is requires both packages to resolve ( javax.servlet /
jakarta.servlet ), which means users that only have javax.servlet
support would be
rombert commented on PR #13:
URL:
https://github.com/apache/sling-org-apache-sling-i18n/pull/13#issuecomment-2107431441
> Why can't the EE8 loyalists just stay on the old version of
org.apache.sling.i18n?
I don't think "loyalists" is the right term here. And we don't typically get
sonarcloud[bot] commented on PR #14:
URL:
https://github.com/apache/sling-org-apache-sling-i18n/pull/14#issuecomment-2107393290
## [