[
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.