[
https://issues.apache.org/jira/browse/SENTRY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207256#comment-16207256
]
Mano Kovacs commented on SENTRY-1992:
-------------------------------------
[~spena], thank you for your quick response.
Yes, kafka binding configures it through that property. Actually, kafka binding
sets those fields in {{KafkaAuthBinding}}:
{noformat}
if (providerBackend instanceof SentryGenericProviderBackend) {
((SentryGenericProviderBackend)
providerBackend).setComponentType(COMPONENT_TYPE);
((SentryGenericProviderBackend)
providerBackend).setServiceName(instanceName);
}
{noformat}
This is the same code you find in {{SqoopAuthBinding}} and {{SolrAuthBinding}},
but using different configuration property.
This kind of beats the purpose of the abstraction and configurable backend
provider for the bindings. Unless these bindings separately handle this
implementation, it is not going to work, which makes this redundant code
necessary. However, the backend provider could require additional configuration
from the user. I think the binding itself should not know anything about the
actual implementation.
My proposal would eliminate the need for implementation-specific code in future
bindings.
> Improve parameter handling for SentryGenericProviderBackend
> -----------------------------------------------------------
>
> Key: SENTRY-1992
> URL: https://issues.apache.org/jira/browse/SENTRY-1992
> Project: Sentry
> Issue Type: Improvement
> Reporter: Mano Kovacs
>
> {{SentryGenericProviderBackend}} uses {{componentType}} and {{serviceName}}
> for sentry-service request but does not validate if it set, nor takes it from
> the configuration. That makes less modular to configure bindings.
> Proposing validation of the parameters and fallback for configuration entries.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)