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:
[EMAIL PROTECTED] 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
