When deploying an app in our Kubernetes infrastructure, the app doesn't fetch the token from some URI anymore, but the token is directly put into the file system. The tokens library can already work with this, but needs a different configuration in this case.
An application can currently do this by providing an own AccessTokenProvider bean, e.g. like this:
@Bean
public org.zalando.nakadiproducer.AccessTokenProvider nakadiProducerAccessTokenProvider() {
return () -> accessTokens.get("nakadi");
}
(This is assuming that accessTokens is a properly pre-configured AccessTokens bean, e.g. the one autoconfigured from tokens-spring-boot-starter, and there is a token named nakadi in there).
Our library should be able to discover such an existing AccessTokens bean itself and use it, instead of having to build its own one. (It should only be used if no Fahrschein NakadiClient is already there, though, see #75 .)
When deploying an app in our Kubernetes infrastructure, the app doesn't fetch the token from some URI anymore, but the token is directly put into the file system. The tokens library can already work with this, but needs a different configuration in this case.
An application can currently do this by providing an own AccessTokenProvider bean, e.g. like this:
(This is assuming that
accessTokens
is a properly pre-configuredAccessTokens
bean, e.g. the one autoconfigured from tokens-spring-boot-starter, and there is a token namednakadi
in there).Our library should be able to discover such an existing AccessTokens bean itself and use it, instead of having to build its own one. (It should only be used if no Fahrschein NakadiClient is already there, though, see #75 .)