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.
