> Since the container doesn't have the control over the life cycle of the > thread that takes care of the reload, say next time the container > starts, you don't want the reloading to take effect not all, you'd have > to figure out a way to kill that thread....?
In my unit tests, when I request the container to shutdown, my custom thread also shuts down. > Plus per the email Emmanuel sent, commons-configuration seems already to > have a built-in mechanism to do the periodical reload without spawning > any thread.... If I understood that email correctly, the reload strategy basically loads the configuration file each time any configuration is asked for. That is great - however, for various reasons (mainly small performance gains), I prefer to load configuration through a singleton class - effectively caching all configuration. when applications require config data, they get it from the in memory singleton cache. A background thread of this singleton class checks for changes at regular intervals and refreshes the in-memory configuration. On Apr 6, 2005 2:57 PM, WANG Qingtian <[EMAIL PROTECTED]> wrote: > Soaring Eagle wrote: > > Hello all, > > > > In an app we are doing, we use commons config to load properties and > > use a threaded class to do the reload every few seconds. this is then > > packaged as a part of a j2ee application. When application code is > > referenced for the first time, a thread is started and this thread > > checks for modifications at intervals. Though the J2EE spec does not > > allow a developer to start threads, this seems to work well for me. > > Since the container doesn't have the control over the life cycle of the > thread that takes care of the reload, say next time the container > starts, you don't want the reloading to take effect not all, you'd have > to figure out a way to kill that thread....? > > Plus per the email Emmanuel sent, commons-configuration seems already to > have a built-in mechanism to do the periodical reload without spawning > any thread.... > > > > > > The other option would be create a java application class as the > > configuration wrapper (containing a main method) and to start that > > class as a "startup" class in the J2EE container. > > That'll work until the time comes when you want switch to a container > that doesn't offer a startup/shutdown class. Once in a blue moon you'd > want to switch containers, but still.... > > > > > > Please share your views on this type of design. > > > > Thanks > > Eagle. > > > > On Apr 4, 2005 5:47 PM, WANG Qingtian <[EMAIL PROTECTED]> wrote: > > > >>Hi, > >> > >>Is the reload strategy implemented by creating a thread that > >>periodically checks the time stamp of the configuration file? If so, how > >>do I make sure that thread is started/stopped properly when I use it in > >>a j2ee container? Like, will the thread be killed when I shut down the > >>web/ejb container? What is the "best practice" of using "configuration" > >>in a j2ee container? > >> > >>Thanks a lot for your help!!! > >>Qingtian > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
