[
https://issues.apache.org/jira/browse/CASSANDRA-20450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936554#comment-17936554
]
Jeremiah Jordan commented on CASSANDRA-20450:
---------------------------------------------
The fact that the original code worked, and the new code does not, says to me
that if anyone actually made a test which wanted to use a different auth class,
it would fail with this class loader issue. The old way works because the
"defaultCls" is going to already have been made in the same distributed shared
class loader that the interface is in. Not sure if you want to try and fix it
now, or just leave a comment somewhere that we know actually using something
besides the default auth won't work.
> Fix simulator dtests after CASSANDRA-20368
> ------------------------------------------
>
> Key: CASSANDRA-20450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20450
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After CASSANDRA-20368 was merged, we are getting this in simulator dtests:
> {code:java}
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.auth.AllowAllAuthenticator cannot be cast to class
> org.apache.cassandra.auth.IAuthenticator
> (org.apache.cassandra.auth.AllowAllAuthenticator is in unnamed module of
> loader 'app'; org.apache.cassandra.auth.IAuthenticator is in unnamed module
> of loader org.apache.cassandra.distributed.shared.InstanceClassLoader
> @740abb5)
> at org.apache.cassandra.auth.AuthConfig.applyAuth(AuthConfig.java:54)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:284)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:269)
> at
> org.apache.cassandra.distributed.impl.Instance.partialStartup(Instance.java:710)
> {code}
> The problem is that after that was merged, we started to do this:
> {code:java}
> private static <T> T authInstantiate(ParameterizedClass authCls, Class<T>
> defaultCls) {
> if (authCls != null && authCls.class_name != null)
> {
> String authPackage = AuthConfig.class.getPackage().getName();
> return ParameterizedClass.newInstance(authCls, List.of("",
> authPackage));
> }
> return ParameterizedClass.newInstance(new
> ParameterizedClass(defaultCls.getName()), List.of());
> }{code}
> while previously it was this
> {code:java}
> private static <T> T authInstantiate(ParameterizedClass authCls, Class<T>
> defaultCls) {
> if (authCls != null && authCls.class_name != null)
> {
> String authPackage = AuthConfig.class.getPackage().getName();
> return ParameterizedClass.newInstance(authCls, List.of("",
> authPackage));
> }
> try
> {
> return defaultCls.newInstance();
> }
> catch (InstantiationException | IllegalAccessException e)
> {
> throw new ConfigurationException("Failed to instantiate " +
> defaultCls.getName(), e);
> }
> } {code}
> I am not completely sure what's the problem as "normally" it just works, but
> when using this code in connection with simulator, my suspicion is that it is
> using a different class loader and then creating an instance via
> ParameterizedClass.newInstance just messes it up on all the casts etc.
> The easy solution here is to just revert to "what was". The only functional
> difference here is that when a user does e.g. this in yaml
> {code}
> authorizer:
> {code}
> that means, setting authorizer literally to nothing (null), then what the
> current trunk code does (which broke the simulator tests) is that it will
> take AllowAllAuthorizer, checks what constructor it has and if it has map
> constructor it will prefer that one. If it does not have any map constructor,
> it will create an instance using no-arg constructor.
> I do not think there is any practical difference here so we might just revert
> to "what was".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
