cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bim2...@basistech.com>
Subject RE: GenericApplicationContext for BusApplicationContext
Date Mon, 10 Sep 2007 10:50:03 GMT
I've seen cxf.xml but not bus-extensions.xml. I'll go look at the later.

It does occur to me that the use of Spring to set up these bindings in the tools is not so
much extending the bus as being an application. CXF applications (that use Spring) don't extend
the bus, they just create their own context, so maybe the tools should follow that pattern?
I'll report back after I read more code.

> -----Original Message-----
> From: Willem Jiang [mailto:ning.jiang@iona.com]
> Sent: Monday, September 10, 2007 12:31 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: GenericApplicationContext for BusApplicationContext
> 
> Hi Benson,
> 
> If you have chance to look at the cxf.xml[1] and bus-extensions.xml[2],
> you probably know what I mean about the #1.
> 
> Here are a already extension loading mechanism in the CXF bus now, we
> can just reuse it in the tool :)
> 
> [1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/r
> esources/META-INF/cxf/cxf.xml
> [2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/r
> esources/META-INF/bus-extensions.xml
> 
> Willem.
> 
> 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:ning.jiang@iona.com]
> >> Sent: Sunday, September 09, 2007 9:38 PM
> >> To: cxf-dev@incubator.apache.org
> >> 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:ning.jiang@iona.com]
> >>>> Sent: Friday, September 07, 2007 10:35 PM
> >>>> To: cxf-dev@incubator.apache.org
> >>>> 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.
> >>>>
> >>>>
> >>>
> >
> >

Mime
View raw message