cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject RE: GenericApplicationContext for BusApplicationContext
Date Mon, 10 Sep 2007 10:46:23 GMT
It is a pleasure doing business with you. I'll implement accordingly.

> -----Original Message-----
> From: Willem Jiang []
> Sent: Monday, September 10, 2007 3:02 AM
> To:
> 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
> I'll add code to check for a lack-of-a-context, and then create one
> 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
> that I get when I ask the live service for the ?wsdl URL. Well, the
> way to be sure to really get exactly the same thing is to set up the
> service / endpoint, just as in the live application.
> >
> I got what you want , and adding the spring configuration of the
> factory in the tool could be more a comfortable way for customer
> up their service.
> > For applications that use Spring, this would be a natural
> to what I've drafted so far. We'd initialize an application context
> contained, in fact, the user's usual beans.
> >
> > (When I was coding this, my idea of the next step was to allow the
> to supply an xml file of beans that could override and supplement the
> trivial ones I introduced.)
> >
> You may need pass the bean's ID or just override the service builder
> something.
> > For applications that don't use Spring, I'm a bit at a loss. We
> invite them to supply a Java class that serves as a service factory.
> and I really don't like this idea, we could provide some other
> configuration language that allows them to express all the things they
> 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
> 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
> used the -databinding as a bean id?
> >
> I agree.
> > My design went like this: there are fundamentally a small set of
> bindings (represented by the enum) and the spring config (as extended
> the user) allows their customization. If we eliminate the enum, we
> 'there are any number of data bindings as supplied by beans, and users
> 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
> Spring, so we have to have a factories that can cough up things like
> 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.

View raw message