Can I mix Terracotta with custom classloaders?

Today's challenge is going to be an interesting one.  As I often do, I'm attempting to mix a couple ideas together to see if something really interesting comes out.  Here's the context: I'm looking at Terracotta Distributed Shared Object technology for a project I'm working on.  It is a really slick way for distributing objects between JVMs without having to implement any custom infrastructure classes -- POJOs all the way, baby.  The application will be using Spring to manage object instances as well as supporting Hibernate access.  The part of the project I'm working on is headless so I would like to use a bootstrap classloader to help keep the installation process simple.  I would also like to use the TDSO infrastructure to share a few key objects.  Mixing the two ideas, however,  is proving to be a challenge.  As you may have guessed, part of Terracotta's magic is done via classloading which means you have play by their rules.  In my case, I'm creating a brand new loader for my application and not using any Terracotta classes.  Specifically, I'm creating a new URLClassLoader and populating it with the JARs and directories I need to run my application.  When I use the launcher in conjunction with TDSO, I get the following error:

"java.lang.IllegalStateException: This classloader instance has not been registered (loader class:java.net.URLClassLoader)."

A bit of Googling turns up a few discussions that suggest either writing a Terracotta Integration Module (TIM) or casting my loader to a NamedClassLoader and calling the __tc_setClassLoaderName method might solve my problem.  Writing a TIM seems like a lot of work but that is what was done for other environments that use custom classloaders, such as Tomcat and Jetty.  I put in some reflection code just to see if the __tc_setClassLoaderName was even available and, as expected, it was not.  I'm guessing because I never told TDSO to share the URLClassLoader so it didn't work any of its byte code manipulation magic.  This is going to be a tough nut to crack but I'm not ready to give up just yet.

How can I manage my Java program's classpath?

I ran into an interesting article that shows a solution to the problem of running incompatible classes within a single JVM. The idea is to keep the launching application's classpath small and clean and then use a custom classloader to load the application's various pieces. Using separate classloaders is exactly how most Java EE containers keep applications from seeing each other's classes. I think this technique, couple with a command socket is a great way to launch an application. It is very possible to use multiple loaders to run variants of the same application within the JVM and not have to rely on OSGi or Java EE and the associated complexity.  The technique is fairly simple to implement and helps to avoid those pesky ClassNotFound exceptions.

How can I control a headless Java program?

I ran into an interesting idea and will describe it here. The problem is that you have a headless, server type process running and you need a clean way to administer it. One idea is to create main() that starts a thread that actually runs the program. The main thread opens a socket and waits for commands. You can then send a "stop" command which halts the application thread and exits the main thread. I can see this tactic being a great way to start a non-web based Spring application. The application thread does the normal Spring context instantiation, making sure to have Spring register its shutdown hook, while the main thread just waits for a command. Since the command thread isn't going to be under load you don't have to pay any special attention to the listening code, such as using NIO or socket frameworks.