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:[EMAIL PROTECTED]
Sent: Tuesday, September 05, 2006 4:23 PM
To: [email protected]
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:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 4:11 AM
To: [email protected]
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 [EMAIL PROTECTED]
--
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 [EMAIL PROTECTED]
