Dan Diephouse schrieb:
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
+1 exactly what I think.
--
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]
