When restructuring the code last month for more modularity, I moved each module into its own jar file, each loaded with its own ClassLoader. One of the modules used Google's gdata API, and moving the gdata jar files into the module caused the problem of the javax.activation framework not finding the handler for application/atom+xml documents. At first, I just kept the gdata jar files in the main classpath so that it would work, as I had a bunch of other things to work on.

When I got back to looking into it, I googled around a bit and discovered that I needed to call Thread.setContextClassLoader() to the module's ClassLoader (and then restore it after returning out), and that made it work.

Right now, it's pretty ugly, because I call Thread.setContextClassLoader() within the module using gdata, and that doesn't extend well to other modules. All calls to the module should be wrapped with Thread.setContextClassLoader(), so that the module doesn't have to worry about it. The cleanest way I see to do this without disturbing the existing code is to create a wrapper module object for each module, which is kind of gross. But now that I know about Thread.setContextClassLoader(), the next time I'm doing something similar, I'll accommodate it in the design.

Among the things involved with moving each module into its own jar file, I moved all the static images associated with the module from the web directory into the module jar file, and added a servlet to serve them up, including sending the "Last-Modified" header and honoring the "If-Modified-Since" header.

The modules are now pretty modular. Until six months ago, there was a file that had all of the modules (5 at the time) hard-coded into it. Until last month, the SNMP code had all the modules (9 at the time) hard-coded into it.