cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mika Göckel <mika.goec...@gmx.de>
Subject Re: Configuration Requirements CXF
Date Tue, 05 Sep 2006 09:48:50 GMT
Hi Jervis,

frankly, more the contrary. Having a persistence mechanism complicates a 
lot of things. In professional environments, you often find that 
different staff (even different companies) do the administration of 
production environments. Beeing able to tweak more than small parts of 
the configuration in production makes it necessary to have a "process" 
to feed back this configuration information to developers, to keep track 
(a la versioning system) of what has changed, to take care of clustered 
environments where config changes have to be distributed to nodes etc.

Mika


Liu, Jervis schrieb:
> Hi Mika, In Celtix 1.0, we had a configuration persistence story on the list, which is
to save any configuration changes to configuration file during the shutdown. We just did not
have time to tackle this story. Another reason this story was postponed is because we would
like to see a concrete user requirement before we spend time on development. So followed your
question, would you be able to identify a use case that requires configuration persistence?
>
> Thanks,
> Jervis
>
>   
>> -----Original Message-----
>> From: Mika Göckel [mailto:mika.goeckel@gmx.de]
>> Sent: Tuesday, September 05, 2006 4:23 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Configuration Requirements CXF
>>
>>
>> Hi,
>>
>> I'm trying to follow your discussion and find it very interesting.
>> One question about external configuration-changes (through 
>> JMX or other 
>> sources). How would you ensure the changes survive a restart of the 
>> application, or better survive a redeployment?
>>
>> I like the idea of being able to tweak my soapstack at runtime, but I 
>> feel it can get really hairy and at the end leads to a sort of 
>> app-server sort of application. Is this our goal?
>> Hot-Deployment, dynamic configuration, dependency-resolution between 
>> separate deployment-modules, etc.
>>
>> Mika
>>
>> Jiang Ning schrieb:
>>     
>>> Hi Andrea,
>>>
>>> Yep, the Current CXF management interface is not coupled 
>>>       
>> with JMX. We 
>>     
>>> are using annotations to wrap the Management Information ( 
>>>       
>> attributs 
>>     
>>> and operations) and export instrumentation object through 
>>>       
>> the JMX.  I 
>>     
>>> think if we want to export the configuration information to the JMX 
>>> layer, we can store the configuration instance (may be the Spring 
>>> beans instance) in the instrumentation. That will be much 
>>>       
>> easy for us 
>>     
>>> to maintain the configuration states when we modify the 
>>>       
>> configuration 
>>     
>>> from out side. Because we get the configuration from same 
>>>       
>> place, the 
>>     
>>> notification of configuration changed will not be necessary.
>>>
>>> Just some  rough  thoughts ,   comments  and suggestions  
>>>       
>> are welcome :)
>>     
>>> Cheers,
>>>
>>> Willem.
>>>
>>> Andrea Smyth wrote:
>>>
>>>       
>>>> Hi Willem,
>>>>
>>>> I have updated this requirement to reflect the fact that the CXF 
>>>> management interface is actually a layer above JMX, and hence 
>>>> modifying configuration values at runtime via JMX is not 
>>>>         
>> the same as 
>>     
>>>> doing so via the CXF management interfaces. Not sure if everyone 
>>>> would consider being able to do the latter as a 
>>>>         
>> requirement - but I 
>>     
>>>> was under the impression that CXF management is only optionally 
>>>> backed up by JMS and that we don't want to depend 
>>>>         
>> exclusively on it.
>>     
>>>> Maybe you want to add things like 'being able to register 
>>>>         
>> listeners 
>>     
>>>> so as to be notified of a configuration change' to the 
>>>>         
>> requirements?
>>     
>>>> Andrea.
>>>>
>>>> Jiang Ning wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>> Just some comments on "JMX Users should be able to tweak the 
>>>>> configuration at runtime."
>>>>>
>>>>> 1. Which configuration instance the JMX should hold for  
>>>>>           
>> maintenance 
>>     
>>>>> of consistency
>>>>>
>>>>> If the JMX get the core component's configuration 
>>>>>           
>> object's instance 
>>     
>>>>> , the JMX's configuration will take effect on the components self 
>>>>> effectively. It is simple, but the configuration instance will be 
>>>>> separated in everywhere of core.
>>>>>
>>>>> If the JMX just get the configuration instance from the CXF 
>>>>> configuration API, there should be an event for core components 
>>>>> which use the configuration can be notified when the 
>>>>>           
>> configuration 
>>     
>>>>> are changed. This will make the configuration API more complex.
>>>>>
>>>>> 2. There is an issue about using Jconsole to modify the 
>>>>>           
>> configuration.
>>     
>>>>> As you know Jconsole  just  display the primary object in 
>>>>>           
>> its GUI,  
>>     
>>>>> I  think  if we  want to  provide  a  more powerful  management  
>>>>> console,  we should  do it  by our self.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Willem.
>>>>>
>>>>> Dan Diephouse wrote:
>>>>>
>>>>>           
>>>>>> I updated the page with these things and several of my own.
>>>>>>
>>>>>> I think the Spring approach that I roughly outlined can meet the

>>>>>> criteria, although a few tweaks are probably in order for 
>>>>>> discovery. I think we need to starting talking about two 
>>>>>>             
>> cases for 
>>     
>>>>>> discovery. The first is where the user is just using CXF and not

>>>>>> trying to integrate with any container. For this we could have a

>>>>>> spring based bus which loads all the 
>>>>>>             
>> "META-INF/cxf/cxf-*.xml" files 
>>     
>>>>>> off from the classpath. So it would find all of them at 
>>>>>>             
>> startup by 
>>     
>>>>>> virtue of searching the classpath. The second case would 
>>>>>>             
>> be people 
>>     
>>>>>> trying to do Spring integration. This above scenario 
>>>>>>             
>> allow reuse by 
>>     
>>>>>> normal spring users via an <import 
>>>>>> resource="META-INF/cxf/cxf-*.xml"/> tag.
>>>>>>
>>>>>> The other tricky thing is registration. For instance, 
>>>>>>             
>> registering a 
>>     
>>>>>> destination with a destinationfactory. If you want out 
>>>>>>             
>> of the box 
>>     
>>>>>> registration from each jar on the classpath, I think there are a

>>>>>> couple options:
>>>>>> 1. have a @PostConstruct which does the registering. 
>>>>>>             
>> This does seem 
>>     
>>>>>> kind of icky though as I may not always want to register things
>>>>>> 2. Create a component which does the registering. The spring 
>>>>>> MethodInvoker class could do this: Kind of annoying to write the

>>>>>> extra configuration, but it only needs to be done once..
>>>>>> 3. Have an initialize-method="register" on the <bean> which
does 
>>>>>> the registering
>>>>>> 4. Autowiring? (not sure if Spring's autowiring can do that)
>>>>>>
>>>>>> Supporting of getting configuration from multiple sources can be

>>>>>> done pretty easily I think with:
>>>>>> a) having a bean in a user config which overrides the 
>>>>>>             
>> default bean
>>     
>>>>>> b) Grabbing configuration from the service model/context 
>>>>>>             
>> hierarchy
>>     
>>>>>> c) Using spring's support for command line properties overriding

>>>>>> spring bean values [1]
>>>>>>
>>>>>> - Dan
>>>>>>
>>>>>> 1. 
>>>>>>
>>>>>>             
>> http://static.springframework.org/spring/docs/2.0.x/reference/
>> beans.html#beans-factory-extension-factory-postprocessors 
>>     
>>>>>> Liu, Jervis wrote:
>>>>>>
>>>>>>             
>>>>>>> Hi,
>>>>>>>
>>>>>>> Two comments:
>>>>>>>
>>>>>>> 1. Should not we have a support for dynamic 
>>>>>>>               
>> configuration? i.e., 
>>     
>>>>>>> users can change default configurations in the runtime either

>>>>>>> programatically or through management interface (for 
>>>>>>>               
>> example, JMX 
>>     
>>>>>>> Console).
>>>>>>>
>>>>>>> 2. Configuration override: shall we have a override 
>>>>>>>               
>> mechanism so 
>>     
>>>>>>> that configurations can be taken from multiple sources 
>>>>>>>               
>> and can be 
>>     
>>>>>>> overridden in order. For example, a configuration can 
>>>>>>>               
>> be applied 
>>     
>>>>>>> in the following order: default config <- user supplied config

>>>>>>> file <- wsdl <- command line
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jervis
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>               
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>>>>>>>> Sent: Saturday, September 02, 2006 4:11 AM
>>>>>>>> To: cxf-dev@incubator.apache.org
>>>>>>>> Subject: Re: Configuration Requirements CXF
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrea Smyth wrote:
>>>>>>>>  
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Before discussing further implementation details 
>>>>>>>>>                   
>> let's collect 
>>     
>>>>>>>>> the requirements for configuration in CXF.
>>>>>>>>> I have created a page on confluence for that purpose:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     
>>>>>>>>>                   
>>>>>>>>
>>>>>>>> http://cwiki.apache.org/confluence/display/CXF/Configuration+R
>>>>>>>> equirements
>>>>>>>>  
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> starting out with some requirements based on experience
with 
>>>>>>>>> Celtix users.
>>>>>>>>>
>>>>>>>>> Please update it with any further requirements that 
>>>>>>>>>                   
>> you may have.
>>     
>>>>>>>>> Andrea.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     
>>>>>>>>>                   
>>>>>>>>
>>>>>>>> Sounds like a good plan. I'll go through this weekend and
add 
>>>>>>>> some stuff.
>>>>>>>>
>>>>>>>> - Dan
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Dan Diephouse
>>>>>>>> Envoi Solutions
>>>>>>>> http://envoisolutions.com
>>>>>>>> http://netzooid.com/blog
>>>>>>>>
>>>>>>>>
>>>>>>>>   
>>>>>>>>                 
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>>           
>>>>         
>> -- 
>> cyber:con gmbh
>> Mika Göckel
>>
>> Rathausallee 10
>> 53757 Sankt Augustin
>>
>> tel (+49)2241 / 9350 0
>> fax (+49)2241 / 9350 99
>> mob (+49) 172 / 279 2771
>> skype mika.goeckel
>> email mika@cybercon.de
>>
>>
>>     
>
>   


-- 
cyber:con gmbh
Mika Göckel

Rathausallee 10
53757 Sankt Augustin

tel (+49)2241 / 9350 0
fax (+49)2241 / 9350 99
mob (+49) 172 / 279 2771
skype mika.goeckel
email mika@cybercon.de


Mime
View raw message