[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152569#comment-16152569 ] Eric Hubert commented on CASSANDRA-13396: - We faced the same underlying issue after upgrading from Cassandra 3.9 to 3.11.0 when using Cassandra embedded for integration testing using JUnit. As our application uses a different logging backend and we did not want to switch it and provide appropriate redundant configuration for logback, we excluded logback dependencies and only provided our implementation to also avoid any warnings about duplicate bindings. This setup worked fine with Cassandra 3.9, but fails with Cassandra >= 3.10; the server does not startup, because of the missing classes. So in this case any patch working with instanceof checks still attempting to load those classes without specific try/catch would obviously also fail. In addition to SMAwareReconfigureOnChangeFilter in org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install() using multiple logback internals (added with CASSANDRA-12535) I also found the change with CASSANDRA-12509 adding ch.qos.logback.core.hook.DelayingShutdownHook in StorageService#initServer problematic. Would it be an alternative to handle all access to the underlying logging implementation via reflection? E.g. attempting to load logback classes and only if this does not fail, perform implementation specific actions via reflection (otherwise log a warning about missing logback presence, which can be ignored in integration test setups). We are mostly talking about one-time initialization, so the performance impact should be really negligible. This solution would require users to properly exclude logback logging libs if they want to use other sf4j implementation bindings. Providing multiple logging implementations with sl4fj bindings anyway triggers a warning which should be handled. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364749#comment-16364749 ] Eric Hubert commented on CASSANDRA-13396: - [~jasobrown], maybe you can have a glance on [my comment|#comment-16152569] as well. I have not started working on a patch, because I did not receive any feedback on my suggestion on a conceptual level. I did not want to waste time working on an implementation without knowing of a chance of inclusion. Because we faced some issues in production which are either fixed in 3.11.1 or will be fixed in 3.11.2 we really would like to update, but this still blocks us. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364865#comment-16364865 ] Eric Hubert commented on CASSANDRA-13396: - [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running alongside an application using slf4j with any slf4j supported backend != logback your are in trouble and no longer able to start the cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentation between embedded and standalone similar to "runManaged" to only allow/support other logging backends (skip special logging backend specific configuration) if CassandraDeamon is used/configured differently than from main() as done by a standalone server installation, this this is really a concern you want to see addressed. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364865#comment-16364865 ] Eric Hubert edited comment on CASSANDRA-13396 at 2/16/18 2:42 PM: -- [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running in the same JVM alongside an application using slf4j with any slf4j supported backend != logback after upgrading to Cassandra 3.10 or later you are in trouble and no longer able to start the Cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentiation between embedded and standalone usage similar to "runManaged" in CassandraDeamon to only allow/support other logging backends (skip special logging backend specific configuration) when CassandraDeamon is used/configured differently than done from main() used by a standalone server installation, if this is really a concern you want to see addressed. Even in this case one should exchange nasty runtime exceptions or even JVM errors (ClassCastException or NoClassDefFoundError) with a dedicated error message: "When using a Cassandra standalone installation the only supported logging backend is logback." For ClassCastException add something like "slf4j is currently bound to a different logging framework. Please ensure your classpath only contains logback implementations!" For NoClassDefFoundError add something like "No logback implementation was found. Please ensure your classpath contains the bundled logback implementation!" You can decide to abort the startup or have the same behavior as for the embedded case, but only providing a detailed error logging regarding the unsupported setup. For embedded use cases one could advice programmers to activate the CassandraDaemon differently (e.g. some parameter) and here I would propose to simply not execute all logback specific configuration logic - e.g. try loading specific logback classes via reflection, so in this mode logback could be easily replaced by any slf4j logging backend which the application currently uses without further adjustments. JUnit test cases might be a bit tricky, because I think they involve different classpath setups of the used test runner to simulate/trigger those type of issues. was (Author: ehubert): [~jasobrown], fair enough. From what I read/understood the majority of users (if not all, definitely including us) facing this issue, wanted to use Cassandra as an embedded server (mostly for integration testing purposes) utilizing class org.apache.cassandra.service.CassandraDaemon - so no production deployment of a standalone server or cluster. While running alongside an application using slf4j with any slf4j supported backend != logback your are in trouble and no longer able to start the cassandra server, although logging/logging performance are none of your (primary) goals/concerns. I doubt there are many users who want to configure a standalone single or multi-node Cassandra installation using a different logging backend to use this in production and have your support, but many users want to write automated integration/scenario tests of their own application interacting with Cassandra using an embedded Cassandra server in addition to plain unit tests using mocks without being forced to switch the logging backend chosen for their application for similar reasons you have. Therefore I see no conflict at all. An implementation could even somehow enforce the differentation between embedded and standalone similar to "runManaged" to only allow/support other logging backends (skip special logging backend specific configuration) if CassandraDeamon is used/configured differently than from main() as done by a standalone server installation, this this is really a concern you want to see addressed. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412701#comment-16412701
]
Eric Hubert commented on CASSANDRA-13396:
-
[~jasobrown] thanks for your feedback, which helped me to adjust the logging
implementation detection from using an slf4j implementation depended mechanism
({{StaticLoggerBinder}}) instead just using what is available via its public
API {{org.slf4j.LoggerFactory#getILoggerFactory()}} which is totally sufficient
for this purpose (see updated patch [^CASSANDRA-13396_ehubert_3.patch]).
I now also tested some slf4j backend implemenations with different versions of
slf4j:
+slf4j 1.7.12 - JUL:+
WARNING: You are using Cassandra with an unsupported deployment. The intended
logging implementation library logback is not used by slf4j. Detected slf4j
logger factory: org.slf4j.*impl*.JDK14LoggerFactory. You will not be able to
dynamically manage log levels via JMX and may have performance or other issues.
+slf4j 1.7.12 - Logback 1.1.3 or 1.2.3:+
No warning - successful Cassandra startup
+slf4j 1.8.0-beta2 - JUL:+
WARNING: You are using Cassandra with an unsupported deployment. The intended
logging implementation library logback is not used by slf4j. Detected slf4j
logger factory: org.slf4j.*jul*.JDK14LoggerFactory. You will not be able to
dynamically manage log levels via JMX and may have performance or other issues.
+slf4j 1.8.0-beta2 - Logback 1.3.0-alpha4+
_logback depencendy upgrade to 1.3.0 required - slf4j upgrade to 1.8.x should
only be done once logback 1.3.x release is availabe_
No warning - successful Cassandra startup
I did not test whether the logback-implementation specific code (with my patch
centralized in {{org.apache.cassandra.utils.logging.LogbackLoggingSupport}}) is
still working properly after this library upgrade. I only tested implementation
detection does not need to be adjusted when upgrading to the newer slf4j
version.
> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
>
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
> Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch,
> CASSANDRA-13396_ehubert_2.patch, CASSANDRA-13396_ehubert_3.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated CASSANDRA-13396: Attachment: CASSANDRA-13396_ehubert_3.patch > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch, > CASSANDRA-13396_ehubert_2.patch, CASSANDRA-13396_ehubert_3.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412806#comment-16412806 ] Eric Hubert commented on CASSANDRA-13396: - Just in case it makes it easier for you or others to review: https://github.com/apache/cassandra/pull/210/files > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch, > CASSANDRA-13396_ehubert_2.patch, CASSANDRA-13396_ehubert_3.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated CASSANDRA-13396: Comment: was deleted (was: Just in case it makes it easier for you or others to review: https://github.com/apache/cassandra/pull/210/files) > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch, > CASSANDRA-13396_ehubert_2.patch, CASSANDRA-13396_ehubert_3.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated CASSANDRA-13396:
Status: Patch Available (was: Open)
Hi [~jasobrown]! Today, I took some time to prepare a patch against the
Cassandra 3.11 branch which basically:
* bundles all logback implementation specific functionality in one class
(required a bit of code reorganization)
* extracted an interface to be able to a) minimize use of reflection and b) be
able to provide alternative implementations (the patch itself only provides a
no-op fallback implementation)
* load and instantiate logging-implementation specific extension according to
used slf4j binding via reflection (Cassandra code only works on new interface
which has no java class dependencies to specific implementations)
So far there are no new (integration) tests which likely would also require
some classpath / ClassLoader magic.
I tested the change using "a neutral" application use case by utilizing
[Cassandra Unit|https://github.com/jsevellec/cassandra-unit].
The "test" involved adjusting log4j config from Cassandra Unit test resources,
changing the used cassandra-all version in parent pom, excluding logback deps
from the pom and executing any of the tests.
With stock Cassandra 3.11.2 we see:
{code:java}
2018-03-20 10:51:43,753 [pool-2-thread-1] ERROR
cassandra.service.CassandraDaemon - Exception encountered during startup
java.lang.NoClassDefFoundError: ch/qos/logback/classic/Logger
at
org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install(ThreadAwareSecurityManager.java:92)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:192)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:602)
at
org.cassandraunit.utils.EmbeddedCassandraServerHelper.lambda$startEmbeddedCassandra$1(EmbeddedCassandraServerHelper.java:144)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.Logger
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
{code}
Using the patch [^CASSANDRA-13396_ehubert_1.patch] I provided we have a
successful server startup with a warning:
{code:java}
2018-03-20 13:47:32,688 [pool-2-thread-1] WARN
utils.logging.LoggingSupportFactory - You are using Cassandra with an
unsupported deployment. The intended logging implementation library logback is
not used by slf4j. Detected slf4j binding: org.slf4j.impl.Log4jLoggerFactory.
You will not be able to dynamically manage log levels via JMX and may have
performance or other issues.
{code}
Please consider this as an initial patch suggestion to gather quick feedback on
the approach! I'm willing to adjust things according to your requirements or
are happy if you like to tweak it to your requirements.
Would be great to see this in Cassandra 3.11.3 if possible.
> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
>
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
> Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated CASSANDRA-13396: Attachment: CASSANDRA-13396_ehubert_1.patch > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411069#comment-16411069 ] Eric Hubert commented on CASSANDRA-13396: - Anyone with some feedback on my submitted patch? I may have some time tomorrow to incorporate feedback/make adjustments etc, but next week might become rather busy. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412205#comment-16412205 ] Eric Hubert commented on CASSANDRA-13396: - Hi Jason! Sorry about the patch file. I now quickly recreated it from command line using git diff after pulling all updates from the 3.11 branch and attached it as [^CASSANDRA-13396_ehubert_2.patch]. Regarding your question about alternatives to determine the logging implementation slf4j bound to when using slf4j >= 1.8 I do not think this will be much related to Jigsaw modularization (although I may be wrong). Looks like they make use of the long existing ServiceLoader JDK implementation (AFAIK since JDK6). I happily offer to investigate this. Other alternatives to simply do something similar by attempting to load specific implementation classes via reflection is by far not as elegant if you ask me. > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch, > CASSANDRA-13396_ehubert_2.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[ https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated CASSANDRA-13396: Attachment: CASSANDRA-13396_ehubert_2.patch > Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager > > > Key: CASSANDRA-13396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13396 > Project: Cassandra > Issue Type: Bug >Reporter: Edward Capriolo >Assignee: Eugene Fedotov >Priority: Minor > Attachments: CASSANDRA-13396_ehubert_1.patch, > CASSANDRA-13396_ehubert_2.patch > > > https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412255#comment-16412255
]
Eric Hubert commented on CASSANDRA-13396:
-
I'm willing to test this out, but I think for slf4j >=1.8 we may need something
like the following untested litte utility method to do the job of determining
the binding
{code}
private static SLF4JServiceProvider determineSlf4jProvider()
{
ServiceLoader serviceLoader =
ServiceLoader.load(SLF4JServiceProvider.class);
Iterator serviceIterator =
serviceLoader.iterator();
if (serviceIterator.hasNext())
{
return serviceIterator.next();
} else {
return new NOPServiceProvider()
}
}
{code}
or via reflection make org.slf4j.LoggerFactory#getProvider() accessible and
call it
or provde an own class in package org.slf4j and wrap this static message call
to this package-scoped method.
Maybe this is all not necessary and one can directly work with public
org.slf4j.LoggerFactory#getILoggerFactory() using the bound provider to return
a implementation-specific factory. As said, I'll happily have a closer look at
this. I'm pretty sure something which can be addressed rather easily. The
latter might even be somehow possible to use for a compatible implementation
although returned implementation classes are very likely completely different
for those slf4j versions.
> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
>
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
> Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch,
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
