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 08:23:06 GMT
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


Mime
View raw message