Mika Göckel wrote:
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.
IMO - yes and no. No to making the core an appserver of sorts - I very
much would like this to keep this out of the core code as it leads to a
much more complex framework. If you have any doubts look at what axis2
has done with their core. They're making it into an appserver. They have
deployment archives, classloader mucking, etc. It leads to an
unnecessarily complex application and a lot of problems.
Yes, because I know some people need the features. I think its possible
to do this in a layered approach though. For instance, if we have a
spring runtime its easy enough to search the context for different beans
and tweak those values. But I think the other configuration scenarios
are important too. In the very near future (i.e. as soon as we get this
Configuration layer figured out) I would like to start working on
embedding cxf and storing the configuration in a database for an
application of mine.
Regarding hot deployment - I guess I'm very skeptical that people are
going to need hot deployment built into cxf. Most of the time people who
want to do hot deploys are already using another container like an
appserver or maybe JBI. To me this is where hot deployment code should
be contained.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
