Ever wondered what to do if JBoss causes your computer to explode?
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 things in Oracle (in version 9 at least – I’ve not seen 10 yet), but they’re just not as developer friendly. I’m not knocking Oracle, I think its a fantastic database also, however I feel it is let down by its developer toolset.
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.