doobries domain

Ever wondered what to do if JBoss causes your computer to explode? http://wiki.jboss.org/wiki/Wiki.jsp?page=WhatDoIDoIfJBossExplodesMyComputer

In the past, whenever I’ve done logging within a project, I’ve used log4j as my preferred logging package. This has been primarily for historical reasons as I started developing with Java before the JDK 1.4 logging package was available. Earlier this week, my RSS aggregator popped up informing me that a new version of log4j (1.2.13) had been released. It then occurred to me, is there a need for log4j anymore? I primarily target Java 1.4 and 5 VM’s so I don’t need to worry about the JDK logging package not being available. The log4j wiki has a page that attempts to answer this question and provides good reasoning for using log4j instead of Java logging, however I get the impression that these arguments are somewhat out of date. What is your preference for logging API? Are there any up-to-date comparisons? At the moment, I’m sticking with log4j, but I couldn’t honestly say whether this is the best approach or not.

There’s an interesting thread going on over at The Server Side based upon a comment made by Ugo Cei – "I seriously wonder why anyone would want to develop anything substantial in Java nowadays without using Spring." Having done J2EE applications using both "traditional" approaches (i.e. EJB 2.x) and more lightweight approaches (e.g. Spring), I’d choose the more lightweight approach every time. Probably the majority of J2EE applications don’t need the full J2EE stack and Spring provides all the tools necessary to get the job done. As I mentioned in a previous post, when I’ve done projects without using Spring, I’ve missed not having dependency injection (why should I really care about getting a database connection?). EJB 3 looks interesting however, yet there is a large momentum with Spring at the moment, so I don’t see either technology toppling the other. I think both technologies will co-exists side by side.

OK, that’s maybe overstating it a bit, but I do think that the tools that come with SQL Server are very developer friendly. Take, for instance, the SQL Profiler. I find that this is particularly useful when writing any code that accesses databases, or for diagnosing database problems. If you’re using Hibernate (and probably other libraries as well), you can get the sql dumped out to the console that is being executing. This is very useful most of the time, but it doesn’t contain the physical SQL that is going to be executed. It generally replaces the values from prepared statements with '?'s. For debugging SQL related work its often invaluable to see the exact SQL that is being performed and on what connection – this can allow you to easily identify any potential database locking problems. Running a SQL profile trace also allows you to see how long each query is taking and allows you to identify any potential bottlenecks in your application. I know you can do similar th...

I’ve just upgraded one of my development machines from running Fedora Core 1 to Fedora Core 2 using yum. This was a pretty painless procedure, I followed the instructions given at http://www.brandonhutchinson.com/Upgrading_Red_Hat_Linux_with_yum.html The system feels a lot faster now (I don’t know if it’s just me or if FC2 is actually faster). I’m going to leave it a couple of days and see if it remains stable. If it does, I’ll consider upgrading to FC3.

Its posts like this that make me want to start programming in Ruby instead of Java.

Update 6 of the JDK is now available for downloading from http://java.sun.com . for Windows, Linux and Solaris. The current release is now 1.5.0_06. Release notes are available here .

I recently wrote about how developers don’t always clean up correctly when using databases after I read this blog. In my blog entry I suggested that developers could use a library (such as Spring) to help them close up database resources. Well, today I stumbled across the Java Specialists Newsletter Issue 116 which details another library. The Jakarta Commons-DbUtils library does this for you. From the commons web site "DbUtils is a small set of classes designed to make working with JDBC easier. JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data" If you are using JDBC for your persistence access, I recommend that you use one of these available libraries (DbUtils or Spring etc.). After all, writing JDBC code is fairly tedious and error prone.