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. Willem. 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 instead. > > 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 [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 07, 2007 10:35 PM >> To: [email protected] >> 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: >> http://www.nabble.com/GenericApplicationContext-for-BusApplicationContext- >> tf4403714.html#a12566180 >> Sent from the cxf-dev mailing list archive at Nabble.com. >> > >
