[ 
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)

Reply via email to