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 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.
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