[
https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034180#comment-13034180
]
David Valeri commented on CAMEL-3750:
-------------------------------------
Willem,
Regarding the earlier discussion that ended with this:
{quote}
1.B) If we stick to TCCL for KeyStoreParameters, the need for a CamelContext
reference is removed and nothing in the entire JSSE util hierarchy will need a
reference to a CamelContext. SSLContextParameters et al. can then be reused
across CamelContexts as desired. I think this is a nice feature. Is there a
good use case where a resource would be in a bundle but not on the bundle
classpath, thus justifying the use of the CamelContext and ClassResolver?
Before I revert the incorporation of ClassResolver, are there other use cases
in other containers that justify the use of ClassResolver over or in addition
to the original approach listed in my above comment?
{quote}
I think we now have 2 good use cases for using the ClassResolver in addition to
the TCCL: CAMEL-3899 and CAMEL-3946. The Camel property placeholders will be
an invaluable feature for those not using Spring and I think we are going to
need the OsgiClassResolver in Blueprint as the TCCL is not always going to be
set to the loading bundle's class loader as is the case with Spring DM.
If you know of another way around the TCCL issue in Blueprint, let me know.
Otherwise I will plan on reintroducing support for the JSSE utility classes to
be CamelContext aware for use of the ClassResolver (in addition to the TCCL)
and Camel property placeholder.
In order to make the configuration portable across multiple CamelContext's,
perhaps I can pass in a context when the build methods are called rather than
when creating/configuring the builders.
> 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: 2.8.0
>
> 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, 2011.05.15-CAMEL-3750-core.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, localhost.ks
>
>
> 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
