cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: GenericApplicationContext for BusApplicationContext
Date Mon, 10 Sep 2007 01:37:30 GMT
Hi Benson,

My Chinese name is 姜宁, and you already has the Chinese input your
system :).

I went through the patch of CXF-807, you just want to create the front
end service builder and the data binding object in spring context.
Here are my concerns about it。

1. You use an enum DatabindingType to make the data binding object which
create by the spring connect with the JavaToWSDL processor.
It still have lots of hard codes there , I think you could introduce
some kind of data binding factory just like we do in the CXF transport
layer(DestinationFactoryManager and ConduitInitiatorManager) or the
binding layer(BindingFactoryManager). In this way we can add the
extensions more easy without change any code of the tools.

2. You make the tool a tied dependency on the spring bus's context.
We have two types bus factory in CXF, one is SpringBusFactory which
relays on the spring context(), the other is CXFBusFactory just creates
a simple extension bus(), which has nothing to do with the spring.
In your patch , you just make an assumption that the bus is spring bus,
so you can always get the application context form the bus. But if the
bus is create by the CXFBusFactory , you will get the null point
exception there.


Benson Margulies wrote:
> I'm sure I'll pick the wrong Hanzi, but ...
> 拧将,
> I didn't know about refresh. I read the big billboard on Spring javadoc on the class
in place now, and didn't realize that their proposed substitution had tradeoffs. So I agree
that changing the bus context is a bad idea.
> Anyway, the patch I posted for CXF-807 illustrates what I am up to.
> Here's the idea. In java2ws, we want users to be able to get the same wsdl that the ?wsdl
URL would produce from a live service. In a live service, the user can configure rather arbitrary
parameters by configuring beans.
> So, I thought, java2ws should have the option of reading a bean configuration to get
the user's desired service configuration.
> Initially, I thought that this would be best accomplished by adding their beans to the
BusApplicationContext, but when I ran into the issue with that, I tried making a child context
> It 'works' as far as I've done it, which is to use beans from an internal XML file to
just implement the -frontend and -databinding options. When I see if the community likes this,
I'll go on to add reading in additional XML for user overrides of the configuration.
> --benson
>> -----Original Message-----
>> From: Willem2 []
>> Sent: Friday, September 07, 2007 10:35 PM
>> To:
>> Subject: Re: GenericApplicationContext for BusApplicationContext
>> Hi Benson,
>> I don't think replace the ClassPathXmlApplicationContext with the
>> GenericApplicationContext is a good idea.
>> GenericApplicationContext do not support refresh :(
>> Can you elaborate your requirement of adding more definition  by using
>> XmlBeanDefinitionReaders?
>> And It is interesting to have the child contexts, can you also explain it ?
>> Willem.
>> bmargulies wrote:
>>> If BusApplicationContext extended GenericApplicationContext instead of
>>> the ClassPathXml... thing it implements now, then more definitions could
>>> be added later by using XmlBeanDefinitionReaders. I'm working on an idea
>>> that would make use of this. Would anyone object to a patch that just
>>> made this change (changing the BusApplicationContext)? Or would is there
>>> a preference to create child contexts of the main Bus context for
>>> situations like this?
>> --
>> View this message in context:
>> tf4403714.html#a12566180
>> Sent from the cxf-dev mailing list archive at

View raw message