On 4/3/02 12:16 PM, "Fernandez Martinez, Alejandro" <[EMAIL PROTECTED]> wrote:
> In order to implement a LogUser interface and have a setLogger(Log) method > called, don't you need a full lifecycle for the components? Not at all (well, maybe...). The point of view here is that implementing LogUser means you want a configured log to use, and the lifecycle is up to the component and framework it works in... > > That is, to be sure setLogger(Log) will be called at a certain point in all > LogUsers, LogUsers must register somewhere. No - it's left up to the use - we just want a standard way of doing it. > Then, the logging package will > call setLogger(Log) for all components after it has read the configuration. > That, in turn, means the components should tell the logging package to > configure itself, or read the configuration from a given location, or > whatever. This resembles even more a full-fledged framework, and does not > seem proper for a simple logging package. No - we are coming at it from the POV that we want to write little tools that work with any app/framework/etc that knows about LogUser. The component that implements the interface can make no demands - it is just saying "I can log using Log, so give me one if you have it..." > > Un saludo, > > Alex. > >> -----Mensaje original----- >> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> Enviado el: mi�rcoles 3 de abril de 2002 17:55 >> Para: Jakarta Commons Developers List >> Asunto: Re: [logging] Need interface... >> >> >> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote: >> >>> What we need is a marker interface that indicates a tool >> wants a logger, and >>> of course a method to give it the logger... I did a quick >> scan of the >>> public API, and there doesn't seem to be one. >>> >>> So what I propose is to add an interface 'LogUser' or >> something like it (we >>> can quibble about the name...) >>> >>> public interface LogUser >>> { >>> public void setCommonsLogger(Log log) >>> } >> >> In other words, you also want a 'push' model for the logger. >> Curently each >> component is supposed to 'pull' the logger. >> >> Well, I can't say no. I prefer the current Log.getLog() pattern, but >> the whole point of commons is to be open and accept multiple points >> of view, instead of forcing everyone to use a 'right' thing. >> >> +1 on the idea - but maybe we can discuss a bit the details. LogUser >> and setCommonLogger sounds a bit weird, and I'm not sure I >> understand who >> will call the method. >> >> In JMX terms, you would have a method setLogger( >> o.a.commons.logger.Log ) >> or setLoggerName( String ) and based on some config JMX will set the >> logger. The Log???? interface will be extended by the component >> MBean interface ( if any ). Seems a valid use case, and a >> good idea to >> 'standardise' the pattern used to set the logger in a component. >> >> Maybe even a set logLevel() to tune the ammount of output the >> component >> generates - i.e. a second filter pattern. I wouldn't say no, >> since the >> pattern is in wide use in tomcat(3 at least, and other >> projects as well ) >> and quite usefull. >> >> >>> As I personally believe that just being a commons committer >> doesn't give me >>> the 'spirit-of-the-law' right to commit to the logger, I'll >> ask for some >>> even vague hint of approval from the logger people before >> moving forward. >> >> Good idea, given the amount of debate we had for each API change in >> commons-logger. I would do the same. >> >> However feel free to commit anything in the impl :-). >> >> Costin >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
