Sorry, I guess a vote IS a bit too formal on a proposal. :-) But I am glad to see that folks think it is worthy of investigation and inclusion.
-Mark > -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 6:19 AM > To: Log4J Developers List > Subject: RE: [VOTE] Proposal: Log4Init servlet class > > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
