Chiranga, On 2/27/2016 9:38 AM, Chiranga Alwis wrote: > Well, what I am trying to achieve is as follows: > > I am trying to load certain custom configurations from a file which > is similar to web.xml in Tomcat, for each Context. We can define it > globally and also override the configurations at context level. For > this I have already created a custom Listener and have added it to > lib folder. > > I have already constructed it in a manner in which for each > configuration the configurations are loaded at webapp deployment. > > But now I intend to perform this task not only at the initial > deployment, but also if someone makes a change to the webapp. I > believe Tomcat also dynamically reloads a context if modified, for > example a modification to the web.xml or a Java class. We don't have > to switch off the Tomcat server and restart it to load the new > changes. > > In my understanding, in such a situation the Context instance that > was initially created at server startup is destroyed and a new > Context instance is created. I got this idea as I did not come across > a new event type under Tomcat component lifecycle which defines an > event of updating a Tomcat component such as a Context. The ones that > exist are for starting and destroying of Tomcat components. > > Is my understanding correct? Or is it different? Plus what is/are the > most appropriate LifeCycle events which I am to use in such a > situation? > > On Sat, Feb 27, 2016 at 6:17 PM, Mark Thomas <ma...@apache.org> > wrote: > >> On 26 February 2016 19:09:59 GMT+00:00, Chiranga Alwis < >> chirangaal...@gmail.com> wrote: >>> Well, sorry if the question is not clear. >>> >>> What I want to know is for what type of event we need to listen >>> in order to carry out a task when a Context is modified. It would >>> be great if there is a clear explanation on how this is to be >>> checked. >> >> Again, define modified. >> >> Again, why do you want to run a task? What are you actually trying >> to achieve? >> >> Mark >> >>> >>> On Fri, Feb 26, 2016 at 5:21 PM, Mark Thomas <ma...@apache.org> >>> wrote: >>> >>>> On 26/02/2016 11:44, Chiranga Alwis wrote: >>>>> Hi, >>>>> >>>>> I have currently created a LifecycleListener which listens >>>>> to >>> Tomcat's >>>>> context deployment event and loads data in a custom >>>>> configuration >>> file at >>>>> that point. >>>>> >>>>> I have been trying to find out whether LifecycleListeners >>>>> support >>> context >>>>> update and modification events but yet in my understanding I >>>>> could >>> not >>>>> discover an appropriate resource to use. >>>> >>>> Define update. >>>> >>>> Define modification. >>>> >>>> Better still, explain what it is you actually want to achieve >>>> rather than ask for help implementing your, potentially flawed, >>>> solution. >>>> >>>> Mark
My thoughts on this from an operations / sanity viewpoint. I am always leery of changing web application configurations on the fly. It's easy to get source code repositories not agreeing with production code, not agreeing with Maven repositories (if you use Maven), etc., etc. Then when you go to debug a production problem, figuring out what you're working with becomes challenging. I much prefer using parallel deployment, and changing the web application every time a configuration changes. Tomcat handles this gracefully. We've found that Jenkins / Nexus / Maven / parallel deployment makes it easy to manage test, UAT, and production releases. The Jenkins job sends all interested parties email, which contains the version of the product, who did the release, and where the release can be found. There's also a record in the Jenkins logs, so we can look at a product release history fairly easily. That being said, if you absolutely want to change configurations on the fly, I'd look at something like the following (please note that I am a systems architect and NOT a Java developer): 1. Store your configuration in a Singleton Maybe use a ConcurrentHashMap 2. Populate the Singelton via a ServletContextListener on start up 3. Create a protected administrative interface Look at using the Remote Address Filter to provide protection 4. Reload the configuration using the protected administrative interface I think this is ugly, and you should strongly consider releasing point updates when the configuration changes. . . . just my two cents /mde/
signature.asc
Description: OpenPGP digital signature
