Jim, I thought I understood you all as asking me to focus on java2ws as it would be replacing java2wsdl. If it needs to be done in both places, I'll have a look.
--benson > -----Original Message----- > From: Jim Ma [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 09, 2007 11:59 PM > To: [email protected] > Subject: Re: GenericApplicationContext for BusApplicationContext > > Hi Beanson, > > Your patch for CXF-807 is OK for me. > > For #1,I think there is no need to add other configuration language for > the applications that does not use Spring .We can > provide more flags(advanced flags) to generate same wsdl as in the > running application. That is to say , we provide two > ways to configure java2ws tool : Spring configuration file and tool flags. > > There is another thing in my mind , so far wsdl2java also can not > support spring configuration and aegis data binding . > We also need to add this to wsdl2java and use the same mechanism to load > service factory and data binding. We also need to > refactor wsdl2java to add this feature. Thoughts? > > Regards > > Jim > > 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. > >>>> > >>>> > >>> > > > >
