Well, this post has nothing to do with java, but I though it would be important, since this issue caused me a lot of frustration. I recently bought a laptop with Windows Vista Home Premium, and I was frustrated at what seemed to me that it was a hardware problem. Well, it wasn't. It was a windows "feature" ;-)
The "feature" that annoyed me was that the screen blinked a couple of times when I was logging in, in a matter that seemed as if the screen is faulty. The same thing happened when I wanted to do something that windows think that I shouldn't do, like moving a read only file, or run an executable program (yet another windows "feature"). When I tried to do any of those actions that would cause a security problem, I got a prompt to ask me if I allow this action, with the desktop disabled, and with an occasional screen blink (totally random).
Well, after some googling, I found the causes of those two really annoying "features". The first "feature" was the Transient Multimon Manager (TMM). This TMM is "a Microsoft Windows Vista operating system feature" responsible for detecting your monitors as you connect/disconnect them to/from your mobile PC. You may regard TMM as a good feature in case you use multiple displays (external monitor, projector, etc.) especially that "TMM persists the user's settings on a per-display basis when possible".
When you seldom use multiple displays (like me), TMM is of no value. So, how do we turn it off? Simple. Go to task scheduler (present under "Accessories/System Tools"), then go to "Task Scheduler Library/Microsoft/Windows/MobilePC", and you'll find a TMM task. Disable it, and you're done (of course you'll have to restart your system for the change to take effect, because the task will already be running). You can also disable the trigger of the task. I do not recommend deleting the task altogether, since you might need it in the future.
Now for the second "feature". Windows vista has what's called "secure desktop". Well, it is a good feature to be frank. When you try to do an action that Vista thinks that it might be the result of a malicious action, it will prompt you whether you allow this action or not. This is not "secure desktop" by the way. Secure desktop is responsible for locking all the processes running in the background so that if the action was really performed by a piece of malicious software, it wouldn't give this piece of software the ability to mimic the user allowing the action to be performed.
So, if you think that you will never have malicious software, and you don't want secure desktop, all you have to do is to run your registry editor (just type "regedit" in the "run" screen), and go to "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/
CurrentVersion/Policies/System", and change the value of the "PromptOnSecureDesktop" to "0" (that's a zero not an O) instead of "1". This will remove secure desktop (hence the occasional blinking) but will not remove the prompting. I recommend that you keep secure desktop for the security reasons, but that's just me.
Edit on 6/1/2008:
I would like to thank Matt for supplying this link in his comment. I think that the screen shot woul give you a little help. Thanks Matt
Saturday, October 20, 2007
Saturday, October 13, 2007
Commons Logging may be harmful to your health
All of us know that decoupling your code from the frameworks you use is a really great thing. This is why bridge libraries like commons logging are really wonderful. Just imagine how much code you will be changing if you are using log4j APIs in all of you application classes, and then a decision was made to start using the java APIs instead. Think of how much code would be changed. But with commons logging, the code changes would be minimal. Another thing, look at how many open source projects that are using commons logging. This must mean that commons logging is a good thing, right? WRONG!
First, let us define the meanings of "good" and "bad" concerning libraries such as commons logging. I think, that a "good" library would be able to bridge your logging requests to the logging framework of your preference with minimum interference and a very small overhead. I don't have to mention here that it should be stable and bug free of course. Another thing, which I personally think that it's very important, is that it should be as simple as possible.
If we take a look at JCL (Jakarta Commons Logging), we'll find that a lot of those aspects are not met. JCL works in a quiet complex way. It has a discovery mechanism to see which logging library you have in your application, and then uses class loading to load the logger that will be used. Even though this does the job, this class loading solution has its drawbacks. First of all, this may cause a lot of problems if your application is in a strict class loading environment (like OSGI for example). Another thing, JCL has a bad history with it's class loading solution.
Version 1.04 of JCL that was released on the 16th of June 2004 had some serious problems with its class loading mechanism. Ceki Gülcü (the original author of log4j) wrote a marvelous article on the subject. He also wrote a great piece on JCL, but might be a little outdated. Even though version 1.1 of JCL, released about 2 years after 1.04, claims that the bug is fixed, it's still a risk to use it, especially for the complexity of this library.
Another thing that needs to be mentioned here is that Rod Waldhoff, the author of commons logging, wrote a blog entry in 2003, titled "Commons Logging was my fault", where, in the last part of it, he says where to use and, more importantly, not to use JCL. To conclude it, JCL should be used in small and tiny components that are intended to be used by other developers in their projects. Even with that, Erik van Oosten created a project called "Version 99 Does Not Exist", which is an empty JAR with a pom file and maven meta data, so that you would put it in your maven repository, so that libraries that depend on JCL would not download it from the net, since the empty JAR is version 99.
So what else should we use? Well, I think that SLF4J is a great project. It's a simple facade for various logging APIs. The beauty of it is that instead of the class loading solution, it is just a simple facade, where you just plug in the desired implementation at deployment time. It's a very simple solution, "perhaps even laughably so" as stated in their FAQ.
SLF4J is wonderful, simple, stable and can be used in strict class loading environments like OSGI. It can be used with log4j, jdk1.4 logging, SimpleLogger, logback and x4juli (the latter 2 provide native implementation of SLF4J APIs). It's very simple to migrate to SLF4J from JCL. Simply download "jcl104-over-slf4j.jar", and it will delegate JCL calls to SLF4J.
SLF4J also has a couple of great features, parameterized logging and MDC support. Parameterized logging can cause a significant increase in the performance. One last thing that I have noticed, which is quiet funny really, several apache projects use SLF4J instead of commons logging. This sure shows that SLF4J is on the right track.
First, let us define the meanings of "good" and "bad" concerning libraries such as commons logging. I think, that a "good" library would be able to bridge your logging requests to the logging framework of your preference with minimum interference and a very small overhead. I don't have to mention here that it should be stable and bug free of course. Another thing, which I personally think that it's very important, is that it should be as simple as possible.
If we take a look at JCL (Jakarta Commons Logging), we'll find that a lot of those aspects are not met. JCL works in a quiet complex way. It has a discovery mechanism to see which logging library you have in your application, and then uses class loading to load the logger that will be used. Even though this does the job, this class loading solution has its drawbacks. First of all, this may cause a lot of problems if your application is in a strict class loading environment (like OSGI for example). Another thing, JCL has a bad history with it's class loading solution.
Version 1.04 of JCL that was released on the 16th of June 2004 had some serious problems with its class loading mechanism. Ceki Gülcü (the original author of log4j) wrote a marvelous article on the subject. He also wrote a great piece on JCL, but might be a little outdated. Even though version 1.1 of JCL, released about 2 years after 1.04, claims that the bug is fixed, it's still a risk to use it, especially for the complexity of this library.
Another thing that needs to be mentioned here is that Rod Waldhoff, the author of commons logging, wrote a blog entry in 2003, titled "Commons Logging was my fault", where, in the last part of it, he says where to use and, more importantly, not to use JCL. To conclude it, JCL should be used in small and tiny components that are intended to be used by other developers in their projects. Even with that, Erik van Oosten created a project called "Version 99 Does Not Exist", which is an empty JAR with a pom file and maven meta data, so that you would put it in your maven repository, so that libraries that depend on JCL would not download it from the net, since the empty JAR is version 99.
So what else should we use? Well, I think that SLF4J is a great project. It's a simple facade for various logging APIs. The beauty of it is that instead of the class loading solution, it is just a simple facade, where you just plug in the desired implementation at deployment time. It's a very simple solution, "perhaps even laughably so" as stated in their FAQ.
SLF4J is wonderful, simple, stable and can be used in strict class loading environments like OSGI. It can be used with log4j, jdk1.4 logging, SimpleLogger, logback and x4juli (the latter 2 provide native implementation of SLF4J APIs). It's very simple to migrate to SLF4J from JCL. Simply download "jcl104-over-slf4j.jar", and it will delegate JCL calls to SLF4J.
SLF4J also has a couple of great features, parameterized logging and MDC support. Parameterized logging can cause a significant increase in the performance. One last thing that I have noticed, which is quiet funny really, several apache projects use SLF4J instead of commons logging. This sure shows that SLF4J is on the right track.
Subscribe to:
Posts (Atom)