> I guess this would be one way to do it, but I must say the WebLogic approach where the container writes back the XML has always irritated me. (Especially pre 8.1 where it would regularly corrupt the file.)
I agree there have been some issues with early weblogic writes of config.xml, but I consider that an implementation problem not a design one. (I am still not pleased that they don't offer a dtd or schema of the config either :( ).
> Also, what if it's impossible to write back to the definition? WebLogic is a top-level Java app, Spring is not. What if the definition is in an XML file accessed via the network?
well there are some scenarios where its a read only config (read via http or a read only mount point/network share) but in this case you should know this to be the case when you first read it, and don't offer that option (of modify & persist).
I think its much better to change the settings and then persist them for a variety of reasons:
1. you don't have to poll the filesystem or poke the running app to reread the config.
2. if you don't allow file config changes its cleaner and less chance for conflicts... like if the file changed and it conflicts with a value that has changed via the domain logic which takes precidence? and why? and how will people know? this could produce some unexpected results.
3. provies the developer greater control of (property level) things that they will or won't allow to be changed once the application has been started. Based on the way applications are written, it could be very harmful to change a certain property, based on its usage. And exposing this thru the domain logic api, or via JMX, gives control back to what can actually be changed and when.
thoughts and comments welcome....
-Jason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I think admins can and should access (what a developer choses to expose) via JMX. This can be a very good thing in any environment that has roles for deployer, admin and developer.
As far as updates across a cluster, you could have the MBean set to ensure that all MBeans of its exact kind that were connected to the same MBean server are equal or not. It could just do a lookup to the other beans across the cluster and propagage the update. (or not, depending on your wishes) I am sure there are other ways to do it, and some vendors may implement some features to do this (not sure). But this is one way that would work.
I see JMX as a huge step for Spring, because with it you will then be able to hookup to enterprise class processes of configuration and management. (across many applications).
thoughts?
-jp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-04
I would find such a feature useful during development as it can avoid requiring us to restart web containers Tomcat as we build new web pages and consequently modifiy {servlet-name}-servlet.xml and applicationContext.xml.
In my current environment, Tomcat runs from an exploded web app directory and when I modify my Spring MVC handler class for example, I simply rebuild the web app and Tomcat picks up the changes. However since application contexts aren't dynamically refreshed, any changes to these files require me to restart Tomcat. Tomcat startup times may not be high for small apps, but as the app gets larger, restarting tomcat frequently adds considerable time to the development cycle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
furthering the discussion from http://opensource.atlassian.com/projects/spring/browse/SPR-94 (sorry if it was posted to the wrong place)
> I guess this would be one way to do it, but I must say the WebLogic approach where the container writes back the XML has always irritated me. (Especially pre 8.1 where it would regularly corrupt the file.)
I agree there have been some issues with early weblogic writes of config.xml, but I consider that an implementation problem not a design one. (I am still not pleased that they don't offer a dtd or schema of the config either :( ).
> Also, what if it's impossible to write back to the definition? WebLogic is a top-level Java app, Spring is not. What if the definition is in an XML file accessed via the network?
well there are some scenarios where its a read only config (read via http or a read only mount point/network share) but in this case you should know this to be the case when you first read it, and don't offer that option (of modify & persist).
I think its much better to change the settings and then persist them for a variety of reasons:
1. you don't have to poll the filesystem or poke the running app to reread the config.
2. if you don't allow file config changes its cleaner and less chance for conflicts... like if the file changed and it conflicts with a value that has changed via the domain logic which takes precidence? and why? and how will people know? this could produce some unexpected results.
3. provies the developer greater control of (property level) things that they will or won't allow to be changed once the application has been started. Based on the way applications are written, it could be very harmful to change a certain property, based on its usage. And exposing this thru the domain logic api, or via JMX, gives control back to what can actually be changed and when.
thoughts and comments welcome....
-Jason
Jason
Some good arguments here. What about allowing administrators to change settings? Do you envisage that happening via JMX?
What about a clustered environment? Suppose several servers run from the same XML, and a JMX change occurs on one server but should affect them all?
R
Yes I think admins can and should access (what a developer choses to expose) via JMX. This can be a very good thing in any environment that has roles for deployer, admin and developer.
As far as updates across a cluster, you could have the MBean set to ensure that all MBeans of its exact kind that were connected to the same MBean server are equal or not. It could just do a lookup to the other beans across the cluster and propagage the update. (or not, depending on your wishes) I am sure there are other ways to do it, and some vendors may implement some features to do this (not sure). But this is one way that would work.
I see JMX as a huge step for Spring, because with it you will then be able to hookup to enterprise class processes of configuration and management. (across many applications).
thoughts?
-jp
I would find such a feature useful during development as it can avoid requiring us to restart web containers Tomcat as we build new web pages and consequently modifiy {servlet-name}-servlet.xml and applicationContext.xml.
In my current environment, Tomcat runs from an exploded web app directory and when I modify my Spring MVC handler class for example, I simply rebuild the web app and Tomcat picks up the changes. However since application contexts aren't dynamically refreshed, any changes to these files require me to restart Tomcat. Tomcat startup times may not be high for small apps, but as the app gets larger, restarting tomcat frequently adds considerable time to the development cycle.
you dont have to restart, use this http://localhost:8080/manager/html
and just reload... its quicker than restart..
although, i think this topic needs more support..
-jp