On 4/3/02 12:56 PM, "Fernandez Martinez, Alejandro" <[EMAIL PROTECTED]> wrote:
> So, if I understand you right, you just want the interface; Yes - and a note saying why it's there. We can do something in velocity-tools - declare that the interface LogWantsTool implies that the toolbox hands the tool an interface to log through. But we figured that others could use this - it's more general. > the use given to > it (i.e., the lifecycle) is left to you and your application? That makes > sense, even if it leaves inversion of control in your hands -- inversion of > inversion of control :) Well, I don't think it inverts control - it just leaves it out of the picture. Or there is an implied lifecycle - basically the component saying - "after instantiation, you can call setCommonsLog(logger) if you understand what I mean and if you want to - if not, I'll deal" geir > > Un saludo, > > Alex. > >> -----Mensaje original----- >> De: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] >> Enviado el: mi�rcoles 3 de abril de 2002 19:21 >> Para: Jakarta Commons Developers List >> Asunto: Re: [logging] Need interface... >> >> >> 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]> > -- 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]>
