Add logging support for debugging purposes. The central logging mechanism should contain several levels of logging (e.g. i/o to the serial port, etc..) and be controlled via a properties file. -Maybe via the user interface as well.
Discussion
Anonymous
-
2007-03-07
Logged In: YES
user_id=1701854
Originator: NO
The easiest way to accomplish this is to use log4j. Two questions...
1.) Is it "license compatible" with the GPL that we have release this code under?
2.) Where is the best place to put the central logging class?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have used log4j in other projects already. Generally I vote pro it, but would propose to delay logging until we get the deployment feature done. Whatever we come up with finally, we must bring the logging infrastructure along with the JScan2052.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-03-10
Logged In: YES
user_id=1701854
Originator: NO
began design of logging feature. Using java.util.logging due to FSF stating that the Apache 2.0 license is incompatible with the GPL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-03-10
assigned_to: nobody --> jreprogle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jim,
I took a little time today looking into the logging feature. You had asked me where to pull the logger before, and unfortunately you didn't receive an answer from me. Sorry. So you decided to pull it from a central place, which is the right idea. But the Modelservice is implemented as Singleton and is too central in my opinion. A Singleton is JVM-wide which goes too far in my opinion. I introduced it during refactoring because at that point I was not sure about what the MVC structure was going to look like. (Still learning here.)
Let's think about the following: You buy yourself a second scanning device and attach it to a second serial port on your computer. With the Singleton approach we are actually lost already. We can have only one scanner attached to one port at the present version, since there is still that singleton from where I pull the device and the port. It's better in my opinion to have a context that tells to which device/port we are currently talking. That's what the context interface is actually for. At present, I replaced the Singleton references in MainframePanel and FreqPanel with calls to the context (resp. the controller).
As for the model, we will need to pass on the current context in the calls to the models, which is missing too at present. -I'm a bit behind. That's why you didn't have the right clues as to where to hook in logging. I think it belongs there, because we might have device number 1 log into logfile 1 and device number 2 log into logfile 2 (would make perfect sense to me). Provided that we ever want to support such a configuration. (Why not, actually?) Moving from a context to singleton is cheap, the other way round it includes heavy refactoring.
Sorry for the long explanation, but I thought we need to communicate a little more about that not-even-half-implemented context thingy concept.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1701854
Originator: NO
The easiest way to accomplish this is to use log4j. Two questions...
1.) Is it "license compatible" with the GPL that we have release this code under?
2.) Where is the best place to put the central logging class?
Logged In: YES
user_id=1727860
Originator: YES
I have used log4j in other projects already. Generally I vote pro it, but would propose to delay logging until we get the deployment feature done. Whatever we come up with finally, we must bring the logging infrastructure along with the JScan2052.
Logged In: YES
user_id=1701854
Originator: NO
began design of logging feature. Using java.util.logging due to FSF stating that the Apache 2.0 license is incompatible with the GPL.
Logged In: YES
user_id=1727860
Originator: YES
Jim,
I took a little time today looking into the logging feature. You had asked me where to pull the logger before, and unfortunately you didn't receive an answer from me. Sorry. So you decided to pull it from a central place, which is the right idea. But the Modelservice is implemented as Singleton and is too central in my opinion. A Singleton is JVM-wide which goes too far in my opinion. I introduced it during refactoring because at that point I was not sure about what the MVC structure was going to look like. (Still learning here.)
Let's think about the following: You buy yourself a second scanning device and attach it to a second serial port on your computer. With the Singleton approach we are actually lost already. We can have only one scanner attached to one port at the present version, since there is still that singleton from where I pull the device and the port. It's better in my opinion to have a context that tells to which device/port we are currently talking. That's what the context interface is actually for. At present, I replaced the Singleton references in MainframePanel and FreqPanel with calls to the context (resp. the controller).
As for the model, we will need to pass on the current context in the calls to the models, which is missing too at present. -I'm a bit behind. That's why you didn't have the right clues as to where to hook in logging. I think it belongs there, because we might have device number 1 log into logfile 1 and device number 2 log into logfile 2 (would make perfect sense to me). Provided that we ever want to support such a configuration. (Why not, actually?) Moving from a context to singleton is cheap, the other way round it includes heavy refactoring.
Sorry for the long explanation, but I thought we need to communicate a little more about that not-even-half-implemented context thingy concept.