cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiang Ning <ning.ji...@iona.com>
Subject Re: Configuration Requirements CXF
Date Tue, 05 Sep 2006 06:28:50 GMT
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
>>>>>
>>>>>
>>>>>   
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Mime
View raw message