cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: GenericApplicationContext for BusApplicationContext
Date Mon, 10 Sep 2007 07:02:23 GMT
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
> 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.


View raw message