I just mean that none of the other pages in the application link to
it, so chances are pretty good that nobody who doesn't know about will
find out about it.  All it does internally is call the Log4J
DOMConfigurator.configure() method and write a simple success message
to the user.  You can implement this as a standalone servlet or as a
Struts Action.

-- Jeff


On 10/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> By saying "not linked to" , do you mean its an action loading a JSP , and
> is NOT called from any of the pages / buttons etc ? Hiding it from the
> application user world ?  What does this JSP do internally ?
>
> Thanks
> abhay
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> You can easily play a joke on a person who likes to argue: agree with him.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Abhay B Chaware
> Tech Lead
> KPIT Cummins Infosystems Ltd.
> Daytime Ph. 763-574-5355
> Evening Ph. 763-786-1224
>
>
>
>
>                       Jeff Beal
>                       <[EMAIL PROTECTED]        To:       Struts Users 
> Mailing List <user@struts.apache.org>, [EMAIL PROTECTED]
>                       >                        cc:
>                                                Subject:  Re: changing log4J 
> configuration during run time
>                       10/12/2005 11:50
>                       AM
>                       Please respond to
>                       Struts Users
>                       Mailing List
>
>
>
>
>
>
> We have a "super-secret" (that is, not linked to) URL in our
> application that we can use to trigger a Log4J reload.  We don't have
> to restart the server, but we also don't have to worry about the
> possibility of configureAndWatch() taking *any* cycles from our
> production box.  (Since I put in this mechanism about a year ago, we
> have used our "super-secret" URL roughly twice.  It just seems silly
> to constantly watch a file that only changes twice a year, even if the
> watching doesn't take up significant resources.)
>
> -- Jeff
>
> On 10/12/05, Deep Chand <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > In log4J, if I change the configuration i.e. increase/decrease the
> > level of a particular logger or add more appenders/categories in the
> > config file, then do I have to restart the web server for that setting
> > to take effect.
> >
> > What I understand from the documentation is that if I use
> > DOMConfigurator.configureAndWatch(<configFileName>, <timeInMilliSec>)
> > then I don't have to restart the server. Is this the only way to
> > change the logging configuration during run time or there are some
> > other ways also? If you use this method, then a thread is launched
> > which continously monitors the config file changes. Is this technique
> > has some serious performance overhead and therefore not preffered in
> > production enviornment?
> >
> > What do people generally prefer - use this method OR simply use
> > DOMConfigurator.configure(fileName) and restart the server after
> > changing the config file?
> >
> > Thanks
> > Deep
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
>
> _____________
> This e-mail transmission and any attachments to it are intended solely for
> the use of the individual or entity to whom it is addressed and may contain
> confidential and privileged information.  If you are not the intended
> recipient, your use, forwarding, printing, storing, disseminating,
> distribution, or copying of this communication is prohibited.  If you
> received this communication in error, please notify the sender immediately
> by replying to this message and delete it from your computer.
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to