You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "exceptionfactory (via GitHub)" <gi...@apache.org> on 2023/06/28 22:44:34 UTC

[GitHub] [nifi] exceptionfactory commented on pull request #7446: NIFI-11536: implemented AbstractStoreScanner and KeyStoreScanner that…

exceptionfactory commented on PR #7446:
URL: https://github.com/apache/nifi/pull/7446#issuecomment-1612209337

   > I made the changes while still preserving `KeyStoreScanner` and `TrustStoreScanner` as the derived classes for two reasons.
   > 
   >     1. So the logger is class-specific
   
   It is not necessary to define a class-specific logger, although maintaining two separate class implementations might be useful based on the second concern.
   
   > 
   >     2. So the `server` would have beans with distinct types. Having all have the same type would cause some existing tests to fail since it uses `server.getBean`.
   
   That is a good point regarding `addBean` and `getBean`. With that in mind, it does seem reasonable to maintain two separate classes.
   
   > 
   > 
   > Some thoughts: I was wondering if we were to have just one class whether it's a good idea to have both a keystore scanner and truststore scanner in the same class. One advantage this would have is if both keystore and truststore changed, then the `SSLContext` would be reloaded only once, as opposed to having two scanners that reloaded it twice.
   
   Although having one class might be worth considering, in general the keystore and truststore should change independently, so keeping two separate classes sounds good.
   
   Thanks for considering the options.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org