[
https://issues.apache.org/jira/browse/CRYPTO-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334038#comment-15334038
]
Sebb commented on CRYPTO-81:
----------------------------
The current code uses the property parameter for two purposes: defining the
class name and providing properties to the class instance.
That seems wrong - what if the instance uses the same property name to mean
something else?
Moving the class name into a separate enum parameter would fix this.
However enums are only suitable for situations where the list of possible
values are known in advance.
This is true for any implementations provided by the Crypto product (the enum
can be extended when new implementations are provided), but what about external
implementations?
Is the Crypto code intended to support 3rd party implementations?
If so, then there needs to be a way to instantiate these.
> improve factory api for constructing Random & Cipher
> ----------------------------------------------------
>
> Key: CRYPTO-81
> URL: https://issues.apache.org/jira/browse/CRYPTO-81
> Project: Commons Crypto
> Issue Type: Bug
> Reporter: Xianda Ke
> Assignee: Xianda Ke
>
> currently, the client code to construct a CryptoRandom or CryptoCipher looks
> like this:
> {code}
> // code snippet (a)
> Properties props = new Properties();
> props.setProperty(
> ConfigurationKeys.COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY,
> OpensslCryptoRandom.class.getName());
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
> {code}
> or using configuration file, it looks like :
> {code}
> # config file
> secure.random.classes="org.apache.commons.crypto.random.OpensslCryptoRandom"
> {code}
> {code}
> // code snippet (b)
> {
> Properties props = loadMyApplicationConfig();
> // ...
> }
>
> {
> // bussiness logic ...
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
> // ...
> CryptoCipher cipher = CryptoCipherFactory.getInstance(transform, props);
> }
> {code}
> disadvantages:
> 1. if client user just want use openssl engine, trivial stuff in code
> snippet (a). it looks annoying.
> 2. Client user has to use the long long config key string such as
> "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY" or full name of classes
> Client user has to read source to learn how to config the properties.
> 3. the implementation classes such as JavaCryptoRandom, OsCryptoRandom and
> JavaCryptoRandom are public.
> it would be hard to change library implementation in future.
> if we just *use a enum (RandomProvider or CryptCipherProvider)*
> {code}
> // code snippet (c)
> // client code looks simple and elegant now:
> //RandomProvider.OS or RandomProvider.JAVA
> CryptoRandom random =
> CryptoRandomFactory.getCryptoRandom(RandomProvider.OPENSSL);
> {code}
> still, client user can use configuration file
> {code}
> # config file
> RandomProvider="OPENSSL"
> CryptCipherProvider="JCE"
> {code}
> {code}
> // code snippet
> {
> Properties props = loadMyApplicationConfig();
> RandomProvider randProvider =
> RandomProvider.valueOf(props.getProperty(p1));
> CryptoProvider cryptoRrovider
> =RandomProvider.valueOf(props.getProperty(p1));
> }
> {
> // bussiness logic ...
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(randProvider);
> // ...
> CryptoCipher cipher = CryptoCipherFactory.getInstance(transform,
> cryptoRrovider);
> }
> {code}
> advantages:
> 1. Simpler API. snippet (c) is simpler than snippet (a).
> 2. Modern IDE will hint that CryptoRandomFactory.getCryptoRandom() need a
> enum type (RandomProvider). client user do NOT have to search the long key
> string such as "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY". Modern IDE will
> tell client user how to config
> 3. we don't have to expose the implementation classes as public
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
