You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@basistech.com> on 2007/09/07 22:50:25 UTC
GenericApplicationContext for BusApplicationContext
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?
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
Jim,
I get anxious when I have too much code on my not-very-backed-up system. Please commit what I've posted so far, and I'll continue with the next steps in a subsequent patch. I would like to tackle the other direction as well, but I don't want to promise too far out since the next few weeks are going to be really crowded for me.
I apparently was up too late last night and misread remarks about wsdl2java as applying to java2wsdl :-)
To avoid a repeat, I'm going to bed now.
--benson
> -----Original Message-----
> From: Jim Ma [mailto:ema@iona.com]
> Sent: Monday, September 10, 2007 10:11 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: GenericApplicationContext for BusApplicationContext
>
> Hi Benson ,
>
> Java2wsdl will be removed , so you do not need to do it in java2wsdl .
> Will you add more feature in patch for CXF-807 (for example,
> your next step to allow the user provide a xml file of beans)?
> If do not , I will apply your patch for CXF-807.
>
> And also there are two tasks in wsdl2java , would you like to take one
> of them ?
> (1) add same thing to load data binding and other things in wsdl2ajva as
> you provided in patch for java2ws.
> (2) support aegis data binding in wsdl2java
>
> Thanks
>
> Jim
>
> Benson Margulies wrote:
> > Jim,
> >
> > I thought I understood you all as asking me to focus on java2ws as it
> would be replacing java2wsdl. If it needs to be done in both places, I'll
> have a look.
> >
> > --benson
> >
> >
> >
> >> -----Original Message-----
> >> From: Jim Ma [mailto:ema@iona.com]
> >> Sent: Sunday, September 09, 2007 11:59 PM
> >> To: cxf-dev@incubator.apache.org
> >> Subject: Re: GenericApplicationContext for BusApplicationContext
> >>
> >> 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.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> >
> >
Re: GenericApplicationContext for BusApplicationContext
Posted by Jim Ma <em...@iona.com>.
Hi Benson ,
Java2wsdl will be removed , so you do not need to do it in java2wsdl .
Will you add more feature in patch for CXF-807 (for example,
your next step to allow the user provide a xml file of beans)?
If do not , I will apply your patch for CXF-807.
And also there are two tasks in wsdl2java , would you like to take one
of them ?
(1) add same thing to load data binding and other things in wsdl2ajva as
you provided in patch for java2ws.
(2) support aegis data binding in wsdl2java
Thanks
Jim
Benson Margulies wrote:
> Jim,
>
> I thought I understood you all as asking me to focus on java2ws as it would be replacing java2wsdl. If it needs to be done in both places, I'll have a look.
>
> --benson
>
>
>
>> -----Original Message-----
>> From: Jim Ma [mailto:ema@iona.com]
>> Sent: Sunday, September 09, 2007 11:59 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: GenericApplicationContext for BusApplicationContext
>>
>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>
>
>
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
Jim,
I thought I understood you all as asking me to focus on java2ws as it would be replacing java2wsdl. If it needs to be done in both places, I'll have a look.
--benson
> -----Original Message-----
> From: Jim Ma [mailto:ema@iona.com]
> Sent: Sunday, September 09, 2007 11:59 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: GenericApplicationContext for BusApplicationContext
>
> 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.
> >>>>
> >>>>
> >>>
> >
> >
Re: GenericApplicationContext for BusApplicationContext
Posted by Jim Ma <em...@iona.com>.
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.
>>>>
>>>>
>>>
>
>
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
It is a pleasure doing business with you. I'll implement accordingly.
> -----Original Message-----
> From: Willem Jiang [mailto:ning.jiang@iona.com]
> Sent: Monday, September 10, 2007 3:02 AM
> To: cxf-dev@incubator.apache.org
> 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
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.
Re: GenericApplicationContext for BusApplicationContext
Posted by Willem Jiang <ni...@iona.com>.
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.
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
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.
> >>>>
> >>>>
> >>>
> >
> >
Re: GenericApplicationContext for BusApplicationContext
Posted by Willem Jiang <ni...@iona.com>.
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/resources/META-INF/cxf/cxf.xml
[2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/resources/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.
>>>>
>>>>
>>>
>
>
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
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.
> >>
> >
> >
Re: GenericApplicationContext for BusApplicationContext
Posted by Willem Jiang <ni...@iona.com>.
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.
>>
>
>
RE: GenericApplicationContext for BusApplicationContext
Posted by Benson Margulies <bi...@basistech.com>.
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.
Re: GenericApplicationContext for BusApplicationContext
Posted by Willem2 <ni...@iona.com>.
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.