You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "David Valeri (JIRA)" <ji...@apache.org> on 2011/03/03 21:35:36 UTC
[jira] Created: (CAMEL-3750) Provide a common mehanism to
facilitate configuration of TLS across Camel components
Provide a common mehanism to facilitate configuration of TLS across Camel components
------------------------------------------------------------------------------------
Key: CAMEL-3750
URL: https://issues.apache.org/jira/browse/CAMEL-3750
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-http, camel-jetty
Reporter: David Valeri
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:
KeyStoreParameters ksp = new KeyStoreParameters();
ksp.setResource(this.getClass().getClassLoader().getResource("jsse/localhost.ks").toString());
ksp.setPassword(pwd);
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyPassword(pwd);
kmp.setKeyStore(ksp);
TrustManagersParameters tmp = new TrustManagersParameters();
tmp.setKeyStore(ksp);
SSLContextParameters sslContextParameters = new SSLContextParameters();
sslContextParameters.setKeyManager(kmp);
sslContextParameters.setTrustManager(tmp);
XML Configuration:
<SSLContextParameters secureSocketProtocol="TLS">
<keyManager
keyPassword="password">
<keyStore resource="./localhost.jks" password="password"/>
</keyManager>
<secureSocketProtocolsFilter>
<include>TLS.*</include>
</secureSocketProtocolsFilter>
</SSLContextParameters>
Usage in a route:
from("jetty:https://localhost:443/hello?sslContextParametersRef=sslContextParameters").process(proc);
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034476#comment-13034476 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Hi David,
It's make sense to use the ClassResolver from the CamelContext in case the TCCL is not set.
We can provide camelContextId attribute on the JSSE if the user want to use it across the multiple CamelContext.
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: 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034486#comment-13034486 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Just applied the patch with thanks to David.
> 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
[jira] [Issue Comment Edited] (CAMEL-3750) Provide a common
mechanism to facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (CAMEL-3750) Provide a common mehanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Description:
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);
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyPassword(pwd);
kmp.setKeyStore(ksp);
TrustManagersParameters tmp = new TrustManagersParameters();
tmp.setKeyStore(ksp);
SSLContextParameters sslContextParameters = new SSLContextParameters();
sslContextParameters.setKeyManager(kmp);
sslContextParameters.setTrustManager(tmp);
{code}
XML Configuration:
{code:XML}
<SSLContextParameters secureSocketProtocol="TLS">
<keyManager
keyPassword="password">
<keyStore resource="./localhost.jks" password="password"/>
</keyManager>
<secureSocketProtocolsFilter>
<include>TLS.*</include>
</secureSocketProtocolsFilter>
</SSLContextParameters>
{code}
Usage in a route:
{code}
from("jetty:https://localhost:443/hello?sslContextParametersRef=sslContextParameters").process(proc);
{code}
was:
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:
KeyStoreParameters ksp = new KeyStoreParameters();
ksp.setResource(this.getClass().getClassLoader().getResource("jsse/localhost.ks").toString());
ksp.setPassword(pwd);
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyPassword(pwd);
kmp.setKeyStore(ksp);
TrustManagersParameters tmp = new TrustManagersParameters();
tmp.setKeyStore(ksp);
SSLContextParameters sslContextParameters = new SSLContextParameters();
sslContextParameters.setKeyManager(kmp);
sslContextParameters.setTrustManager(tmp);
XML Configuration:
<SSLContextParameters secureSocketProtocol="TLS">
<keyManager
keyPassword="password">
<keyStore resource="./localhost.jks" password="password"/>
</keyManager>
<secureSocketProtocolsFilter>
<include>TLS.*</include>
</secureSocketProtocolsFilter>
</SSLContextParameters>
Usage in a route:
from("jetty:https://localhost:443/hello?sslContextParametersRef=sslContextParameters").process(proc);
I should have a patch containing an initial implementation of the idea some time tomorrow. If this is something that would make it into the main code, I'll make it production worthy and submit it for inclusion.
> Provide a common mehanism to facilitate configuration of TLS across Camel components
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
>
> 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);
>
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyPassword(pwd);
> kmp.setKeyStore(ksp);
> TrustManagersParameters tmp = new TrustManagersParameters();
> tmp.setKeyStore(ksp);
>
> SSLContextParameters sslContextParameters = new SSLContextParameters();
> sslContextParameters.setKeyManager(kmp);
> sslContextParameters.setTrustManager(tmp);
> {code}
> XML Configuration:
> {code:XML}
> <SSLContextParameters secureSocketProtocol="TLS">
> <keyManager
> keyPassword="password">
> <keyStore resource="./localhost.jks" password="password"/>
> </keyManager>
> <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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: (was: CAMEL-3750.patch)
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023644#comment-13023644 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014995#comment-13014995 ]
Claus Ibsen commented on CAMEL-3750:
------------------------------------
When you load resources from classpath you should use the ClassResolver from CamelContext. It ensures we can have it working when using OSGi, JBoss, WebSphere and other containers.
We need unit tests for OSGi as well, as OSGi can play tricks on you.
And can you provide the patch in smaller pieces. Something for camel-core, and then for each component. Its easier to work with than a 300kb patch.
> 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: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Fix For: Future
>
> Attachments: CAMEL-3750.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);
>
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch
2011.05.24-CAMEL-3899-3946-camel-spring.patch
2011.05.24-CAMEL-3899-3946-camel-core-xml.patch
2011.05.24-CAMEL-3899-3946-camel-blueprint.patch
2011.05.24-CAMEL-3899-3946-camel-core.patch
Attaching patches for CAMEL-3899 and CAMEL-3946.
The patches include adding support for the optional use of ClassResolver in order to support Blueprint, the addition of Blueprint support, and support for Camel Property Placeholders.
> 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, 2011.05.24-CAMEL-3899-3946-camel-blueprint.patch, 2011.05.24-CAMEL-3899-3946-camel-core-xml.patch, 2011.05.24-CAMEL-3899-3946-camel-core.patch, 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch, 2011.05.24-CAMEL-3899-3946-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, 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043391#comment-13043391 ]
David Valeri commented on CAMEL-3750:
-------------------------------------
Apologies about the sloppy CS. I'll play with Eclipse again to make sure that plug-in is working right.
I wrapped up the documentation updates today so I think this is done for now.
> 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, 2011.05.24-CAMEL-3899-3946-camel-blueprint.patch, 2011.05.24-CAMEL-3899-3946-camel-core-xml.patch, 2011.05.24-CAMEL-3899-3946-camel-core.patch, 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch, 2011.05.24-CAMEL-3899-3946-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, 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040616#comment-13040616 ]
Claus Ibsen commented on CAMEL-3750:
------------------------------------
Thanks David your latest patches from May 25th is now in trunk. I polished them a bit and fixed CS.
> 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, 2011.05.24-CAMEL-3899-3946-camel-blueprint.patch, 2011.05.24-CAMEL-3899-3946-camel-core-xml.patch, 2011.05.24-CAMEL-3899-3946-camel-core.patch, 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch, 2011.05.24-CAMEL-3899-3946-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, 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-core-xml.patch
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750-camel-core-xml.patch, CAMEL-3750-camel-core.patch, CAMEL-3750-camel-spring.patch, CAMEL-3750.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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-http4.patch
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-spring.patch
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750-camel-core-xml.patch, CAMEL-3750-camel-core.patch, CAMEL-3750-camel-spring.patch, CAMEL-3750.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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: 2011.05.15-CAMEL-3750-core.patch
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019921#comment-13019921 ]
David Valeri commented on CAMEL-3750:
-------------------------------------
The attached patches should cover the requested changes. Let me know if anything is missing.
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Description:
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}
was:
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);
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}
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750.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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020998#comment-13020998 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Hi David
For number 1) A. If you take a look at the generated schema there is an schema import of "http://camel.apache.org/schema/spring"
But for the keyStoreParameters, secureRandomParameters and sslContextParameters they have nothing to do with the CamelContext, and they should support to be reused in different camel context. So I don't think they need to extend the AbstractCamelFactoryBean.
For number 1) B. I think the using the TCCL could be enough for SSLContextParameters to load the resource, as the spring application will set the TCCL with the application classloader, and the user can import the other bundle package if the resource is in the other bundle.
For number 2) It could be difficult to maintain schema map rightly if there are lots of http endpoints are deployed into the container like servicemix. I agree we leave http component this way, when we move the http-client4 we could drop the support camel-http.
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020304#comment-13020304 ]
David Valeri commented on CAMEL-3750:
-------------------------------------
For number 1)
A) Is there harm in extending AbstractCamelFactoryBean from core-xml? It appeared to be the pattern being followed by the Spring and Blueprint handlers. The pattern I see is AbstractCamelFactoryBean (core-xml) -> AbstractMyTypeFactoryBean (core-xml) -> ConcreteMyTypeFactoryBean (spring OR blueprint). I think this makes Blueprint support just a matter of implementing ConcreteMyTypeFactoryBean instances and a handler in the Blueprint module right? Is there some mistake in my abstract factory beans that is going to prevent adding Blueprint support down the road?
B) The SSLContextParameters use of ClassResolver was implemented per the earlier request from Claus. Originally the code was as follows:
{code:java}
try {
is = new FileInputStream(this.resource);
} catch (FileNotFoundException e) {
LOG.debug("Could not open resource as a file, trying as class path resource.", e);
}
if (is == null) {
is = this.getClass().getResourceAsStream(this.resource);
if (is == null) {
LOG.debug("Could not open resource as a class path resource using the "
+ this.getClass().getClassLoader()
+ " classloader. Trying as a class path resource with the TCCL (if set).");
}
}
if (is == null && Thread.currentThread().getContextClassLoader() != null) {
is = Thread.currentThread().getContextClassLoader().getResourceAsStream(this.resource);
if (is == null) {
LOG.debug("Could not open resource as a class path resource using the TCCL "
+ this.getClass().getClassLoader() + ". Trying as a URL.");
}
}
if (is == null) {
try {
is = new URL(this.resource).openStream();
} catch (IOException e) {
LOG.debug("Could not open resource as a URL.", e);
}
}
if (is == null) {
throw new IOException("Could not open " + this.resource + " as a file, class path resource, or URL.");
}
{code}
I didn't look through the ClassResolver implementations before making the requested change, but after reviewing OsgiClassResolver, it appears that it does not consult the TCCL. OsgiClassResolver only looks in the bundle that created the Camel context. I can see a case where the key store resource may be in another bundle from the one loading the context and accessible only through the bundle's classpath rather than through the Bundle contents. Perhaps both ClassResolver and the TCCL should be consulted?
2) The HTTP component's TLS support is a little limited because of how Commons HTTP 3.x supports TLS configuration. The 3.x branches lookup a "ProtocolSocketFactory" in a global repository provided by the Protocol class. I could accept sslContextParametersRef and set it into Protocol in the component, BUT the second endpoint the user creates using sslContextParametersRef is going to clobber the ProtocolSocketFactory configuration from the first endpoint since they both use the same schema name ("https"). Since this repository is global, used both inside and outside of the Camel component, and I think it would be exceedingly difficult to rework the component to cleanly support a per endpoint use of sslContextParametersRef, I opted for the simpler approach as show below.
{code:java}
SSLContextParameters params = new SSLContextParameters();
ProtocolSocketFactory factory =
new SSLContextParametersSecureProtocolSocketFactory(params);
Protocol.registerProtocol("https",
new Protocol(
"https",
factory,
443));
{code}
I suppose it might be possible to generate a schema name for each endpoint using the sslContextParametersRef parameter and register the ProtocolSocketFactory under that generated schema name. Then hand the URL off to Commons HTTP with the generated schema name.
So https://www.google.com?sslContextParametersRef=params1 would result in something like the following:
{code:java}
ProtocolSocketFactory factory =
new SSLContextParametersSecureProtocolSocketFactory(params1);
Protocol.registerProtocol("generatedSchemaName1",
new Protocol(
"https",
factory,
443));
{code}
Where Commons HTTP is actually handed the URL: generatedSchemaName1://www.google.com
I'd have to look at the HTTP component again to see if all of the needed information to do something like this is accessible or if there would be a fair bit of refactoring needed to get all of the information in the same spot.
> 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
[jira] [Assigned] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang reassigned CAMEL-3750:
-----------------------------------
Assignee: Willem Jiang
> 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-spring.patch, CAMEL-3750.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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-jetty.patch
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-itest-osgi.patch
> 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
Re: [jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by David Valeri <dv...@apache.org>.
Yes. They should be in the patch under the Camel Spring component. Let me
know if you find them to be missing as that indicates something is amiss
with my workspace.
David Valeri
-------------------
Twitter: DavidValeri
Blog: http://davidvaleri.wordpress.com/
FuseSource: http://fusesource.com
On Sat, Apr 2, 2011 at 9:04 PM, Johan Edstrom <se...@gmail.com> wrote:
> Do you have NamespaceHandlers for this as well?
>
> On Apr 2, 2011, at 3:46 PM, David Valeri (JIRA) wrote:
>
> >
> > [
> https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015082#comment-13015082]
> >
> > David Valeri commented on CAMEL-3750:
> > -------------------------------------
> >
> > Claus, thanks for taking a look and providing the feedback.
> >
> > I'll refactor the resource loading, add some OSGi based unit tests, and
> split the patch as requested. I'm guessing it will take me a week or two to
> find the time to to make these changes.
> >
> >> 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
> >> Fix For: Future
> >>
> >> Attachments: CAMEL-3750.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);
> >>
> >> 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
>
>
Re: [jira] [Commented] (CAMEL-3750) Provide a common mechanism to facilitate configuration of TLS across Camel components
Posted by Johan Edstrom <se...@gmail.com>.
Do you have NamespaceHandlers for this as well?
On Apr 2, 2011, at 3:46 PM, David Valeri (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015082#comment-13015082 ]
>
> David Valeri commented on CAMEL-3750:
> -------------------------------------
>
> Claus, thanks for taking a look and providing the feedback.
>
> I'll refactor the resource loading, add some OSGi based unit tests, and split the patch as requested. I'm guessing it will take me a week or two to find the time to to make these changes.
>
>> 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
>> Fix For: Future
>>
>> Attachments: CAMEL-3750.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);
>>
>> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015082#comment-13015082 ]
David Valeri commented on CAMEL-3750:
-------------------------------------
Claus, thanks for taking a look and providing the feedback.
I'll refactor the resource loading, add some OSGi based unit tests, and split the patch as requested. I'm guessing it will take me a week or two to find the time to to make these changes.
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750.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);
>
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-core.patch
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750-camel-core-xml.patch, CAMEL-3750-camel-core.patch, CAMEL-3750-camel-spring.patch, CAMEL-3750.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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-3750:
-------------------------------
Fix Version/s: (was: 2.8.0)
Future
Issue Type: New Feature (was: Improvement)
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750.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);
>
> 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
[jira] [Resolved] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang resolved CAMEL-3750.
---------------------------------
Resolution: Fixed
I think we can close this main issue and keep the sub issue open.
> 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, 2011.05.24-CAMEL-3899-3946-camel-blueprint.patch, 2011.05.24-CAMEL-3899-3946-camel-core-xml.patch, 2011.05.24-CAMEL-3899-3946-camel-core.patch, 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch, 2011.05.24-CAMEL-3899-3946-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, 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
[jira] [Issue Comment Edited] (CAMEL-3750) Provide a common
mechanism to facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015082#comment-13015082 ]
David Valeri edited comment on CAMEL-3750 at 4/2/11 9:46 PM:
-------------------------------------------------------------
Claus, thanks for taking a look and providing the feedback.
I'll refactor the resource loading, add some OSGi based unit tests, and split the patch as requested. I'm guessing it will take me a week or two to find the time to to make these changes.
I'll also document the feature once it makes it into the source tree.
was (Author: davaleri):
Claus, thanks for taking a look and providing the feedback.
I'll refactor the resource loading, add some OSGi based unit tests, and split the patch as requested. I'm guessing it will take me a week or two to find the time to to make these changes.
> 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
> Fix For: Future
>
> Attachments: CAMEL-3750.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);
>
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024713#comment-13024713 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Applied patch with thanks to David.
Now, we can think about adding support to camel-blueprint and other camel components such as camel-mina, camel-netty.
And we can create more sub task to trace these issues.
> 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, 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: 2011.04.22-CAMEL-3750-camel-spring.patch
2011.04.22-CAMEL-3750-camel-jetty.patch
2011.04.22-CAMEL-3750-camel-itest-osgi.patch
2011.04.22-CAMEL-3750-camel-http4.patch
2011.04.22-CAMEL-3750-camel-http.patch
2011.04.22-CAMEL-3750-camel-core-xml.patch
2011.04.22-CAMEL-3750-camel-core.patch
Attached updated patches that revert back to using the TCCL for resource resolution instead of ClassResolver and also remove AbstractCamelFactoryBean from the hierarchy. AbstractCamelFactoryBean was replaced with AbstractJsseUtilFactoryBean which does not have any awareness of a CamelContext. AbstractJsseUtilFactoryBean extends IdentifiedType; however, the dependency can be easily removed by adding an id field plus setter/getter pair into AbstractJsseUtilFactoryBean and removing the extension of IdentifiedType.
What is left to do in order to get this into the trunk? I'd like to add Blueprint support, but I wanted to know if it is possible to close out this ticket first and then add Blueprint support later?
> 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020186#comment-13020186 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Hi David,
I just have a quick review of the patch, here are my comments
1. For the schema of camel-core-util, I think we need to add support of blueprint.
Current camel-core-util schema is dependent on camel-spring, I think we could do this without extends the AbstractCamelFactoryBean, as we can inject the camel context in the camel-core-util NamespaceHandler.
And the only reason that I can tell that the SSLContextParameters depends on CamelContext is for using ClassResolver from CamelContext to load the resource, Maybe we can consider to relay on thread context classloader.
2. The http component doesn't support the sslContextParametersRef as the http4 component does, can you double check your patch?
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: 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024709#comment-13024709 ]
Willem Jiang commented on CAMEL-3750:
-------------------------------------
Hi David,
Yes, you can replace the NS like the blueprint does, but it will introduce other issue that there are two versions of JSSE parameters schema, one for spring and another for blueprint.
So I made some change on the camel-spring patch to let the JSSE parameters schema share the same NS with camel-spring, and it is easy to update the camel-blueprint part.
BTW, I will commit the patch shortly after running the tests.
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, 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Fix Version/s: 2.8.0
Description:
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);
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}
was:
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);
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyPassword(pwd);
kmp.setKeyStore(ksp);
TrustManagersParameters tmp = new TrustManagersParameters();
tmp.setKeyStore(ksp);
SSLContextParameters sslContextParameters = new SSLContextParameters();
sslContextParameters.setKeyManager(kmp);
sslContextParameters.setTrustManager(tmp);
{code}
XML Configuration:
{code:XML}
<SSLContextParameters secureSocketProtocol="TLS">
<keyManager
keyPassword="password">
<keyStore resource="./localhost.jks" password="password"/>
</keyManager>
<secureSocketProtocolsFilter>
<include>TLS.*</include>
</secureSocketProtocolsFilter>
</SSLContextParameters>
{code}
Usage in a route:
{code}
from("jetty:https://localhost:443/hello?sslContextParametersRef=sslContextParameters").process(proc);
{code}
Summary: Provide a common mechanism to facilitate configuration of TLS across Camel components (was: Provide a common mehanism to facilitate configuration of TLS across Camel components)
> 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: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Fix For: 2.8.0
>
> Attachments: CAMEL-3750-initial-proposal.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);
>
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: localhost.ks
> 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, 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
[jira] Updated: (CAMEL-3750) Provide a common mehanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-initial-proposal.patch
Attaching CAMEL-3750-initial-proposal.patch, an initial example of the suggested enhancement.
The patch currently lacks Spring Namespace unit tests as well as thorough unit tests of the JSSE configuration utility itself.
> Provide a common mehanism to facilitate configuration of TLS across Camel components
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Attachments: CAMEL-3750-initial-proposal.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);
>
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyPassword(pwd);
> kmp.setKeyStore(ksp);
> TrustManagersParameters tmp = new TrustManagersParameters();
> tmp.setKeyStore(ksp);
>
> SSLContextParameters sslContextParameters = new SSLContextParameters();
> sslContextParameters.setKeyManager(kmp);
> sslContextParameters.setTrustManager(tmp);
> {code}
> XML Configuration:
> {code:XML}
> <SSLContextParameters secureSocketProtocol="TLS">
> <keyManager
> keyPassword="password">
> <keyStore resource="./localhost.jks" password="password"/>
> </keyManager>
> <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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040609#comment-13040609 ]
Claus Ibsen commented on CAMEL-3750:
------------------------------------
David thanks for the latest patches. I will get them into trunk today. If we wait for long chances are the patching work gets more cumbersome for me.
> 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, 2011.05.24-CAMEL-3899-3946-camel-blueprint.patch, 2011.05.24-CAMEL-3899-3946-camel-core-xml.patch, 2011.05.24-CAMEL-3899-3946-camel-core.patch, 2011.05.24-CAMEL-3899-3946-camel-itest-osgi.patch, 2011.05.24-CAMEL-3899-3946-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, 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750-camel-http.patch
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: (was: 2011.05.15-CAMEL-3750-core.patch)
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: CAMEL-3750.patch
Attaching complete patch with tests and Spring NS handler support.
> 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: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Fix For: 2.8.0
>
> Attachments: CAMEL-3750.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);
>
> 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
[jira] Updated: (CAMEL-3750) Provide a common mehanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Patch Info: [Patch Available]
> Provide a common mehanism to facilitate configuration of TLS across Camel components
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-3750
> URL: https://issues.apache.org/jira/browse/CAMEL-3750
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Attachments: CAMEL-3750-initial-proposal.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);
>
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyPassword(pwd);
> kmp.setKeyStore(ksp);
> TrustManagersParameters tmp = new TrustManagersParameters();
> tmp.setKeyStore(ksp);
>
> SSLContextParameters sslContextParameters = new SSLContextParameters();
> sslContextParameters.setKeyManager(kmp);
> sslContextParameters.setTrustManager(tmp);
> {code}
> XML Configuration:
> {code:XML}
> <SSLContextParameters secureSocketProtocol="TLS">
> <keyManager
> keyPassword="password">
> <keyStore resource="./localhost.jks" password="password"/>
> </keyManager>
> <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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: 2011.05.15-CAMEL-3750-core.patch
Attaching patch with minor updates to the core utility classes to simplify configuration when using client/server specific overrides on only some of the shared configuration options.
> 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-3750:
-------------------------------
Fix Version/s: (was: Future)
2.8.0
> 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, 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
[jira] [Updated] (CAMEL-3750) Provide a common mechanism to
facilitate configuration of TLS across Camel components
Posted by "David Valeri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Valeri updated CAMEL-3750:
--------------------------------
Attachment: (was: CAMEL-3750-initial-proposal.patch)
> 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: Improvement
> Components: camel-core, camel-http, camel-jetty
> Reporter: David Valeri
> Fix For: 2.8.0
>
> Attachments: CAMEL-3750.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);
>
> 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