[ https://issues.apache.org/jira/browse/CRYPTO-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346093#comment-15346093 ]
Sebb commented on CRYPTO-74: ---------------------------- AIUI the custom provider needs to be provided in a separate jar with the file META-INF/services/org.apache.commons.crypto.random.CryptoRandom. If this is added to the classpath, it should be picked up in the same way as the META-INF/services file in the crypto jar > Full class names make code more difficult to update > --------------------------------------------------- > > Key: CRYPTO-74 > URL: https://issues.apache.org/jira/browse/CRYPTO-74 > Project: Commons Crypto > Issue Type: Improvement > Reporter: Sebb > > The method CryptoRandomFactory.getCryptoRandom uses the value of a property > as the full name of the CryptoRandom class to be instantiated. > This is inherently non-portable if the code package names should ever be > changed in future. > One way round this is to add a constant alias for the embedded > implementations. > For example: > CryptoRandomFactory.java > public static final String OPENSSL_RANDOM = "OpensslCryptoRandom"; > public static final String JAVA_RANDOM = "JavaCryptoRandom"; > ... > If the COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY string does not contain a > full class name, then the code would preprend the appropriate package name > (or there could be a lookup table). > This would also work for the case where the class is provided as a system > property value. > Another advantage of this method is that it simplifies the user code. > Similar considerations apply to all other factories which use class name > strings. > [Note: the constants must not contain the full package names as that would > result in a binary incompatibility if the names changed.] -- This message was sent by Atlassian JIRA (v6.3.4#6332)