Some developers seem to think that logging is not really all that useful or important. I've worked with people who have this view. They think that the only way to solve a problem is to launch your program within an IDE or debugger, insert break points, look at variables, step ahead a statement or five, etc.
This method indeed is suitable for some problems. But it's not by any means suitable for all situations. Take, for example, multithreaded applications. Or, what about the case of very intermittent errors in a critical operational system that runs on a 24/7 basis? If you've got 168 hours a week to sit there running the application manually within your IDE, in parallel with the operational runs, waiting for that once in every 5-32 days anomaly (and really hoping that when it occurs operationally it also occurs within your IDE launched and monitored run) -- well, go right ahead and enjoy yourself!
But, guess what: there's a good chance that these unusual, intermittent failures won't be repeatable, and they won't occur in your IDE or debugger driven run, or any attempted rerun! They're intermittent! So, now what do you do? The damaging failure has occured once again, your boss is hovering over you saying "Well, you were watching it. So what happened, and why?" And you... umm... haven't a clue?
Logging has been an important component of operational systems since the inception of operational computing systems. A log is simply a very basic monitor. What complicated system runs without instrumentation to enable the operators to assess the performance of the system? Are we in a "nominal" state (i.e., nothing unusual stands out), or is something flashing an edge or out-of-bounds condition? That's what logs are for.
OK. So much for lecturing against logging naysayers. Just take it from someone who has decades of experience in the area: logging is of critical importance for operational systems.
is a small, yet powerful logging library for mobile devices based on the Log4j API. Supports Java ME (J2ME) and Android. Logs to device, to PC or to servers online. Used in all phases from development on emulator/device to outdoor field-testing.
The benefits of Microlog include:
Easy to set up
Similar to Log4j
Small
Fast
Mature
Many different logging destinations: Console, RecordStore, File, Canvas, Form, Bluetooth, ... (many more)
Different formatters for different needs
Now, I think I'm in the minority of developers in that a requirement of the software engineering work I do is that the operational system has access to me on a 24/7 basis. I mean, it's a requirement of my job that a text message sent by the operational system can immediately get to me. My Blackberry is within hearing range (almost) constantly. I've even created my own custom messages to send to myself based on certain criteria being met by scripts I've created to troll the data situation.
Why? Because certain messages from the operational system might require an immediate response from me (and others). We're supposed to be up and running 24/7. We have a number of nines of availability that we've contracted to provide. We don't want to fall below the required nines. Our future viability as a data center design, development, and operational management team depends on success in fulfilling the required uptime.
Microlog makes it easy to notify developers or operators that anomalies or potential problems may have emerged. Of course, you can also use it for basic debugging as you develop or update a new application. And it's tuned for JavaME and Android. For that to be the case, it has to be lightweight and fast. It's also mature, having been around since 2005.
If you're working on JavaME or Android code, and you need help with assessing the characteristics of operational code, or code that is intended for an operational environment, Microlog looks to me like something quite worthy of your investigation.
Just returned from ØREDEV last Friday. Again, a great conference! Not only was it extremely well organized but I also really liked the size of it (800 attendees – not too big, not too small), the location (an old car factory!), the wide range of topics, insightful speakers, real-world focus, and last, but not least, the friendly atmosphere....
After the latest upgrade of my Hudson instance, I noticed that a new option in the security matrix appeared: it allows anonymous visitors to have a (read only) look at a job configuration, if the administrator allows it. I think it's a great feature (that I was asking for some months ago), as it allows to share our knowledge about our favourite CI tool. So I've opened most of my jobs and you can poke your nose into them; for instance, http://hudson.tidalwave.it/hudson/job/ForceTen%20Release/configure (please note that the "/hudson" part could go away in a few days, if the previous link doesn't work try http://hudson.tidalwave.it/job/ForceTen%20Release/configure). I'll comment about it in a few days, as it implements for the first time a dream that I had months ago, that is the capability of making a release with just a single mouse click...
As a programmer, I spend a lot of time fixing bugs. And a considerable portion of that is the time spent on reproducing a problem. Here is how a typical such session goes. Your user reports that your program doesn't work and throws such and such exception. Or given the symptom he's describing, you suspect some "if" statements to be evaluating to false. If you are lucky and experienced, you can sometimes fix the problem through careful reasoning, but often you need to collect more data to be able to fix the bug. Logging is one such measure, but I often find myself thinking "if only I could ask him to run the program with a debugger and report what the variable 'x' refers to!" After all, a debugger is an ultimate data collection tool. Unlike logging, your program doesn't need to be written a-priori to report data. Similarly, with an ability to inspect stack frames all the way down, evaluate arbitrary expressions, and modify the state of the target problem, a debugger is a far more powerful trouble-shooting tool. The one and the only problem with asking your user to run a debugger is that it's too difficult...
In the Forums, indiika is having a problem with JSP to class file conversion: Hi all, I'm having a small problem. As we know JSP is converted to class file before execute. So I would like to know where this temp class files are created. Specially in Weblogic Server. Lakmal
rahul1kr needs help with JAX-WS custom data type handling: "Hi, I am new to JAX-WS webservice. I have created JAX-WS service which will take custom bean classes as input paramter and return the list of same. Now, I need to write client like DII client(in axis) for WS. The..."
And tspladmin is getting an Intermittent ClassCastException: "I am using Glassfish-v2ur2 on a Windows machine for developing a J2EE web-app. It is being run with the -client option. Sometimes, while re-deploying an application under development, I see a deployment failure with the server log indicating a..."
Our current Spotlight is Geertjan Wielenga's post Financial Applications on the NetBeans Platform: "Experian and Société Générale both have invested in the NetBeans Platform, by using it as the basis of one or more of their applications. And these two are not exactly small organizations. Experian is a global leader in consumer and business credit reporting and marketing services and a constituent of the United Kingdom's FTSE 100 index, with revenues in excess of US$4 billion, while Société Générale is France's second-largest bank by market value. How do I know that these organizations are using the NetBeans Platform? By looking in the dev@openide.netbeans.org mailing list..."
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
