logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <paul.sm...@lawlex.com.au>
Subject RE: reload behavior modification / feature request
Date Thu, 22 Jan 2004 22:10:22 GMT
Tom, a big +1 on everything you've said.

IIRC, there are a couple of people who are very interested in this space
and are interested in developing these concepts for log4j.  Am I
correct?  It would be good if a working party could be established to
push this further.  

Perhaps if a group could be established they could be nominated into the
log4j-sandbox to develop this concept initially with a view to it being
integrated into Log4j fully?  I really see this area as a very important
aspect to the management of a log4j environment, and I would like to
encourage this discussion and development as much as I can.


Paul Smith
On Fri, 2004-01-23 at 08:57, Tom Drake wrote:
> I've been lurking and have a few thoughts on this thread. I'm currently
> involved in some projects that are similar to what's being discussed. So,
> I'd like to chime in with my thoughts on the subject.
> Persistence should be an option. I can easily envision loading and saving
> the log4j configuration data (xml or properties) to/from an external
> database. Providing a pluggable interface for this would make it someone
> elses problem to provide a persistence mechanism suitable for their own
> needs.
> But, let's go one step further. Let's say that we're administrating a
> cluster of servers. In some cases, I'd like to make one-off changes to one
> server only, and not persist them. In other cases, I'd like to make changes
> that are persisted (to a database) and made effective across the entire
> cluster.
> Of course, the persistence mechanism should be abstract, allowing
> persistence to be done via a filesystem, JNDI, database, etc... And cluster
> notification should be abstract as well, allowing one to plug-in a
> JavaGroups, JMS, or smoke signal based implementation. Such a notification
> mechanism would probably include special 'watcher' implementations to notify
> the other nodes of a change.
> So, what could be persisted? XML is more comprehensive than the properties
> format. So, we'd need to write some code to marshall the configuration graph
> to Digester compatible xml. Any 'comments' from the original xml would be
> lost. Even simpler would be to serialize the configuration object tree. But
> this would not be human readable. That may be okay, however, since it could
> be 'visualized' via the JMX console.
> Regards, 
> Tom Drake
> -----Original Message-----
> From: Rob Butler [mailto:robert.butler5@verizon.net] 
> Sent: Thursday, January 22, 2004 1:20 PM
> To: Log4J Developers List
> Subject: Re: reload behavior modification / feature request
> Hi,
> >
> > As to the jmx implementation, I'm not sure if overwriting the initial
> > log4j configuration file is the adequate approach. Or in other words, I
> > would prefer to not make jmx-manipulations persistent. In our opinion, a
> > restarted application e.g. should use the originally defined log4j
> > configuration file instead of a possibly temp. log4j jmx-defined setup
> > used, e.g., before a crash of the application. What do you think?
> >
> Depends on your intended purposes.  JMX is a "management" api (and with JMX
> remoting now a standardized protocol too).  To me that means when you make a
> change, the change is persistent until changed again.  If you use JMX to add
> and run a new EAR on a running J2EE server I would expect that EAR to start
> the next time I shutdown and restarted the entire app server.  If I only
> wanted a change in logging to be temporary I would expect to make the
> change - do what I needed to do with the new logging data - and then change
> it back again.  If the application were not restarted the logging
> modification would stay in place until I changed it again, why shouldn't it
> do the same thing even if I restart the app.  In my opinion the problem with
> most JMX enabled apps is the modifications are not permanent across
> restarts.
> Also, developers are not necessarily always aware of an application being
> restarted.  Where I work we pretty much have a complete hands off policy for
> our production J2EE applications - we aren't allowed to login, etc.
> However, we would be allowed to do something like increase the logging level
> via JMX, or a web console.  I may do this because I need to gather
> additional data over a long period to track down some minor bug.  Should
> production support need to down the box to work on hardware or some other
> un-related issue on the box I would be pretty upset to find out that my much
> needed log data was not collected because the logging change I made via JMX
> was "reset" when the box was re-started.   I don't know of many places that
> ask a developer if it's ok to bring down a production box to fix hardware,
> or software un-related to their app.  They have policies / procedures, etc.
> to do all that kind of stuff, but generally the development team is not
> consulted.
> Later
> Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message