Everything changes....

This blog has been moved to a new URL. Please Update your bookmarks approriately

DAS Keyboard II

Here we are... they´ve done it. Now there is an improved version of DAS Keyboard which comes in an even more simplistic design. But wait, better news to come: it is a "click"-version of its predecessor. So those, who do not suffer from girldfriends/wifes/whatever complaining about the noise: go ahead - i´ll stick with the original.

Moving targets are harder to hit ;)

Nothin´ happened in here for quite some time. The main reason is that i am busy moving from Essen/NRW to Mülheim a. d. Ruhr/NRW. If you feel that you´d need my new address/telnr etc, please send some email. I´ll be back bloggin in a few weeks.

Publication in c't 9/06

there is an article about ORM Basics (Hibernate taken as example) published in the largest german computer magazine. Guess who wrote it (in parts) ;)

tools you might need some day: pound

pound is a really neat, simple and efficient tool following the principal: do only one thing, and do it good. we use it on this server to distribute requests to different backend apache/jboss/whatever servers. it is easy to configure, works with whatever http-server on whatever platform and seems rock-stable.

from the pound website:

WHAT POUND IS:

1. a reverse-proxy: it passes requests from client browsers to one or more back-end servers.
2. a load balancer: it will distribute the requests from the client browsers among several back-end servers, while keeping session information.
3. an SSL wrapper: Pound will decrypt HTTPS requests from client browsers and pass them as plain HTTP to the back-end servers.
4. an HTTP/HTTPS sanitizer: Pound will verify requests for correctness and accept only well-formed ones.
5. a fail over-server: should a back-end server fail, Pound will take note of the fact and stop passing requests to it until it recovers.
6. a request redirector: requests may be distributed among servers according to the requested URL.

Pound is a very small program, easily audited for security problems. It can run as setuid/setgid and/or in a chroot jail. Pound does not access the hard-disk at all (except for reading the certificate file on start, if required) and should thus pose no security threat to any machine.

Pitfalls in Maven2

we (me and a co-worker) are currently working on replacing some unmaintainably large ant-scripts by using maven2. from the beginning it was a goal to avoid using maven-ant-plugin and instead rebuild (and so restructure) the old scripts. here are a few pitfalls we suffered from, so maybe you don´t have to ;)

• use a dependency to the (very) latest maven APIs instead of 2.0. we were puzzled for a day when coding a mojo that had to handle dependencies, just to find out that the getDependecies() call was added to MavenProject in some minor release.
  
  
• when converting from other build-tools, be sure to put resources to srv/main/resources instead of src/main/java. most IDEs create resources (like .properties for instance) directly in the source-tree. we created a plugin-mojo to take care of moving those resources. contact me if you could use that code.
  
  
• if you generate code, tell maven where to find it. this is done by letting maven inject the project into your mojo and registering your source directory by calling:
  
/**
* @parameter expression="${project}"
* @required
*/
private MavenProject project;
public void execute() throws MojoExecutionException, MojoFailureException
{
String outputDirectory; /* maybe injected if you want to configure it. */
[...]
project.addCompileSourceRoot(outputDirectory);
}


• If you happen to generate anything in the src/ tree (which is best to avoid anyway) be sure that this would not interfere with other people (or continuum) checking out the projects. we faced this problem, because some generator created files and continuum blew all our projects to 'broken' state because cvs update did not work anymore (file xy is in the way).
  
  
• use the m2-proxy to realize a local 'central' repository. If you don´t, you may be experiencing productivity loss when the real central is unavailable and you realize, you cannot do anything productive without maven anymore ;)
  Furthermore, use a good (read 'long') caching value for the central repository, so that (slow) outside communication is limited to a reasonable minimum.
  
  
• if you are working in a team and work with snapshots of team-created artifacts, be sure to know what mvn -U means ;) it is quite easy to fall into this one. in our case, best is to make -U a rule in order not to miss anything important. with a decent proxy, it does not hurt performance that much.
  

anyway. maven2 is a great project. even though the learning curve is a little hard if you want to do non-standard stuff (signing jars, obfuscating, code-generation with a home-grown generator etc), it definately eases our every-day life.

cool down the hot deployment

when building webapps, most people agree that hot deployment is evil. it is common to observe some mem-leaking, even though you try to be very careful not to reference classes of the webapp´s classloader from the outside world (the server´s classloader). i tried hard several times to find flaws in our code, that may be responsible for that leaking without significant success.
if you face the same trouble, you might take a few minutes to take a look at you logging habits. there are fundamental flaws in both commons-logging and log4j, that might case some trouble.

Taxonomy of class loader problems encountered when using Jakarta Commons Logging (JCL)

Class loading problems encountered when using JCL fall into three main categories:

* Type-I: A java.lang.NoClassDefFoundError thrown when a class is inaccessible from a parent class loader even if the said class is available to a child class loader
* Type-II: Assignment incompatibility of two classes loaded by distinct class loaders, even in case where the two classes are bit-wise identical.
* Type-III: Holding references to a given class loader will prevent the resources loaded by that class loader from being garbage collected.

easiest way to find out if you suffer from this one might be SLF4J:

One of the benefits that SLF4J offers is a reimplementation of the various Commons Logging APIs which will not leak memory. You can continue to program to those APIs. Just deploy your application with jcl-over-slf4j.jar and you'll have the best of both worlds: the ubiquitous JCL API and a non-leaking implementation thereof. This is not a BAD thing.
This is only one use of SLF4J, but it is an important one. I was able to fix an un-unloadable application by replacing ("augmenting") Tomcat's JCL usage with SLF4J.

there is some weakness (or, "strong-ness" in this case ;) in log4j too:

Looks like a logger implementation issue to me

Just my experience with unloading webapps with log4j and Tomcat. Log4j uses Introspector to make some reflection magic during configuration phase (I could be wrong, I fixed some months ago). The problem is that, even if WeakHashMap are used, classes, that are keys in the maps, do not get gc in acceptable time (at least for me). Putting
Introspector.flushCaches();
in my servlet fixed the issue.

taken from here.

I did not try these suggestions yet, but i damn sure will asap.

local JUG

browsing openbc, i found a Java User Group in the local area. there is going to be a meeting next week where some guy will present a usage of EJB3 outside of the container using Spring. if you live in the area and want to join in... event details can be found here

JSP 2.1

here is an interesting article about JSP 2.1. luckily they finally unified the expression language. thx to Marcus for bringing my attention to that one.

maven 2

i really wish i had more time. maven2 obviously kicks the ass out of my/our old, hard to maintain ant-buildfiles. a known (and somewhat controversial discussed) feature of maven is to create a techie website for your project. if you´d like to get started, try this article, as it takes you step by step to your shiny new maven-based project website.

Easy Message passing

if you´re into J2EE pre 1.5, there is a chance you are pissed by the "boilerplate code" you have to create. (as you probably know) this is where dependency-injection frameworks like spring come in. here is an interesting article providing an overview of how to use spring to simplify your JMS code.

EJB Update

there is a great oracle white-paper providing an overview of changes that EJB3 will bring. although it is not complete, it gives a quick insight of the "brave new ejb3-world".

Blackbelt evolves

as time went by, javablackbelt evolved from what can safely be called an "ambitioned under construction website" to something working. there is an impressive number of exam-takers and registered users down there and the new moderation process seems to make life easier. belt-exams for yellow belt, as well as a few 'belt-relevant' questionaires are up and usable. few of the questions are indeed challenging, but most of them (only basic exams are ready to take) can be considered a cakewalk. noteworthy about this website is, that it does not limit its scope to what sun provides certifications for: there are spring, hibernate struts and jboss exams planned.
best thing though is that some mocks for sun exams and study-guides are to be found there.

if you did not yet, you should consider to take a look.

domain renamed

as you might have noticed, the host uwe.72dpi.de has been renamed to uwe.codesmell.de
this was necessary due to the move of 72dpi.de to another physical server. please update your links/bookmarks/feeds/adressbooks accordingly.