Re: svn commit: r464472 - in /incubator/cxf/trunk: api/src/main/java/org/apache/cxf/binding/ api/src/main/java/org/apache/cxf/service/model/ rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/ rt/bindings/soap/src/main/resources/META-INF/ rt/bindin...

[Dan Diephouse <da...@envoisolutions.com>]

ningjiang@apache.org wrote:

>Author: ningjiang
>Date: Mon Oct 16 05:54:27 2006
>New Revision: 464472
>
>URL: http://svn.apache.org/viewvc?view=rev&rev=464472
>Log:
>[JIRA CXF-18] PhaseTow: Implemented BindingInfoFactoryBeanManager to load the BingInfoFactoryBean just like BingFactoryManager. 
>Moved AbstractBindingInfoFactoryBean.java form frontend/simple to api 
>Moved SoapBindingInfoFactoryBean.java form frontend/simple to SoapBinding
>Added XMLBindingInfoFactoryBean.java 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

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com

Re: Code First Binding Creation

[Andrea Smyth <an...@iona.com>]

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. 
<http://schemas.xmlsoap.org/ws/2005/02/rm/wsdl/wsrm.wsdl>

Andrea.


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:
>>>
>>>> ningjiang@apache.org wrote:
>>>>
>>>>> Author: ningjiang
>>>>> Date: Mon Oct 16 05:54:27 2006
>>>>> New Revision: 464472
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=464472
>>>>> Log:
>>>>> [JIRA CXF-18] PhaseTow: Implemented BindingInfoFactoryBeanManager 
>>>>> to load the BingInfoFactoryBean just like BingFactoryManager. 
>>>>> Moved AbstractBindingInfoFactoryBean.java form frontend/simple to 
>>>>> api Moved SoapBindingInfoFactoryBean.java form frontend/simple to 
>>>>> SoapBinding
>>>>> Added XMLBindingInfoFactoryBean.java 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
>>>>
>>>
>>>
>>
>>
>
>