[ 
https://issues.apache.org/jira/browse/JAMES-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16353273#comment-16353273
 ] 

ASF GitHub Bot commented on JAMES-2330:
---------------------------------------

Github user chibenwa commented on a diff in the pull request:

    https://github.com/apache/james-project/pull/103#discussion_r166176208
  
    --- Diff: 
server/protocols/protocols-library/src/main/java/org/apache/james/protocols/lib/netty/AbstractConfigurableAsyncServer.java
 ---
    @@ -104,7 +104,7 @@
     
         private String secret;
     
    -    private Encryption encryption;
    +    protected Encryption encryption;
    --- End diff --
    
    Hi @randymo.
    
    I understand your needs, and I understand current code do not allow to 
satisfy it.
    
    In this discussion, people are trying to bring additional flexibility to 
classes using inheritance, which sounds like a bad idea. I know this area of 
the code is a bit "old school". But maybe we can give a try to do this well by 
composition.
    
    I would propose to add a new **interface** : 
    
    ```
    public interface EncryptionProvider {
        enum EncryptionMode {
            None,
            StartTls,
            Ssl
        }
    
        class KeystoreInformation { // Name could be improved?
            private final String keystoreLocation;
            private final char[] secret;
            private final String algorithm;
    
            // ... Boiler plate
        }
    
        Encryption get(EncryptionMode encryptionMode, KeystoreInformation 
keystoreInformation);
    }
    ```
    We can then have the 'standard' implementation of it being a lazy provider 
around the current version of `buildSSLContext`.
    
    Then, **AbstractConfigurableAsyncServer** could use this interface in its 
`init` method. We would have removed the burdon of managing SSL from this 
already huge class while enabling you to pass **your** SSL logic.
    
    It also brings in the possibility to store the keystore in a database. Or 
to generate a fake one for testing/ demonstration/ quick-start purposes.
    
    Would that sound like a good idea?
    



> Give ability to override AbstractConfigurableAsyncServer.buildSSLContext
> ------------------------------------------------------------------------
>
>                 Key: JAMES-2330
>                 URL: https://issues.apache.org/jira/browse/JAMES-2330
>             Project: James Server
>          Issue Type: Bug
>          Components: SMTPServer
>    Affects Versions: 3.0.1
>            Reporter: Randal Modowski
>            Priority: Major
>              Labels: easyfix
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I was trying to have my smtp server be able to serve different certs to user 
> based on remote ip, but couldn't the way james is curretly.
> I am creating a PR to make buildSSLContext protect as well as the Encryption 
> field itself. Also making all reference to Encryption use the getEncryption() 
> in case someone wants to override that call as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to