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
