Re: [slf4j-dev] Context for getLogger()
I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter. e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Sample implements Cloneable { private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ... I can provide more detail if this is not clear. What I want to know is if this is the best way do deal with the problem? In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. The specific implementation would change it as needed. What do you think?
Hi Fred, I'm currently busy with meeting a deadline. I will come back to you later, ok? Cheers, Thorsten On Monday, June 28, 2010 10:08 PM [GMT+1=CET], Fred <phreed@gmail.com> wrote (with possible deletions):
I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter.
e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory;
public class Sample implements Cloneable {
private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ...
I can provide more detail if this is not clear. What I want to know is if this is the best way do deal with the problem? In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. The specific implementation would change it as needed. What do you think? _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
That's fine. What I have works for now. On Mon, Jun 28, 2010 at 3:13 PM, Thorsten Möller <Thorsten.Moeller@unibas.ch> wrote:
Hi Fred,
I'm currently busy with meeting a deadline. I will come back to you later, ok?
Cheers, Thorsten
On Monday, June 28, 2010 10:08 PM [GMT+1=CET], Fred <phreed@gmail.com> wrote (with possible deletions):
I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter.
e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory;
public class Sample implements Cloneable {
private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ...
I can provide more detail if this is not clear. What I want to know is if this is the best way do deal with the problem? In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. The specific implementation would change it as needed. What do you think? _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Hi Fred, coming back to your posting, I have some comments/questions - inlined ... On Monday, June 28, 2010 10:08 PM [GMT+1=CET], Fred <phreed@gmail.com> wrote (with possible deletions):
I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter.
e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory;
public class Sample implements Cloneable {
private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ...
I can provide more detail if this is not clear. Indeed it is not clear. Could you describe a use case illustrating why this would be required. And maybe other options to achieve the same.
What I want to know is if this is the best way do deal with the problem? Since it is not clear to me what the actual problem is I would first try to understand it.
In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. This can all be answered if we see the complete picture.
Cheers, Thorsten
On Fri, Jul 2, 2010 at 7:27 AM, Thorsten Möller <Thorsten.Moeller@unibas.ch> wrote:
Hi Fred,
coming back to your posting, I have some comments/questions - inlined ...
On Monday, June 28, 2010 10:08 PM [GMT+1=CET], Fred <phreed@gmail.com> wrote (with possible deletions):
I have been modifying slf4j for use on android. Beginning with the slf4j-android sub-project, I am adding in a context provider to record, forward, combine, filter and otherwise manage the log. In order to do this getLogger needs to know the current context. To work around this I have added a context parameter.
e.g. import android.content.Context; import android.graphics.Matrix; import org.slf4j.Logger; import org.slf4j.LoggerFactory;
public class Sample implements Cloneable {
private Sample(Context context) { _log = LoggerFactory.getLogger(Sample.class, context); ...
I can provide more detail if this is not clear. Indeed it is not clear. Could you describe a use case illustrating why this would be required. And maybe other options to achieve the same.
The following example presumes some knowledge of the android environment. Consider a Log ContentProvider (basically a log server). In order to communicate with any ContentProvider a ContentResolver is required. A ContentResolver is obtained for a particular Context. The relevant Context object is not a global variable. Thus in order for the 'logger.info("sample message");' to work the logger must have access to the Context (or a ContentReceiver). The following attempts to explain in a non-android specific way. Suppose that you have a logging service. You connect to this logging service and wish to have that connection available within some (deeply nested) subroutine but you don't (can't) have global variables. No problem, just keep the connection as a property of the logger object. In other words put the connection (and anything like it) into a context object which is a property of the logger. The problem is I don't see a way to associate a context implementation object with a logger. I would expect there to be ILogger and IContext interfaces which would be implemented via AndroidLogger and AndroidContext classes. The ILogger.java and AndroidLogger.java files exist (but ILogger.java is called Logger.java) but no IContext.java. I have made a patch to add IContext.java and AndroidContext.java. If that still isn't clear I can post the code. But the code won't help unless you understand the problem. The problem is that the current implementation presumes certain context information is available as global variables, which aren't available when communicating between android applications.
What I want to know is if this is the best way do deal with the problem? Since it is not clear to me what the actual problem is I would first try to understand it.
In order to get this to work I have added some android specific stuff to the api/contract. The presumption seems to be that certain information is in some global variable. This doesn't seem quite right. What I am wondering is if there shouldn't be some generalization of context for slf4j. This can all be answered if we see the complete picture.
Cheers, Thorsten
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
participants (2)
-
Fred -
Thorsten Möller