Jim, I get anxious when I have too much code on my not-very-backed-up system. Please commit what I've posted so far, and I'll continue with the next steps in a subsequent patch. I would like to tackle the other direction as well, but I don't want to promise too far out since the next few weeks are going to be really crowded for me.
I apparently was up too late last night and misread remarks about wsdl2java as applying to java2wsdl :-) To avoid a repeat, I'm going to bed now. --benson > -----Original Message----- > From: Jim Ma [mailto:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 10:11 PM > To: [email protected] > Subject: Re: GenericApplicationContext for BusApplicationContext > > Hi Benson , > > Java2wsdl will be removed , so you do not need to do it in java2wsdl . > Will you add more feature in patch for CXF-807 (for example, > your next step to allow the user provide a xml file of beans)? > If do not , I will apply your patch for CXF-807. > > And also there are two tasks in wsdl2java , would you like to take one > of them ? > (1) add same thing to load data binding and other things in wsdl2ajva as > you provided in patch for java2ws. > (2) support aegis data binding in wsdl2java > > Thanks > > Jim > > Benson Margulies wrote: > > 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. > >>>>>> > >>>>>> > >>>>>> > >>> > > > >
