Hi Benson， If you have chance to look at the cxf.xml[1] and bus-extensions.xml[2], you probably know what I mean about the #1.
Here are a already extension loading mechanism in the CXF bus now, we can just reuse it in the tool :) [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/resources/META-INF/cxf/cxf.xml [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/resources/META-INF/bus-extensions.xml Willem. Benson Margulies wrote: > Willem, > > Thanks for looking at this. Here are some thoughts in response. > > For #2, I think my code will work OK, since it will end up passing a null > pointer for the parent app context, and that should be OK. If not, I'll add > code to check for a lack-of-a-context, and then create one with no parent. > > For #1, you raise a question that has been on my mind. > > For me, when I want to run java2ws, I want to get exactly the same thing that > I get when I ask the live service for the ?wsdl URL. Well, the only way to be > sure to really get exactly the same thing is to set up the full service / > endpoint, just as in the live application. > > For applications that use Spring, this would be a natural modification to > what I've drafted so far. We'd initialize an application context that > contained, in fact, the user's usual beans. > > (When I was coding this, my idea of the next step was to allow the user to > supply an xml file of beans that could override and supplement the two > trivial ones I introduced.) > > For applications that don't use Spring, I'm a bit at a loss. We could invite > them to supply a Java class that serves as a service factory. Or, and I > really don't like this idea, we could provide some other configuration > language that allows them to express all the things they can express in > setting up the bus and their particular service from code. > > Does this line of thought make any sense to anyone else? > > Putting that line of thought aside for a moment ... > > With respect to the enum ... > > In the tools, we need some way to map from command-line parameters to a > databinding object (suitably configured). What if I deleted the enum and used > the -databinding as a bean id? > > My design went like this: there are fundamentally a small set of data > bindings (represented by the enum) and the spring config (as extended by the > user) allows their customization. If we eliminate the enum, we say, 'there > are any number of data bindings as supplied by beans, and users can add > whatever they want to the XML.' > > A user could have all the databinding they wanted to by just setting them up > in the XML. The factory is provided by the simple use of scope='prototype'. > > I'm reasoning this way: in the overall project, we don't want to impose > Spring, so we have to have a factories that can cough up things like data > bindings. But in the tools, we can just use Spring for factories. > > It wouldn't surprise me if I'm missing something important here. > > > > > >> -----Original Message----- >> From: Willem Jiang [mailto:[EMAIL PROTECTED] >> Sent: Sunday, September 09, 2007 9:38 PM >> To: [email protected] >> Subject: Re: GenericApplicationContext for BusApplicationContext >> >> 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. >>>> >>>> >>> > >
