[
https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021383#comment-13021383
]
David Valeri commented on CAMEL-3750:
-------------------------------------
Willem,
Thanks for clarifying 1 A and B for me. I understand what you are getting at
now.
1.A) Like you pointed out, the schema import is caused by the use of classes
such as IdentifiedType and AbstractCamelFactoryBean in the JSSE XML related
factory bean hierarchy. I agree that if we do remove the CamelContext
dependency, that AbstractCamelFactoryBean can come out of the hierarchy and
only things like IdentifiedType are needed in the factory bean hierarchy.
However, that still means that the XML schema for the JSSE utility factory
beans has a need to import the main Camel schema because the ComplexType for
the IdentifiedType class is still defined there. I think this import is likely
OK if we get rid of the Camel aware parts brought in by
AbstractCamelFactoryBean and only extend IdentifiedType.
This import in the generated schema will be OK in Blueprint as well. In the
Blueprint module, the import will just change to use the IdentifiedType
ComplexType from the Camel Blueprint namespace instead of the Camel Spring
namespace.
Ultimately, it is not a big deal to eliminate IdentifiedType from the hierarchy
as well. I don't have a strong enough reason for extending IdentifiedType to
justify not removing it, so if you think it best to remove it from the
hierarchy too, I will make this change.
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?
> 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: 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
