There is no need to vote on *potential* contributions. When the contribution becomes ready the championing committer can optionally poll for opinions before committing. We only need to vote if someone objects. I have not seen any formal objections to Mark's proposal, so we do not need to vote. Correct me if I am wrong... :-)
At 08:43 07.10.2002 -0400, you wrote: >Hi, >In Remy's favorite format: > ><ballot> ><question>Add Log4jInitServlet to contribs?</question> ><vote> >[+1] Yes >[ ] No ></vote> ></ballot> > >I also support the idea for a standard log4j context listener. >Thanks Jake. ;) > >Yoav Shapira >Millennium ChemInformatics > > > >-----Original Message----- > >From: Jacob Kjome [mailto:[EMAIL PROTECTED]] > >Sent: Monday, October 07, 2002 8:27 AM > >To: Log4J Developers List > >Subject: Re: [VOTE] Proposal: Log4Init servlet class > > > > > >Hi Mark, > > > >The Log4jInit servlet that I posted to you and is being use in the >example > >you posted to the list under the subject "RE: FW: log4j.jar locked by > >Tomcat even after remove/undeploy ...." could be used for this. It >is > >currently part of the Barracuda project at >http://barracuda.enhydra.org/ , > >the but could certainly be donated to Log4j for official inclusion. >The > >license *can* be changed to fit Log4j's needs. It is very flexible and > >pretty fault-tolerant. It does not yet use Repository Selectors. That > >would have to be added. A Watchdog should be added and the option for > >configureAndWatch() removed for the 1.3 release since Watchdogs will > >supercede configureAndWatch(). > > > >Let me know what you think of my proposed contribution. Certainly work > >needs to be done to it for an official release, but as a 1.2.x based >init > >servlet, it is pretty full featured already. > > > >BTW, there should probably also be a ServletContextListener added to >this > >proposal along with the init servlet. The reason for this is that log > >files stay locked unless LogManager.shutdown() is called. WIth a >servlet > >context listener, you can count on it being run once at startup and >once at > >shutdown rather than whenever the container feels like >loading/unloading in > >the servlet's case. The class Log4jApplicationWatch class that I sent > >along with the Log4jInit servlet should provide this functionality. > > > >Anyway, let me know if my contributions would be acceptable....at least >as > >a basis of where to start. > > > >Jake > > > >At 09:52 PM 10/6/2002 -0700, you wrote: > >>In the quest of finding more things to do that one has time for, I >propose > >>that we explore the inclusion of a Log4jInit servlet class in the >official > >>log4j library. This would be a servlet class that can be used to > >initialize > >>log4j in a web application. Everyone seems to have their own version >of > >one > >>that all do the same basic stuff. > >> > >>I am making this proposal because if this class is used so often, then >I > >>think a basic version should be available in the official log4j >library > >for > >>general use or for specific extension by developers. It will make >log4j > >>"easier" to use because it will have a useful off-the-shelf class > >>specifically designed for web applications. > >> > >>However, I would like this component to be "owned" by someone else >that > >will > >>put the energy into it. If this person is not a committer, then I > >volunteer > >>to "champion" and review the code, and make sure it gets committed >into > >cvs > >>after review. But my v1.3 plate is full with plugins, receivers, > >watchdogs, > >>and filters. > >> > >>A number of folks have stated an interest in contributing to log4j. > >Here's > >>your chance to create something that almost every log4j web >application > >>based developer will use. If no one steps up, then it will just wait > >until > >>one of us has the time. > >> > >>I think there are a number of options for this class that can be >explored, > >>such as possibly using a distinct logger repository per web > >>application/servlet/etc. There may be other related components that >could > >>be considered. > >> > >>But first, what do the other committers think? > >> > >>+1 > >> > >>-Mark > >> > >> > >>-- > >>To unsubscribe, > e-mail: <mailto:log4j-dev->[EMAIL PROTECTED]> > >>For additional commands, e-mail: > <mailto:log4j-dev->[EMAIL PROTECTED]> >This e-mail, including any attachments, is a confidential business >communication, and may contain information that is confidential, >proprietary and/or privileged. This e-mail is intended only for the >individual(s) to whom it is addressed, and may not be saved, copied, >printed, disclosed or used by anyone else. If you are not the(an) >intended recipient, please immediately delete this e-mail from your >computer system and notify the sender. Thank you. > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
