cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: Code First Binding Creation
Date Wed, 25 Oct 2006 11:29:41 GMT
Why not have a version of the createService() method in the 
ServiceFactoryBeans (ReflectionServiceFactoryBean, 
JaxwsServiceFactoryBean etc, i.e. in an abstract base) that takes a 
bindingId as a parameter - which replaces/supersedes the namespace of 
the first child element of the wsdl:binding element that would be used 
in the wsdl first approach.
Applicaton code then does not have to be aware of the 
manager-factory-work pattern - only the factory beans have to.
This would also be helpful to build a service model and an endpoint from 
wsdls that do not actually contain a binding elements, e.g. wsrm.wsdl. 


Dan Diephouse wrote:

> OK, hopefully this will be the last time I respond to my own message 
> :-) I think there is also a third option:
> JaxWsServiceFactoryBean serviceFactory = ...;
> ....
> BindingInfoFactoryManager bifm = ...
> BindingInfoFactory bif = bifm.getBindingInfoFactory("namespace");
> bif.createBinding(serviceFactory);
> Where createBinding creates a binding on serviceFactory.getService();
> Though I do get sick of all this indirection: Manager->Factory->Work, 
> this whole pattern seems to becoming really prevalent in our 
> architecture and it seems there should be a Better Way....
> - Dan
> Dan Diephouse wrote:
>> One other small issue, if we go with the manager approach it needs to 
>> create a new BindingInfoFactory when someone requests one as 
>> BindingInfoFactorys are stateful. So it'd be:
>> void registerBindingInfoFactoryBean(String name, Class 
>> bindInfoFactoryBeanClass);
>> as opposed to:
>> void registerBindingInfoFactoryBean(String name, 
>> AbstractBindingInfoFactoryBean bindInfoFactoryBean);
>> Cheers,
>> - Dan
>> Dan Diephouse wrote:
>>> I spent a bit of time looking at this today, and as I said earlier, 
>>> I'm not sure that the manager approach is the right one. But I'm not 
>>> sure what the right one is either :-). I like the discovery portion 
>>> of the manager approach, but I think the bindinginfofactories do 
>>> need to be coupled to the frontends and I also think there is some 
>>> power in the approach where you can do:
>>> sf = new ServerFactoryBean()
>>> bif = new SoapBindingInfoFactoryBean();
>>> bif.setStyle("document");
>>> sf.setBindingInfoFactory(bif);
>>> that is, I like how you can set up the binding easily via the API & 
>>> getters/setters.
>>> I'm wondering what the solution might be and here's what I've come 
>>> up with so far...
>>> 1. Keep the bean style approach and either a) require jax-ws to have 
>>> specific knowledge of the bindinginfofactory or b) have the user use 
>>> our internal APIs to specify their own bindinginfofactory
>>> 2. Have some sort of manager in the simple/jax-ws frontend
>>> I guess the two approaches don't have to be opposed. That is we 
>>> could try looking up a BindingInfoFactory from the manager or the 
>>> user could also specify their own.
>>> Thoughts? Other ideas?
>>> - Dan
>>> Dan Diephouse wrote:
>>>> wrote:
>>>>> Author: ningjiang
>>>>> Date: Mon Oct 16 05:54:27 2006
>>>>> New Revision: 464472
>>>>> URL:
>>>>> Log:
>>>>> [JIRA CXF-18] PhaseTow: Implemented BindingInfoFactoryBeanManager 
>>>>> to load the BingInfoFactoryBean just like BingFactoryManager. 
>>>>> Moved form frontend/simple to 
>>>>> api Moved form frontend/simple to 
>>>>> SoapBinding
>>>>> Added for creating XMLBinding in 
>>>>> codefirst mode.
>>>> Finally got around to looking at this change and I'm not real keen 
>>>> on it.
>>>> BindingInfoFactorys are highly tied to front ends and 
>>>> servicefactorys. For instance, in the Jax-Ws module we need a 
>>>> version of the SoapBindingInfoFactory which looks at the 
>>>> @SOAPBinding annotations. So it will need access to the information 
>>>> the service factory. We can't remove the setServiceFactory() method 
>>>> from the BindingInfoFactoryBean and replace it with the 
>>>> setService(). It is JAX-WS that needs to know about SOAP, not SOAP 
>>>> that needs to know about JAX-WS.
>>>> I do understand that some discovery mechanism may be needed but I 
>>>> think trying to promote this as a top level concept isn't the right 
>>>> approach. I'm going to take a look a refactoring this a bit.
>>>> Cheers,
>>>> - Dan

View raw message