Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of qingtian.wang@gmail.com
 designates 64.233.170.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Nh9J6yh7LV3RMy2OJLZdlxCPV/J+hqjCYGVUaRg55V7ZQQ3vboUb/WeGQ9X2yefmMi8QM811n4+Mhtn86fiHqZUJNAwY3ZLQDN4crfRvCcxbd6ukYvTnjXse4JOFs7yrfgoFd9NIkOsSKSGeUpVSEI/37fGUBkogURCo6kXCFDk=
Message-ID: <42543C2C.8030701@gmail.com>
Date: Wed, 06 Apr 2005 14:44:44 -0500
From: WANG Qingtian <qingtian.wang@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: Configuration - Reload Strategy in j2ee containers
References: <4251B5FE.6080606@gmail.com>
	 <3177d25505040607194ec611f5@mail.gmail.com> <4254310F.101@gmail.com>
 <3177d255050406123345491752@mail.gmail.com>
In-Reply-To: <3177d255050406123345491752@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Soaring Eagle wrote:
>>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.

Did you try really shutdown the container from the command line in the 
real case scenario other than the unit test, and see if the custom 
thread being killed? If so, great. But I am not sure that behavior 
guaranteed for various containers, though. It's interesting. Please let 
me how you find out.


> 
> 
>>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.

I also asked the performance question. What he said was that you can set 
the reload interval programmatically via the Configuration API itself, 
which will cause the reload to happen only when the interval set is due. 
That effectively does the same thing as with the monitoring thread. I 
didn't look into the code and see if the config data are cached in 
between the same interval. But I'd imagine it'd do the caching....


> 
> On Apr 6, 2005 2:57 PM, WANG Qingtian <qingtian.wang@gmail.com> 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 <qingtian.wang@gmail.com> 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: commons-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org