Weblog for Costin Manolache

Finding an entity in appengine console

2010-07-08T16:36:00.000-07:00

Appengine has a nice "datastore viewer" - you can browse your data, but if you want to find a specific row you need to run a query. The syntax is not obvious from the documentation if you're selecting by primary key:

SELECT * FROM DeviceInfo WHERE __key__ = Key('DeviceInfo', 'my_key')

I have a DeviceInfo table, with a primary key called 'name'. You can find about __key__ and Key in the docs, but I had to try many combinations to find that the first param is actually the type and the key name doesn't matter.

Server to Android messages

2010-05-28T10:34:00.001-07:00

Also check: http://code.google.com/p/chrometophone

Froyo required.

Backup windows from linux

2010-02-22T10:09:00.000-08:00

ntfsclone - to copy/backup to, included on ubuntu live/install CD. Tar doesn't seem to work very well.

This is for moving windows to a larger disk, or making a snapshot to restore later.

I got a new netbook, removed all the garbage, installed my stuff ( chrome, firefox, etc ), saved the 'restore point' and installed ubuntu. I only use windows for netflix and occasional testing - so I don't want to deal with any windows-specific backup program or to have to reinstall.

ZLib memory overhead

2010-01-11T12:49:00.000-08:00

I was testing some compression code - and the load tests were running out of memory. Looks like ZLib allocates about 256K per compressor. I tried this with both BEST_COMPRESSION and BEST_SPEED - looking at Shallow Heap in eclipse heap analyzer, 2x32k short[] and 2x64k byte[].

With SPDY you need to keep the header compressor around for the entire kept-alive connection. HTTP connections only use gzip for individual requests - the context and memory can be reclaimed, so a kept-alive connection has a very small cost - can be as low as just a socket in a selector, sometimes few extra buffers.In tomcat-lite there is one 8k buffer associated with the connection - not hard to get rid of it, but low priority.

Heap dumps - looking at all objects and fields in a live system, without a debugger

2010-01-06T11:06:00.000-08:00

Do you have a java server - maybe in production - and you want to look at the value of some field ? You can't attach a debugger, this would require starting the server with various flags - but you can get a heap dump, which includes all objects, including the value of their fields.

The other use is to generate a heap dump before and after running a load test - and look at garbage to evaluate how much work you put on the garbage collector and find leaks. There are profilers that can get better results - but this is pretty fast and free way to get the same result, and you can use it against running systems.

Getting heap dumps:

 jmap -dump:format=b,file=heap3.bin PID_OF_JAVA_PROCESS

Using code ( in a servlet, etc ):

server = ManagementFactory.getPlatformMBeanServer();
server.invoke(new ObjectName("com.sun.management:type=HotSpotDiagnostic"),
              "dumpHeap",
              new Object[] {fileName, Boolean.TRUE}, 
              new String[] {String.class.getName(), "boolean"});

Looking at the data:

  Eclipse MemoryAnalyzer

or

  jhat heap3.bin

  open http://localhost:7000

Flush() in a compressed stream

2010-01-02T09:38:00.000-08:00

I finally understood the difference between 'sync' and partial flush: http://www.bolet.org/~pornin/deflate-flush.html

Since last byte may not end on a 8-bit boundary - you need to pad, i.e. to end the current compression block and start a new one. The interesting part is that a flush with Z_SYNC_FLUSH inserts 0x00 0x00 0xFF 0xFF - but protocols like PPP can strip it.

Another good link: http://www.zlib.net/zlib_tech.html

Chrome, SSL and Tomcat - or other JSSE-based engines

2009-12-22T22:45:00.000-08:00

If you try to use Chromium with a java server running https - be aware of this bug:
http://bugs.sun.com/view_bug.do?bug_id=6728126

Chrome will use a nice TLS extension - RFC4507, SessionTicket - to allow servers to reuse the session without a second roundtrip and without having to cache the session ( which is quite tricky if you use load balancing - there is no easy way in java to do so ). Of course - JSSE doesn't support the extension, the bug is that it can't even ignore it. Besides saving the roundtrip this also saves some CPU time on both ends - good thing chrome added this.

I spent some time today trying to figure out what was happening - the good news seems to be that it's fixed in recent jdk builds. Unfortunately ubuntu doesn't have the fix yet (not even Karmic), and probably Mac is also behind.

Filed a chrome bug as well - I think reversing the order of SessionTicket and hostname extension would solve this.

The server name extension is another nice thing - it allows chrome to specify which host it's looking for in the first ClientHelo packet - so server can send the right certificate. The "Host" header will be sent after the encryption is started - this is why many https servers require one IP address per host and can't do virtual hosting with SSL.

Sipdroid, gizmo, android, NAT fun

2009-12-19T20:09:00.000-08:00

Few notes on my setup - in hope others will not have to waste so much time. I have a couple of VOIP devices behind a router without SIP support, and SIP is very sensitive to UDP ports.

Network looks like this:

pretty dumb DSL router ( not modem !) - I'm setting it for my parents, that's what they have.
a linux host running siproxd. Next I'll try with an even smaller box ( an openWRT router ) - to save power.
One Grandstream box connected to a regular phone
Android device, with SipDroid.

The firewall is set to forward all UDP and TCP to the linux box - I added a 'custom' rule, I don't want to deal with the dsl router, all real filtering in linux. You can specify the SIP range - 5060 + whatever RTP.

I'm using Gizmo - I like that it's integrated with google voice, relatively easy to set software for most OSes, etc. Well - not so easy to get sound to get gizmo to work on ubuntu with pulseaudio - lot of time wasted there too - I set gizmo to OSS and used "aoss gizmo", this seems to work for me.

One big problem: siproxd can't deal with the 2 identities, i.e. the ascii username and the phone number.

As a rule, I ignore all the gizmo usernames and use only phone numbers. That means user@proxy01.sipphone.com will not work, neither "call gizmo" in the UI. To dial you must use 1234@proxy01.sipphone.com, or "call SIP" in their UI.

On Grandstream - normal registration, with outbound proxy set, no STUN.

On Sipdroid - there is no direct support for proxy, but you can set the "Server" to the IP address of the linux box running siproxd, and than set Domain to proxy01.sipphone.com. Note that older versions of sipdroid don't have the option - just upgrade with latest from market.

So far no problems with the setup - getting my parents to figure out how to dial and where to connect the wires is another story.

Handbrake 0.9.4 on Hardy

2009-11-30T10:27:00.000-08:00

Handbrake is a very nice tool - 'just works' in most cases, has good presets so you don't need to know arcane compression options. They just released a new version - which drops support for .AVI and few other things. I think it's great to see this happen - it's not that common for projects to cut features instead of half-supporting them. On the other hand some devices only work with .avi - so I'll keep the old version around.

Another remarcable thing about Handbrake - they link statically, the binary has only very basic dependencies.

The official download is for Ubuntu 9.10 - I had to compile from source, the CLI version is easy to compile - for GUI you need webkit and few other things, so I'll wait for an official backport.

The only trick for compiling CLI is also compiling current yasm from source, the version in hardy is too old. Simple configure/make install works, just make sure you remove the package with "apt-get remove yasm" if you have the old version installed.

Required packages (besides libtool/autoconf/build-essentials): zlib1g-dev libbz2-dev intltool libglib2.0-dev libdbus-glib-1-dev libgtk2.0-dev libhal-dev libhal-storage-dev libnotify-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

Compiled binary, if you want to skip the compilation -
"gzip -d HandBrakeCLI-0.9.4.gz ; chmod +x HandBrakeCLI-0.9.4"

Trying Maven

2009-10-14T18:08:00.000-07:00

I have never used maven in a project I'm working on - mostly because I disliked the rigidity and 'we know better than you what you need and want'.

Today I wanted to make it a bit easier to build tomcat-lite - and decided to add a maven option. Tomcat-lite is far simpler than tomcat - it may work. I even accepted moving few files around - I couldn't get myself to create the ugly, deep hierarchy - but it seems you can specify 'sourceDirectory' and include resources from the java tree.

Results: I could build the connector and servlets just fine, downloading the deps was nicer than the custom ant tasks that tomcat uses. The main engine - which depends on some files from main tomcat - it looks like no luck.

I found no way to specify exclude patterns on sources, and using a pre-generated jar file is a mess - you must import it in the repository, far from easy or automated. And all the syntax I had to use took a lot of effort to find and tweak - documentation is certainly not targeted to how to make maven work the way you need, but to make you work in whatever way is easier for maven.

Conclusion: Apache-Ivy does the download better - and has a nice task to copy the jars in a lib, and integrates quite nicely with ant. It is even easy to download Ivy and get it to download the rest. Far easier than Maven - and I just used the same pom.xml I was using for maven.

I'll let the pom files around, in case someone wants to use them - but I will continue to avoid maven and projects that only build with maven.

Fixing the annoying Java 2-line logging format

2009-09-27T20:56:00.000-07:00

java.util.logging is far from perfect, but for me the main reason to not use it is the hard-to-read default formatter which shows the date on a whole row. There are more compact formatters - but you need to write code to install them, or edit the command line.

So every time I install a JVM, I change the logging formatter:

1. in $JAVA_HOME/jre/lib/logging.properties, replace

java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
with

java.util.logging.ConsoleHandler.formatter = org.apache.juli.JdkLoggerFormatter

2. copy TOMCAT_HOME/bin/tomcat-juli.jar to JAVA_HOME/jre/lib/ext.

Java flush() - not what you would expect

2009-09-06T20:36:00.000-07:00

What I expect: flush() on the output stream to send the data. After flush() is completed, I expect the receiver to be able to read the data. Operating system and network may have their own delays - flush() is less than commit, so there is no guarantee that data is completely received, or it will ever be received when flush() is done, but it shouldn't be stuck in an intermediate java buffer with no way out until close().

OutputStream.flush() documentation seems to match: 'forces any output bytes to be written out' and clarifies that if any bytes have been buffered, they should be written to their "intended destination". And it clarifies that the OS may further buffer "the bytes are passed to the OS for writing", and not that "they are actually written".

Let's take few examples: SocketOutputStream and FileOutputStream do nothing in flush() because they don't buffer anything, so write() will pass the bytes to the OS.

BufferedOutputStream is the best example of what to do when buffering: it does send all the bytes to the next stream in the chain AND calls out.flush(), so the data will go to the 'intended destination' - the buffer is just an intermediary. Well known that if you want any decent performance you should use BufferedOutputStream. Not so well known - you can use better buffers, for example one that doesn't reallocate and copy the byte[], but instead keeps a list of buffers.

The biggest offender: DeflaterOutputStream. Flush will just call out.flush()., but keeps recent bytes in its buffer. Worse - the actual Deflater doesn't even support zlib flush.

For Servlets, flush() does the right thing - the bytes go all the way to the net. Unless you're using compression, and the serlvet engine uses java Deflater - in which case flush() will not push bytes to the net, they get stuck in deflater. GZIPOutputStream extends Deflater and has the same problem - tomcat's coyote GzipOutputFilter and the example compression filter won't actually flush to the net.

The alternative for compressed output that flush() - http://www.jcraft.com/jzlib/, BSD licence, pure java - has some good info about the flush() problem ). You can also use JNI and libz - Harmony's Deflater is a good starting point - but Harmony has same bug as Sun VM.

More on FutureTask

2009-06-04T11:33:00.001-07:00

Adding to my previous FutureTask post: Future is a very nice interface, but the main problems with FutureTask are the lack of a callback and the clumsy constructor that requires a Callable. I guess their main use case was someone creating a FutureTask that performs a slow operation - as in my example, it is relatively easy to wrap the method in a Callable and then execute the FutureTask in a thread pool.

It is possible to add a callback by overriding FutureTask.done(), which is called after FutureTask.set().

There are few tricks to better use FutureTask. Let's say you have an operation that happens in background already, and you're notified with a callback. You want to wrap it in a Future to make it easier to use:


  interface Callback {
    void done(Object1);
  }

  void doSomethingAsync(Callback callWhenDone) {
  }

  class MyFuture extends FutureTask {
    public MyFuture() { 
      // FutureTask _requires_ a callable - even if it's not using it. Let's give him a dummy one.
     super(new Callable() { public Object1 call() { return null; }});
    }
    // set() is protected - need a visible method to let future know the result 
    public void gotTheResult(Object1 result) {
      this.set(result);
    } 
  }	

  Future<div class="youtube-video"><object1> getSomethingFuture() {
    final MyFuture res = new MyFuture();
    // We _don't_ submit it to an executor - so run() will not be called
    doSomethingAsync(new Calback() {void done(Object1 result) {
      // do what innerRun() does - i.e. call innerSet with the result. 
      // innerSet() will set state to RAN , even if the callable was never called.
      res.gotTheResult(result);});
    return res;
  }

My synergy settings

2008-11-10T15:51:00.001-08:00

I have multiple laptops and computers, and sometimes use them at the same time - it is convenient to use a single keyboard
and mouse. The problem is that the config is not fixed - and synergy is quite hard to reconfigure dynamically.

I start a synergys server on each computer whose keyboard I may use, and use a couple of scripts to create tunnels and
restart the clients.

The trick is to not use specific hostnames - but dummy ones, and explicitly set the "-c clientname" param. Then all real
config is done using ssh tunnels - with the extra benefit of

Server:
synergys -n localhost -a 127.0.0.1:24800

# optional: ssh to shared server ( if the keyboard host is behind another firewall ):
ssh -f -N -R 24800:127.0.0.1:24800 public_computer_with_sshd

Server config: ~/.synergy.conf

section: screens<br />      localhost:<br />      up:<br />      down:<br />      left:<br />      right:<br />end<br /><br />section: links<br />      localhost:<br />        down = down<br />        up = up<br />        left = left<br />        right = right<br />     up:<br />        down = localhost<br />     down:<br />       up = localhost<br />     left:<br />       right = localhost<br />     right:<br />       left = localhost<br />end<br /><br /><br />

On client:

   ssh -N 24800:127.0.0.1:24800 server &
   echo $! > ~/.synergyssh.pid

   killall -9 synergyc
   synergyc -n down localhost

I have few client scripts, pointing to different keyboard servers and layouts.

Intercepting SIGTERM

2008-08-14T13:32:00.000-07:00

The 'proper' way to terminate a java process on unix is by sending SIGTERM, waiting a bit, and then sending SIGKILL. This gives java a chance to clean - using Runtime.getRuntime().getShutdownHook().

If you want to intercept this and do some early cleanup, before letting the others do theirs you need to use sun.misc.Signal - which can also be used to intercept other signals.

Things to do in a shutdownHook ? Flush the logs, finish important background processes and much more.

Code to intercept the signal:


oldSigTERM = Signal.handle(new Signal("TERM"),
                new SignalHandler() {
    public void handle(Signal signal) {
      System.err.println("Quit using SIGTERM hook");
      notificationHandler.prepareToQuit();
      if (oldSigTERM != null) {
        oldSigTERM.handle(signal);
      }
    }
  });

Common-sense on unit testing

2008-08-08T17:42:00.001-07:00

The Cafes » Harold’s Corollary to Knuth’s Law

Using FutureTask

2008-03-20T10:46:00.001-07:00

This is what I typically use to convert a sync method to a background Future. The benefit is that it avoids a lot of custom code (creating threads, locks, etc ) and seems simple enough, and it's relatively easy to cut&paste.

Original:

 
  Result1 slowMethod1(Param1 p1, Param2 p2) throws Exception1 {
  }
  Result2 slowMethod2() throws Exception2 {
  }

  void caller() throws Exception1, Exception2 {
    // slowMethod1 and slowMethod2 are independent of each other
    Result1 r1 = slowMethod1(p1, p2); // first expensive operation
    Result2 r2 = slowMethod2(); // other slow method, not using the result or side-effects of the first
  }

New code:

 
  Executor bgTasks = Executors.newCachedThreadPool(); 

  Future slowMethod1Future(final Param1 p1, Param2 p2) {
    FutureTask  fr = new FutureTask(new Callable() { 
      public Result1 call() {
        return slowMethod1(p1, p2);
      }
   });
    bgTasks.execute(fr);
    return fr;
  }

  void caller() {
     Future fr = slowMethod1Future(p1, p2);
     Result2 r2 = slowMethod2(); 
     try {
      Result1 r1 = fr.get();
    } catch(InterruptedException e) { 
       throw new RuntimeException(...);
    } catch (ExecutionException e) {
       Throwable t = e.getCause();
       if (t intanceof Exception1) { 
         throw (Exception1) t;
       } else {
         throw new RuntimeException(t);
      }
    } 
   }

JConsole in local mode and tomcat

2008-02-27T21:17:00.001-08:00

After some debugging found that Jconsole will connect locally to a new MBeanServer created via ManagementFactory.getPlatformMBeanServer(). Tomcat will look for an existing MBeanServer and create one if needed - but this will be different than what jconsole uses.

The fix is 2 lines - benefit is that you can start tomcat normally, without any special flag, then connect with jconsole and inspect/modify settings. It looks like they use some signal or other form of communication on Linux, which opens a TCP port.

I'm not sure why someone would ever want to use MBeanServerFactory.findMBeanServer() and createMBeanServer. Sure, in the rarely used sandbox mode, if you want to strongly isolate apps it may be needed - assuming you want each untrusted app to have access to its own server, and grant it create mbean server rights.

Time to send a patch - long time since I haven't done that...

OFX download for vanguard

2007-12-25T22:29:00.001-08:00

I've been using ofx.py to get my transactions from Vanguard, it stopped working sometimes this month. I have some code to parse and merge the sort-of-xml responses to an .xls file - which for me works much better than any alternative I tried. Moneydance is close, it provides an API that can be used to extract same data and it's a bit easier to setup, but it does some magic and seem to be less stable. Quicken, Money - never found a way to get my data back, and won't work on linux too well.

Made few changes to get it working again, first the setup is:


               "caps": [ "SIGNON", "INVSTMT" ],
               "fiorg": "vanguard.com", 
               "url": "https://vesnc.vanguard.com/us/OfxDirectConnectServlet"

The main change besides url is the code to get the transactions, urllib2 seems to default to HTTP/1.0, couldn't find a way to force it to 1.1 so I changed the code to use httplib directly:


            garbage, path = urllib2.splittype(self.config["url"])
            host, selector = urllib2.splithost(path)
            h = httplib.HTTPSConnection(host)
            h.request('POST', selector, query, 
                      { "Content-type": "application/x-ofx",
                        "Accept": "*/*, application/x-ofx"
                      })
            res = h.getresponse()
            response = res.read()
            res.close()

Old:


        request = urllib2.Request(self.config["url"],
                                                query,
                                               { "Content-type": "application/x-ofx",
                                                  "Accept": "*/*, application/x-ofx"
                                               })
        print "RES: ", res, " ", res.status, " ", res.reason
       f = urllib2.urlopen(request)
       response = f.read()
       f.close()

JAAS and tomcat

2007-09-29T17:10:00.001-07:00

The JAAS ( authentication/authorization ) API has been around for many years now - the idea is to use a standard API for all authentication, and plugins to use NT, LDAP, PAM, SSO and any other realm. JAAS seems modeled after PAM - the auth API for linux ( and unix in general).

Tomcat supports JAAS auth and provides a sample LoginModule based on the simple clear-text xml file. Like most other apps using auth, tomcat also have direct modules to authenticate against DB, LDAP/JNDI, files - but it will never cover the same range of auth sources as PAM for example ( http://www.kernel.org/pub/linux/libs/pam/modules.html ).

JAAS has few big problems - it is quite complex, it lacks modules and it lacks users. A benefit of using a tomcat-specific module is that it can be better optimized for the target environment. The only reason to use it would be to use a PAM auth source, there is now a JAAS-PAM implementation http://jaas-pam.sourceforge.net/ - seems very good, LGPL, uses JNI to interface with PAM.

The default JAAS modules from Sun seem quite useless - they can authenticate the current user, not much more. The JDNI module is probably usable, but the tomcat JNDI source seems more customizable and simpler.

Another option that wraps PAM is SysAuth
(GPL2), it defines it's own simpler API, it could be wrapped in JAAS or
in a tomcat module. Due to license and the fact that jaas-pam exists -
probably not worth the effort. Another dead end is ShadowJAAS - it supports unix
user/password authentication, by parsing passwd/shadow files in a SUID
root file.

JMX names

2006-05-11T11:28:00.000-07:00

Sun's advice http://java.sun.com/products/JavaManagement/best-practices.html

Allways have type=
if singleton ( or one instance per domain ) - no other key
otherwise: add name=
for grouping, add group=
j2eeType/jsr77 - they kind of agree it's a messs - I think
they do actually define a 'containment scheme', using type=Server.Application.WebModule,.. and Server=, Application=, etc. Not quite JSR77 - but close enough., and it makes more sense.
of course - an easier solution would be to just use unix-like names name=//servername/appname/webname,

On mbeans, they advise:

use standard MBeans - and use the interface with newProxyInstance. Not sure I agree with this one, if you want this kind of programmatic access use RMI/corba/etc if out of process, and the object directly if you are in process - you still have coupling and dependency, but no need for the JMX layer, which is not designed as RPC and is more inefficient than direct calls.
advice against DynamicMBeans - instead extend StandardMBean. I strongly disagree with this one.
On model mbeans, the correctly mention that they are hard to use by themself. The fact that they can't have interfaces is false AFAIK, you can define the interfaces if you want and the proxy will be generated, you can construct a dynamic proxy for anything if you want to write the interface. There is a decoupling since the implementation doesn't have to implement the method, but this can happen in any case if one side changes attributes/methods. See the above point on why I think dynamic proxies for JMX are a convoluted and bad idea.
recommend using OpenMbeans - good idea, and avoiding RMI-specific features like downloading classes.

As usual for any 'best practice' document - don't believe all they say, ask first what 'practice' they had and how many applications they developed or considered before finding the 'best', and how they relate to your use case.

Cleaning a firefox profile

2006-05-08T10:07:00.000-07:00

http://robert.accettura.com/archives/2006/05/03/cleaning-a-firefox-profile/

JamVM -- A compact Java Virtual Machine

2005-11-22T10:38:00.000-08:00

JamVM - impressive VM, runs tomcat without problems, even eclipse works. All in less than 1/2 M. Speed is decent for simple use. And it supports ARM - so I can play with java and tomcat on my toys.

Dashboard/konfabulator for Linux and firefox

2005-10-07T13:48:00.001-07:00

Dashboard/konfabulator for Linux and firefox: "The 'killer feature' in Dashboard and konfabulator is (IMO) the ability to integrate a web-like interface with the OS. This opens the way for a lot of ideas in making Linux easier to use - for 'regular users' but also for advanced users who feel more comfortable using the browser than typing ( and remembering ) complex command lines.

The implementation for firefox of a 'system/exec' feature similar with dashboard and konfabulator is not trivial, but not that complex. As I mentioned in a previous post, the async execution is the tricky part, but it has a reasonably straight solution. I'll try to find a server and post the sources - I'm sure there are better implementations using the event queue, but it works well enough for me.
Now the remaining part is dealing with installing and running 'widgets' in firefox - and exactly emulating the interface. I'm not expecting Dashboard widgets to work unmodified, but with small changes.Â Konfabulator has an simpler interface, but it's not HTML-like, I'll only see if I can implement a similar API for simpler transition.

This has been a very interesting mini-project for me - I found a lot about how firefox works, and I hope it'll serve it's purpose and I'll be able to reduce my use of CLI and have a nicer interface for the linux commands I use. Even if some already have"

A different implementation for commons-logging

2005-10-07T13:48:00.000-07:00

Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.Â  It is also one of the not-so-good APIs or implementations.

The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.

An alternative - that will work better in most cases - is to write a specific commons-logging implementation forÂ  eachÂ  backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.

The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic">A different implementation for commons-logging: "Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.Â It is also one of the not-so-good APIs or implementations.

The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.

An alternative - that will work better in most cases - is to write a specific commons-logging implementation forÂ eachÂ backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.

The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic"