camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-2625) Improvements and minor change requests to camel-netty
Date Fri, 09 Apr 2010 04:21:08 GMT

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

Claus Ibsen commented on CAMEL-2625:
------------------------------------

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.


Mime
View raw message