Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/
I just committed a quick fix for it. Sergey, if you have time, please double check it. On Wed Jul 4 08:44:12 2012, Freeman Fang wrote: Hi Sergey, This commit break some jaxrs tests in 2.5.x branch, they're org.apache.cxf.jaxrs.utils.InjectionUtilsTest.testHandleParameterWithXmlAdapterOnInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsClass org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreTypesOnly Those test failed since Project CXF-2.5.x #337[1] on CI and afterwards. The reason for CodeGeneratorProviderTest failure is because there's another extra Books.class in addition to the classes listed, as CodeGeneratorProviderTest get removed from trunk and 2.6.x branches, so I'm not sure CodeGeneratorProviderTest is still valid based on current jaxrs code. The InjectionUtilsTest failed because the code Object id = InjectionUtils.handleParameter(value, true, Id.class, new Annotation[] {}, ParameterType.PATH, createMessage()); now return id as a String.class, but not the expected Id.class. Could you please take a look? [1]https://builds.apache.org/job/CXF-2.5.x/337/#showFailuresLink Thanks Freeman On 2012-6-27, at 下午7:58, serg...@apache.org wrote: Author: sergeyb Date: Wed Jun 27 11:58:32 2012 New Revision: 1354452 URL: http://svn.apache.org/viewvc?rev=1354452view=rev Log: Merged revisions 1354451 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes r1354451 | sergeyb | 2012-06-27 12:55:57 +0100 (Wed, 27 Jun 2012) | 24 lines Merged revisions 1354447 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes r1354447 | sergeyb | 2012-06-27 12:51:30 +0100 (Wed, 27 Jun 2012) | 17 lines Merged revisions 1354441-1354442,1354446 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r1354441 | sergeyb | 2012-06-27 12:44:38 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4396] Checking a port when 0.0.0.0 address gets replaced r1354442 | sergeyb | 2012-06-27 12:45:33 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Passing corect type for adapters bound to interfaces to be discoverd r1354446 | sergeyb | 2012-06-27 12:49:57 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Minor optimization Modified: cxf/branches/2.4.x-fixes/ (props changed) cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXBUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/HttpUtilsTest.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/InjectionUtilsTest.java Propchange: cxf/branches/2.4.x-fixes/ -- Merged /cxf/branches/2.5.x-fixes:r1354451 Merged /cxf/trunk:r1354441-1354446 Merged /cxf/branches/2.6.x-fixes:r1354447 Propchange: cxf/branches/2.4.x-fixes/ -- Binary property 'svnmerge-integrated' - no diff available. Modified: cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java URL: http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java?rev=1354452r1=1354451r2=1354452view=diff == --- cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java (original) +++ cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java Wed Jun 27 11:58:32 2012 @@ -200,7 +200,10 @@ public final class HttpUtils { if (!absolute) { u = URI.create(base + u.toString()); } else { -u = URI.create(u.toString().replace(ANY_IP_ADDRESS, serverAndPort)); +int originalPort = u.getPort(); +String replaceValue = originalPort == -1 ? ANY_IP_ADDRESS +: ANY_IP_ADDRESS + : + originalPort; +u = URI.create(u.toString().replace(replaceValue, serverAndPort)); } } return u; Modified:
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/
Oh, sorry, completely missed it. Will look asap Cheers, Sergey On 05/07/12 10:02, Willem Jiang wrote: I just committed a quick fix for it. Sergey, if you have time, please double check it. On Wed Jul 4 08:44:12 2012, Freeman Fang wrote: Hi Sergey, This commit break some jaxrs tests in 2.5.x branch, they're org.apache.cxf.jaxrs.utils.InjectionUtilsTest.testHandleParameterWithXmlAdapterOnInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsClass org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreTypesOnly Those test failed since Project CXF-2.5.x #337[1] on CI and afterwards. The reason for CodeGeneratorProviderTest failure is because there's another extra Books.class in addition to the classes listed, as CodeGeneratorProviderTest get removed from trunk and 2.6.x branches, so I'm not sure CodeGeneratorProviderTest is still valid based on current jaxrs code. The InjectionUtilsTest failed because the code Object id = InjectionUtils.handleParameter(value, true, Id.class, new Annotation[] {}, ParameterType.PATH, createMessage()); now return id as a String.class, but not the expected Id.class. Could you please take a look? [1]https://builds.apache.org/job/CXF-2.5.x/337/#showFailuresLink Thanks Freeman On 2012-6-27, at 下午7:58, serg...@apache.org wrote: Author: sergeyb Date: Wed Jun 27 11:58:32 2012 New Revision: 1354452 URL: http://svn.apache.org/viewvc?rev=1354452view=rev Log: Merged revisions 1354451 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes r1354451 | sergeyb | 2012-06-27 12:55:57 +0100 (Wed, 27 Jun 2012) | 24 lines Merged revisions 1354447 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes r1354447 | sergeyb | 2012-06-27 12:51:30 +0100 (Wed, 27 Jun 2012) | 17 lines Merged revisions 1354441-1354442,1354446 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r1354441 | sergeyb | 2012-06-27 12:44:38 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4396] Checking a port when 0.0.0.0 address gets replaced r1354442 | sergeyb | 2012-06-27 12:45:33 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Passing corect type for adapters bound to interfaces to be discoverd r1354446 | sergeyb | 2012-06-27 12:49:57 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Minor optimization Modified: cxf/branches/2.4.x-fixes/ (props changed) cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXBUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/HttpUtilsTest.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/InjectionUtilsTest.java Propchange: cxf/branches/2.4.x-fixes/ -- Merged /cxf/branches/2.5.x-fixes:r1354451 Merged /cxf/trunk:r1354441-1354446 Merged /cxf/branches/2.6.x-fixes:r1354447 Propchange: cxf/branches/2.4.x-fixes/ -- Binary property 'svnmerge-integrated' - no diff available. Modified: cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java URL: http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java?rev=1354452r1=1354451r2=1354452view=diff == --- cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java (original) +++ cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java Wed Jun 27 11:58:32 2012 @@ -200,7 +200,10 @@ public final class HttpUtils { if (!absolute) { u = URI.create(base + u.toString()); } else { - u = URI.create(u.toString().replace(ANY_IP_ADDRESS, serverAndPort)); + int originalPort = u.getPort(); + String replaceValue = originalPort == -1 ? ANY_IP_ADDRESS + : ANY_IP_ADDRESS + : + originalPort; + u = URI.create(u.toString().replace(replaceValue, serverAndPort)); } } return u; Modified: cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java URL: http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java?rev=1354452r1=1354451r2=1354452view=diff == ---
Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/
Hi Willem, Freeman Willem, the fix looks OK, thanks for doing it, I was doing the merge to 2.5.x manually so that led to that broken code Cheers, Sergey On 05/07/12 10:08, Sergey Beryozkin wrote: Oh, sorry, completely missed it. Will look asap Cheers, Sergey On 05/07/12 10:02, Willem Jiang wrote: I just committed a quick fix for it. Sergey, if you have time, please double check it. On Wed Jul 4 08:44:12 2012, Freeman Fang wrote: Hi Sergey, This commit break some jaxrs tests in 2.5.x branch, they're org.apache.cxf.jaxrs.utils.InjectionUtilsTest.testHandleParameterWithXmlAdapterOnInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsInterface org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsClass org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreTypesOnly Those test failed since Project CXF-2.5.x #337[1] on CI and afterwards. The reason for CodeGeneratorProviderTest failure is because there's another extra Books.class in addition to the classes listed, as CodeGeneratorProviderTest get removed from trunk and 2.6.x branches, so I'm not sure CodeGeneratorProviderTest is still valid based on current jaxrs code. The InjectionUtilsTest failed because the code Object id = InjectionUtils.handleParameter(value, true, Id.class, new Annotation[] {}, ParameterType.PATH, createMessage()); now return id as a String.class, but not the expected Id.class. Could you please take a look? [1]https://builds.apache.org/job/CXF-2.5.x/337/#showFailuresLink Thanks Freeman On 2012-6-27, at 下午7:58, serg...@apache.org wrote: Author: sergeyb Date: Wed Jun 27 11:58:32 2012 New Revision: 1354452 URL: http://svn.apache.org/viewvc?rev=1354452view=rev Log: Merged revisions 1354451 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes r1354451 | sergeyb | 2012-06-27 12:55:57 +0100 (Wed, 27 Jun 2012) | 24 lines Merged revisions 1354447 via svnmerge from https://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes r1354447 | sergeyb | 2012-06-27 12:51:30 +0100 (Wed, 27 Jun 2012) | 17 lines Merged revisions 1354441-1354442,1354446 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r1354441 | sergeyb | 2012-06-27 12:44:38 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4396] Checking a port when 0.0.0.0 address gets replaced r1354442 | sergeyb | 2012-06-27 12:45:33 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Passing corect type for adapters bound to interfaces to be discoverd r1354446 | sergeyb | 2012-06-27 12:49:57 +0100 (Wed, 27 Jun 2012) | 1 line [CXF-4379] Minor optimization Modified: cxf/branches/2.4.x-fixes/ (props changed) cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXBUtils.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/HttpUtilsTest.java cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/InjectionUtilsTest.java Propchange: cxf/branches/2.4.x-fixes/ -- Merged /cxf/branches/2.5.x-fixes:r1354451 Merged /cxf/trunk:r1354441-1354446 Merged /cxf/branches/2.6.x-fixes:r1354447 Propchange: cxf/branches/2.4.x-fixes/ -- Binary property 'svnmerge-integrated' - no diff available. Modified: cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java URL: http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java?rev=1354452r1=1354451r2=1354452view=diff == --- cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java (original) +++ cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java Wed Jun 27 11:58:32 2012 @@ -200,7 +200,10 @@ public final class HttpUtils { if (!absolute) { u = URI.create(base + u.toString()); } else { - u = URI.create(u.toString().replace(ANY_IP_ADDRESS, serverAndPort)); + int originalPort = u.getPort(); + String replaceValue = originalPort == -1 ? ANY_IP_ADDRESS + : ANY_IP_ADDRESS + : + originalPort; + u = URI.create(u.toString().replace(replaceValue, serverAndPort)); } } return u; Modified: cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java URL:
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
2012/7/5 Sergey Beryozkin sberyoz...@gmail.com: Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Hi Sergey, yes. I was thinking about introducing an optional ref attribute in some suitable places to do ref=mybean. Here are some examples. The current configuration looks like this: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore type=JKS password=password file=my/file/dir/Morpit.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=password file=my/file/dir/Truststore.jks/ /sec:trustManagers ... Depending on where we allow this optional ref attribute, we could have several variations in referencing. For example, we could allow this attribute in the root level as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters ref=mytlsbean ... In this case, you could configure this bean directly and setting each of its bean attributes. This may not be very convenient, but it is simple and does not require any schema changes to its sub components. or we could allow the ref attribute in the key/trustManagers level, as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers ref=mykeymanagersbean/ sec:trustManagers ref=mytrustmanagersbean/ ... or in the keystore level: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore ref=mykeystorebean/ ... I would like to hear if people want to have something like these. Thanks. Regards, aki Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Hi Aki, On 05/07/12 11:58, Aki Yoshida wrote: 2012/7/5 Sergey Beryozkinsberyoz...@gmail.com: Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Hi Sergey, yes. I was thinking about introducing an optional ref attribute in some suitable places to do ref=mybean. Here are some examples. The current configuration looks like this: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore type=JKS password=password file=my/file/dir/Morpit.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=password file=my/file/dir/Truststore.jks/ /sec:trustManagers ... Depending on where we allow this optional ref attribute, we could have several variations in referencing. For example, we could allow this attribute in the root level as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters ref=mytlsbean ... In this case, you could configure this bean directly and setting each of its bean attributes. This may not be very convenient, but it is simple and does not require any schema changes to its sub components. or we could allow the ref attribute in the key/trustManagers level, as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers ref=mykeymanagersbean/ sec:trustManagers ref=mytrustmanagersbean/ ... or in the keystore level: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore ref=mykeystorebean/ ... I would like to hear if people want to have something like these. IMHO both options look good, +1 from me Thanks, Sergey Thanks. Regards, aki Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
+1,it makes our life easier to share the security parameter beans across the http conduit. On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote: Hi Aki, On 05/07/12 11:58, Aki Yoshida wrote: 2012/7/5 Sergey Beryozkinsberyoz...@gmail.com: Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Hi Sergey, yes. I was thinking about introducing an optional ref attribute in some suitable places to do ref=mybean. Here are some examples. The current configuration looks like this: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore type=JKS password=password file=my/file/dir/Morpit.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=password file=my/file/dir/Truststore.jks/ /sec:trustManagers ... Depending on where we allow this optional ref attribute, we could have several variations in referencing. For example, we could allow this attribute in the root level as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters ref=mytlsbean ... In this case, you could configure this bean directly and setting each of its bean attributes. This may not be very convenient, but it is simple and does not require any schema changes to its sub components. or we could allow the ref attribute in the key/trustManagers level, as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers ref=mykeymanagersbean/ sec:trustManagers ref=mytrustmanagersbean/ ... or in the keystore level: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore ref=mykeystorebean/ ... I would like to hear if people want to have something like these. IMHO both options look good, +1 from me Thanks, Sergey Thanks. Regards, aki Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
more flexibility in configuring httpconduit's tlsClientParameters using spring or blueprint?
Hi Team, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation supported by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. Thanks. Regards, Aki
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Sounds good to me, +1 Freeman On 2012-7-5, at 下午10:28, Willem Jiang wrote: +1,it makes our life easier to share the security parameter beans across the http conduit. On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote: Hi Aki, On 05/07/12 11:58, Aki Yoshida wrote: 2012/7/5 Sergey Beryozkinsberyoz...@gmail.com: Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Hi Sergey, yes. I was thinking about introducing an optional ref attribute in some suitable places to do ref=mybean. Here are some examples. The current configuration looks like this: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore type=JKS password=password file=my/file/dir/Morpit.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=password file=my/file/dir/Truststore.jks/ /sec:trustManagers ... Depending on where we allow this optional ref attribute, we could have several variations in referencing. For example, we could allow this attribute in the root level as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters ref=mytlsbean ... In this case, you could configure this bean directly and setting each of its bean attributes. This may not be very convenient, but it is simple and does not require any schema changes to its sub components. or we could allow the ref attribute in the key/trustManagers level, as in http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers ref=mykeymanagersbean/ sec:trustManagers ref=mytrustmanagersbean/ ... or in the keystore level: http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit; http:tlsClientParameters sec:keyManagers keyPassword=password sec:keyStore ref=mykeystorebean/ ... I would like to hear if people want to have something like these. IMHO both options look good, +1 from me Thanks, Sergey Thanks. Regards, aki Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang - Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042