Re: Bus instance sharing among different ports ?
Hi, You may consider to configure the feature on endpoints and then share the same bus across these endpoints. On 7/4/12 11:40 PM, Ivan wrote: Hi, from the design side, is it too heavy to create one bus instance for each web service port ? If does, let's say, I have many serviceBeans, some of them are required to enable ws-security, and some of them may require to enable ws-addressing, it is possible to do that with the same bus instance and does it mean that all those interceptors and policy builder will be involved in the message processing ? Thanks. -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: Bus instance sharing among different ports ?
Hi, The map between bus and endpoint is very flexible in CXF. The multiple endpoints can share the same bus, and you can configure ws-security/ws-addressing per endpoint basis, so not all endpoints with same bus share same interceptors. Freeman On 2012-7-4, at 下午11:40, Ivan wrote: Hi, from the design side, is it too heavy to create one bus instance for each web service port ? If does, let's say, I have many serviceBeans, some of them are required to enable ws-security, and some of them may require to enable ws-addressing, it is possible to do that with the same bus instance and does it mean that all those interceptors and policy builder will be involved in the message processing ? Thanks. -- Ivan - 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
Bus instance sharing among different ports ?
Hi, from the design side, is it too heavy to create one bus instance for each web service port ? If does, let's say, I have many serviceBeans, some of them are required to enable ws-security, and some of them may require to enable ws-addressing, it is possible to do that with the same bus instance and does it mean that all those interceptors and policy builder will be involved in the message processing ? Thanks. -- Ivan
more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
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. Thanks. Regards, Aki
