logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <mwom...@bevocal.com>
Subject RE: Configuration Servlet Features
Date Fri, 20 Dec 2002 18:45:52 GMT
I forgot one other item...

2.5) A command to "reset/reload" the configuration.

On a related note, from some of my own work, I have found it useful to have
the code that does the configuration factored out into a common class that
both the init and configuration servlet use to "load" or "reset" the
configuration to a known starting state.  I think we should consider doing
something similar for the proposed servlet classes.  I would suggest a
o.a.log4j.servlet.CommonUtil class that has methods to set the
configuration, etc.  One of the methods could take a ServletContext, and
would use it to get the content init params, etc.


> -----Original Message-----
> From: Mark Womack 
> Sent: Thursday, December 19, 2002 1:41 PM
> To: 'Log4J Developers List'
> Subject: Configuration Servlet Features
> > I think that his servlet is a really good base for 
> displaying current
> > configuration information for a web application.  I have a 
> > couple of ideas
> > for feature additions that I will go into later.  If anyone 
> > has any other
> > ideas or code submissions in this vein, please post.
> OK, here are a couple of ideas that I have:
> 1) The logger information can be displayed in a hierarchical 
> nature, by
> package name.  So, if you have a lot of loggers, you can 
> expand to the ones
> that you care about, hiding the rest.  Maybe the servlet could switch
> between the current view and the hierarchical view.  I wrote 
> some code that
> gets the current loggers and then allows you to iterate 
> through the package
> names, getting information at each level.  I will post it 
> later.  All that
> is needed is another object to keep track of display state (what is
> expanded) and this could be stored by the servlet in the web 
> session.  My
> code does not have any side effects (ie it does not create 
> new loggers).
> Then the page generation code could reference this object to 
> display the
> logger info.
> So, instead of
> com.mycompany.servlet.HttpUtils
> com.mycompany.servlet.Servlet
> com.mycompany.servlet.StringUtils
> com.mycompany.util.JMSUtils
> com.mycompany.util.Log4jUtils
> com.mycompany.util.StringUtils
> You would see
> com
> with a link to expand it (either on the package name or a 
> little expander
> icon).  Eventually you could display something like this:
> com
>  mycompany
>   servlet
>    HttpUtils
>    Servlet
>    ServletUtils
>   util
> 2) Allow the level to be set for any logger, not just the 
> ones that have
> been created.  This is simple to do in log4j.  Just do a 
> getLogger() for the
> package name you want.  If the logger does not exist log4j 
> will create it.
> So, modify the servlet to have a text edit box where the user 
> can type in
> the name and set the desired level via a popup.
> 3) Built-in help.  Have a "verbose" mode on the servlet where 
> description
> text on how to use the various bits of interface are 
> displayed.  This mode
> can be turned on/off.
> 4) Useful links.  Maybe have some links to the log4j jakarta 
> home page or
> something on the page generated by the servlet.
> -Mark
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message