[
https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023644#comment-13023644
]
Willem Jiang edited comment on CAMEL-3750 at 4/24/11 9:41 AM:
--------------------------------------------------------------
Hi David,
After digging the code more, I think we should put the JSSE parameters into the
camel-spring schema namespace to avoid the schema import issue when we need to
add the support in blueprint and we could do the same thing with the
camel-blueprint. I'm working on it now :)
Now I need you to attach the "org/apache/camel/util/jsse/localhost.ks" as a
separate file, it looks localhost.ks is lost in the patch file.
{code}
Index: src/test/resources/org/apache/camel/util/jsse/localhost.ks
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: src/test/resources/org/apache/camel/util/jsse/localhost.ks
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
{code}
Willem
was (Author: njiang):
Hi David,
I think we could move the schema generation of JSSE utility factory into
camel-core-xml, this time we don't need to follow the camel factory beam model,
as the JSSE parameter object doesn't need to do any addition work to create a
object. In this way we just has one schema for the the JSSE parameter :). Do
worry, I'm hacking this part of work now.
Now I need you to attach the "org/apache/camel/util/jsse/localhost.ks" as a
separate file, it looks localhost.ks is lost in the patch file.
{code}
Index: src/test/resources/org/apache/camel/util/jsse/localhost.ks
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: src/test/resources/org/apache/camel/util/jsse/localhost.ks
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
{code}
Willem
> Provide a common mechanism to facilitate configuration of TLS across Camel
> components
> -------------------------------------------------------------------------------------
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
> Issue Type: New Feature
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Assignee: Willem Jiang
> Fix For: Future
>
> Attachments: 2011.04.22-CAMEL-3750-camel-core-xml.patch,
> 2011.04.22-CAMEL-3750-camel-core.patch,
> 2011.04.22-CAMEL-3750-camel-http.patch,
> 2011.04.22-CAMEL-3750-camel-http4.patch,
> 2011.04.22-CAMEL-3750-camel-itest-osgi.patch,
> 2011.04.22-CAMEL-3750-camel-jetty.patch,
> 2011.04.22-CAMEL-3750-camel-spring.patch, CAMEL-3750-camel-core-xml.patch,
> CAMEL-3750-camel-core.patch, CAMEL-3750-camel-http.patch,
> CAMEL-3750-camel-http4.patch, CAMEL-3750-camel-itest-osgi.patch,
> CAMEL-3750-camel-jetty.patch, CAMEL-3750-camel-spring.patch
>
>
> CXF provides a nice Spring Namespace handler for configuring TLS options on
> the Jetty transport. Configuring these options using XML in Spring or
> through a simplified set of utility classes decreases the learning curve for
> users by sheltering them from the horrors of JSSE.
> There are a large number of components in Camel that deal with socket
> communication at some level, but they all require users to learn the specific
> low level configuration capabilities of the library on which the component is
> based in order to configure custom TLS options.
> It would be convenient if users didn't need to learn the advanced networking
> configuration options for each component.
> This enhancement suggests a similar Spring Namespace handler and utility
> classes that allow for simplified configuration of an SSLContext as well as
> adding provisions to some of the Camel components in order to accept this new
> configuration mechanism. The initial components to support the new
> configuration mechanism are the http, http4, and Jetty components. Other
> components would follow.
> An example usage is below.
> Programmatic configuration:
> {code}
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(this.getClass().getClassLoader().getResource("jsse/localhost.ks").toString());
> ksp.setPassword(pwd);
> ksp.setContext(context);
>
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyPassword(pwd);
> kmp.setKeyStore(ksp);
> TrustManagersParameters tmp = new TrustManagersParameters();
> tmp.setKeyStore(ksp);
>
> SSLContextParameters sslContextParameters = new SSLContextParameters();
> sslContextParameters.setKeyManagers(kmp);
> sslContextParameters.setTrustManagers(tmp);
> {code}
> XML Configuration:
> {code:XML}
> <SSLContextParameters id="sslContextParameters" secureSocketProtocol="TLS">
> <keyManagers
> keyPassword="password">
> <keyStore resource="./localhost.jks" password="password"/>
> </keyManagers>
> <secureSocketProtocolsFilter>
> <include>TLS.*</include>
> </secureSocketProtocolsFilter>
> </SSLContextParameters>
> {code}
> Usage in a route:
> {code}
> from("jetty:https://localhost:443/hello?sslContextParametersRef=sslContextParameters";).process(proc);
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
