Re: [Logging] Facade
On Tue, 3 Jun 2003, Adam Jack wrote: Date: Tue, 3 Jun 2003 06:42:58 -0600 From: Adam Jack [EMAIL PROTECTED] Reply-To: Jakarta Commons Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Logging] Facade I have a wrapper around my commons logging calls, as such each log message is marked as from my wrapper class, not the true originator. Can I set a facade (class to ignore) like I can w/ log4j, or originator (not real name) as I can w/ JDK 1.4 logging? In short, is there a way to get the log entries marked as coming from the true originator? The existing Log implementation classes in c-l are already facades, so they go to some effort to make available the name of the class that called them. However, this support is hard coded -- for example, see the log(Level,String,Throwable) method in org.apache.comming.logging,impl.JDK14Logger. Throwing another facade around the c-l facade seems like an odd thing to do in the first place. But if you really want to do so, I'd investigate modifying the actual Log implementation class for whichever logging implementation you're using underneath. regards Adam Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Logging] Facade
The existing Log implementation classes in c-l are already facades, so they go to some effort to make available the name of the class that called them. However, this support is hard coded -- for example, see the log(Level,String,Throwable) method in org.apache.comming.logging,impl.JDK14Logger. Both log4j and JDK1.4 logging allow facades (in different ways). Could not Commons Logging (c-l) allow this as a works if the underlying implementation supports it feature? Throwing another facade around the c-l facade seems like an odd thing to do in the first place. But if you really want to do so, I'd investigate modifying the actual Log implementation class for whichever logging implementation you're using underneath. It seems wrong to ever try to get at what is beneath c-l, that is for c-l to deal with. I want this feature for users, not for myself alone, so I think it needs to be built into c-l. The primary reason I have for wrappering is: (1) I've been asked to have a property switch on/off this modules logging, to save folks getting too deep into logging configuration, and to optimise for the 99% of the time folks do not want logging. Note: This includes info/warn/errors. (2) I need to fail safe if logging is not in the environment (so can't put those classes into my code). (3) I want to be able to move to the next best logging XYZ that comes out, or whatever survives from the log4j/jdk14/c-l tussle. So, any chance of facade in c-l? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Logging] Facade
On Tue, 3 Jun 2003, Adam Jack wrote: Date: Tue, 3 Jun 2003 10:02:36 -0600 From: Adam Jack [EMAIL PROTECTED] Reply-To: Jakarta Commons Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: 'Craig R. McClanahan' [EMAIL PROTECTED], 'Jakarta Commons Users List' [EMAIL PROTECTED] Subject: RE: [Logging] Facade The existing Log implementation classes in c-l are already facades, so they go to some effort to make available the name of the class that called them. However, this support is hard coded -- for example, see the log(Level,String,Throwable) method in org.apache.comming.logging,impl.JDK14Logger. Both log4j and JDK1.4 logging allow facades (in different ways). Could not Commons Logging (c-l) allow this as a works if the underlying implementation supports it feature? Throwing another facade around the c-l facade seems like an odd thing to do in the first place. But if you really want to do so, I'd investigate modifying the actual Log implementation class for whichever logging implementation you're using underneath. It seems wrong to ever try to get at what is beneath c-l, that is for c-l to deal with. I want this feature for users, not for myself alone, so I think it needs to be built into c-l. The primary reason I have for wrappering is: (1) I've been asked to have a property switch on/off this modules logging, to save folks getting too deep into logging configuration, and to optimise for the 99% of the time folks do not want logging. Note: This includes info/warn/errors. I don't see how wrapping the configuration of the underlying logging implementation has anything to do with wrapping the log calls themselves, but ok. (2) I need to fail safe if logging is not in the environment (so can't put those classes into my code). You mean if the C-L classes are not in your code? (C-L already defaults to SimpleLog writing to System.out if neither JDK 1.4 or Log4J 1.2 can be found.) Sounds like you might want to think about turning your facade into direct calls on the underlying logging system, instead of trying to go through C-L as well. C-L isn't really buying you anything. (3) I want to be able to move to the next best logging XYZ that comes out, or whatever survives from the log4j/jdk14/c-l tussle. So, any chance of facade in c-l? You've got the source ... go ahead and propose a patch :-). For my purposes, C-L is already a facade that already exposes the method name of whoever called it. Double facading (as you propose) is not something that I'm going to spend any coding time on. regards, Adam Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Logging] Facade
(2) I need to fail safe if logging is not in the environment (so can't put those classes into my code). You mean if the C-L classes are not in your code? (C-L already defaults to SimpleLog writing to System.out if neither JDK 1.4 or Log4J 1.2 can be found.) No, if C-L classes are not in the environment my code ends up being run in. I can't control where the user runs me, so I want to tolerate C-Ls absence. Sounds like you might want to think about turning your facade into direct calls on the underlying logging system, instead of trying to go through C-L as well. C-L isn't really buying you anything. C-L is buying me yet another choice. If I went directly to JDK1.4 I am JDK1.4 only. If I go to log4j (a beautiful thing) I am conflicting w/ all the Jakarta products running to commons-logging. I don't need C-L as a code wrapper (hands on is nicer) but it is a valuable abstraction. I have thought about it, long and hard. As a user it suits my requirements/usage to wrapper C-L. C-L wrappers log4j, JDK1.4 logging -- and they allow for it. (3) I want to be able to move to the next best logging XYZ that comes out, or whatever survives from the log4j/jdk14/c-l tussle. So, any chance of facade in c-l? You've got the source ... go ahead and propose a patch :-). Yeah, maybe. I am still waiting for patches I've posted to be applied to commons-vfs/ant/others, and am getting tired of expending that energy only to wait w/ no reply. Since this is only a propose (and below you don't seem open to it) I'll not be trying any time soon. So my stuff looks stupid over C-L, I'll live. For my purposes, C-L is already a facade that already exposes the method name of whoever called it. Double facading (as you propose) is not something that I'm going to spend any coding time on. Double facading is a user/usage choice, for whatever user reasons. You don't have to code it to support it. Both JDK1.4 and Log4j allow this, 'cos they respect user choices... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Logging] Facade
P.S. C-L needs an Eclipse Plug-in Log driver and an Ant Log driver ... otherwise folks (like me) have to attempt to write C-L wrappers to try to make them. ;-) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
