[
https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024687#comment-13024687
]
David Valeri commented on CAMEL-3750:
-------------------------------------
I don't see the schema import issue you are referring to. The camel-spring
namespaced schema is generated from the concrete JAX-B beans in camel-spring
and the inherited JAX-B aspects of the abstract factory beans from
camel-core-xml. The camel-blueprint schema is generated from the concrete
JAX-B beans in camel-blueprint and the same inherited JAX-B aspects of the
abstract factory beans form camel-core-xml.
Both schema are generated in exactly the same way, the only difference is that
the NS is changed in the schema generated under camel-blueprint. It is changed
by this ant task in the build process:
{code:xml}
<replace file="${project.build.directory}/schema/camel-blueprint.xsd"
token="http://camel.apache.org/schema/spring";
value="http://camel.apache.org/schema/blueprint"; />
{code}
The same step can be applied to the schema for the util namespace generated
under blueprint. When it comes out of the generator it will have an import for
the Camel Spring namespace and itself will have a Spring NS. We can simply use
the replace task to replace the import with an import of the Blueprint
namespace and replace the schema namespace with a Camel Util Blueprint
namespace.
Since both the Blueprint and Spring handlers use JAX-B to deserialize the XML,
both NS handlers should be just fine with the NS import and deserialization
across elements from different namespaces.
I'm somewhat averse to putting everything in the main schema since some of the
type definitions have generic names such as Filter and it didn't seem to fit
well with the very DSL and CamelContext specific nature of the current
elements/types in the main schema (Spring and Blueprint).
> 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
