When you setup your project with commons-configuration library plugged in sometimes you can get very misleading error:
ConfigurationException: XML-22101: (Fatal Error) DOMSource node as this type not supported
This error may be caused by missing XML library bindings. In order to fix that error you have to configure properly some service providers (point JVM to correct XML parsing/transformation implementations).
Anders Janmyr has written recently an interesting article why he hates static typing:
Donald Knuth wrote in his famous paper Structured Programming with go to Statements (PDF)
We should forget about small efficiencies, say about 97% of the time: pre-mature optimization is the root of all evil
Since compilation is premature optimization, it is therefore, the root of all evil. Simple!
Pretty “smart” reasoning but stupid, IMHO.
During recent 2nd level cache implementation research I noticed EHCache has a very funny dependency: slf4j. Hey, WTH, yet another log library implementation? – I asked myself. No commons-logging as everywhere?
I googled around and found “The evils of commons-logging.jar and its ilk” article. It highlight some problems related to commons-logging usage:
I agree with 1, 3 and 4. 2 is questionable: sometimes logs sorted in one timeline allows for better error analysis.
slf4j is proposed as an alternative. It’s more modular and (probably) simpler that commons-logging. All configuration is a matter of placing selected implementation (slf4j-jdk14-1.5.8.jar for instance) jar on classpath. And voila! – logging is done thru JDK 1.4 logging. Quite simple.
Sometimes when you get an exception like this:
javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:"
you want to see what entries are visible in JNDI. No problem, place this code somewhere near lookup problem code location:
InitialContext ic = new InitialContext();
NamingEnumeration it = ic.list("java:comp");
System.out.println("JNDI entries:");
while (it.hasMore()) {
NameClassPair nc = it.next();
System.out.println("JNDI entry: " + nc.getName());
}
You will see all JNDI names availailable on console then (you can use your logging library instead of course).
Second level cache in Hibernate allows to greatly speed-up your application by minimizing number of SQL queries issued and serving some results from in-memory cache (with optional disk storage or distributed cache). You have option to plug in different cache libraries (or to Bring Your Own Cache – an approach popular among my colleagues from India 
). There are caching limits you must be aware of when implementing 2nd level cache.
Powered by WordPress