Ok, following stuff happened: My app runs smooth, uses log4j (of course) and also commons-digester and some other stuff from commons.
I deploy it as a webstart-app for the first time, my stuff in one jar, libs in other jars. -> Whooaa ClassNotFoundException for some log4j classes, but the log4j jar is there! How could that happen? After some fiddling I found out that it is actually a class cast problem. Fortunatlly I found Ceki's "Think again" on http://www.qos.ch/logging/thinkAgain.html So the problem is with commons-logging, I never used it, but digester does #?!##! Thanks Ceki, you really saved me hours, if not days!!! I managed to get it running by adding the log4j classes to the digester jar. A really ugly workaround, but what could one do? So actually at runtime I have two Logger classes, with the same name and the same package, but they are different, as they are loaded by different classloaders. Conclusions: The "discovery process" of commons-logging is not only weak. it is a major bug and annoyance! I had problems with it without ever using the logging itself, who would expect that? The java classloader architecture is rotten!!! This really needs to be changed. This will become java's number one weakness. And it needs some decent versioning! And the /lib/ext dir should be thrown away! (just recently came across an applet that installs a really old xml parser in /lib/ext ! Welcome to classloader hell!) Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
