[jira] Issue Comment Edited: (CAMEL-2625) Improvements and minor change requests to camel-netty

["Claus Ibsen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58715#action_58715 ] 

Claus Ibsen edited comment on CAMEL-2625 at 4/9/10 4:22 AM:
------------------------------------------------------------

Looks good but this code
{code}
         sslHandler = component.resolveAndRemoveReferenceParameter(parameters, "sslHandler", SslHandler.class, null);
         passphrase = component.resolveAndRemoveReferenceParameter(parameters, "passphrase", String.class, null);
+        keyStoreFormat = component.resolveAndRemoveReferenceParameter(parameters, "keyStoreFormat", String.class, "JKS");
+        securityProvider = component.resolveAndRemoveReferenceParameter(parameters, "securityProvider", String.class, "SunX509");
         keyStoreFile = component.resolveAndRemoveReferenceParameter(parameters, "keyStoreFile", File.class, null);
         trustStoreFile = component.resolveAndRemoveReferenceParameter(parameters, "trustStoreFile", File.class, null);
         encoder = component.resolveAndRemoveReferenceParameter(parameters, "encoder", ChannelDownstreamHandler.class, new ObjectEncoder());
{code}
The method {{resolveAndRemoveReferenceParameter}} is essentially only needed when you have complex objects (eg SslHandler.class etc.).
When you have simple types such as a String, Number, Boolean etc. then they are not usually referenced/lookup up, and hence you would use
{{getAndRemoveParameter}} method instead (I think that is the name). refereneable

But the {{resolveAndRemoveReferenceParameter}} should fallback to the other method as well, so there is no harm. Just when reading the code you may be surprised the first time.

Also those new options should be added to the wiki page and their default values listed. Eg the SunX509 default may not run on IBM JDKs where you have to provide a provider that is included by IBM.

      was (Author: davsclaus):
    Looks good but this code
{code}
         sslHandler = component.resolveAndRemoveReferenceParameter(parameters, "sslHandler", SslHandler.class, null);
         passphrase = component.resolveAndRemoveReferenceParameter(parameters, "passphrase", String.class, null);
+        keyStoreFormat = component.resolveAndRemoveReferenceParameter(parameters, "keyStoreFormat", String.class, "JKS");
+        securityProvider = component.resolveAndRemoveReferenceParameter(parameters, "securityProvider", String.class, "SunX509");
         keyStoreFile = component.resolveAndRemoveReferenceParameter(parameters, "keyStoreFile", File.class, null);
         trustStoreFile = component.resolveAndRemoveReferenceParameter(parameters, "trustStoreFile", File.class, null);
         encoder = component.resolveAndRemoveReferenceParameter(parameters, "encoder", ChannelDownstreamHandler.class, new ObjectEncoder());
{code}
The method {{resolveAndRemoveReferenceParameter}} is essentially only needed when you have complex objects (eg SslHandler.class etc.).
When you have simple types such as a String, Number, Boolean etc. then they are not usually, and hence you would use
{{getAndRemoveParameter}} method instead (I think that is the name). refereneable

But the {{resolveAndRemoveReferenceParameter}} should fallback to the other method as well, so there is no harm. Just when reading the code you may be surprised the first time.

Also those new options should be added to the wiki page and their default values listed. Eg the SunX509 default may not run on IBM JDKs where you have to provide a provider that is included by IBM.
  
> Improvements and minor change requests to camel-netty
> -----------------------------------------------------
>
>                 Key: CAMEL-2625
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-2625
>             Project: Apache Camel
>          Issue Type: Improvement
>            Reporter: Ashwin Karpe
>            Assignee: Ashwin Karpe
>             Fix For: 2.3.0
>
>         Attachments: CAMEL-2625-camel-netty.zip, CAMEL-2625-Netty-Patch.diff
>
>
> (Request by Gareth Collins via nabble request...)
> Would it be possible to make the TrustManager optional for Netty SSL support? I made a change in my local version of camel-netty and it works for me (file org.apache.camel.component.netty.ssl.SSLEngineFactory - replacement for the original SSLEngineFactory constructor): 
> public SSLEngineFactory(File keyStoreFile, File trustStoreFile, char[] passphrase) throws Exception { 
>         super();         
>         
>         KeyStore ks = KeyStore.getInstance("JKS"); 
>         
>         ks.load(IOConverter.toInputStream(keyStoreFile), passphrase); 
>         
>         KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); 
>         kmf.init(ks, passphrase); 
>         
>         sslContext = SSLContext.getInstance(SSL_PROTOCOL); 
>         
>         
>         if (trustStoreFile != null) 
>         { 
>         
>         KeyStore ts = KeyStore.getInstance("JKS"); 
>         ts.load(IOConverter.toInputStream(trustStoreFile), passphrase); 
>         TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); 
>         tmf.init(ts); 
>         sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); 
>         } 
>         else 
>         { 
>         sslContext.init(kmf.getKeyManagers(), null, null); 
>         } 
>     } 
> I ask for this as I have to contact a server where SSL will not work properly if a TrustManager is installed. If this could go in before CAMEL 2.3 it would be much appreciated. 
> A couple of questions about the netty implementation: 
> (1) Is there a reason why JKS was hardcoded here, rather than allowing the key store format to be configured? 
> (2) When I add the TrustManager using netty for the connection where it could not be used, netty throws me no exception, the connection remains open, but the messages I send do not get to the server. If I connect directly using an SSLSocket I see a javax.net.ssl.SSLHandshakeException. Is there something I am missing here?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.