It is a pleasure doing business with you. I'll implement accordingly.
> -----Original Message----- > From: Willem Jiang [mailto:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 3:02 AM > To: [email protected] > Subject: Re: GenericApplicationContext for BusApplicationContext > > Hi Benson , > Please see my comments in the mail. > > 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. > > > I got what you want , and adding the spring configuration of the service > factory in the tool could be more a comfortable way for customer setting > up their service. > > 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.) > > > You may need pass the bean's ID or just override the service builder or > something. > > 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? > > > OK ,forget about what I mentioned of the other applications that don't > use Spring. I just want to tell you the CXF runtime would start up > without spring configuration, but it still need wire the endpiont some > where. And I am still the big Spring fan ,who like the way of wiring the > whole endpoint with Spring. > > 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? > > > I agree. > > 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. > > > Yes , I agree. > > It wouldn't surprise me if I'm missing something important here. > > > > > > > > > > Willem.
