cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Ma <...@iona.com>
Subject Re: GenericApplicationContext for BusApplicationContext
Date Mon, 10 Sep 2007 03:59:17 GMT
Hi Beanson,

Your patch for CXF-807 is OK for me.

For #1,I think there is no need to add other configuration language for
the applications that does not use Spring .We can
provide more flags(advanced flags) to generate same wsdl as in the
running application. That is to say , we provide two
ways to configure java2ws tool : Spring configuration file and tool flags.

There is another thing in my mind , so far wsdl2java also can not
support spring configuration and aegis data binding .
We also need to add this to wsdl2java and use the same mechanism to load
service factory and data binding. We also need to
refactor wsdl2java to add this feature. Thoughts?

Regards

Jim

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