Java Application/Thread Server

Question

I am looking for something very close to an application server with these features:

• it should handle a series of threads/daemons, allowing the user to start-stop-reload each one without affecting the others
• it should keep libraries separated between different threads/daemons
• it should allow to share some libraries

Currently we have some legacy code reinventing the wheel... and not a perflectly round-shaped one at that! I thought to use Tomcat, but I don't need a web server, except maybe for the simple backoffice user interface (/manager/html).

Any suggestion? Is there a non-web application server, or is there a better alternative to Tomcat (more lightweight, for example, or easier to configure)? Thanks in advance.

Answer 1

You could consider Spring dmServer. It's a rather non-traditional appserver, with a very lightweight OSGi core (the web container is optional, for example), but it gives you classloader isolation and basic container services. It's not a JavaEE container, but comes with plug-in modules that are.

You're stlll going to have to do a lot of work yourself, but the basics of dmServer are very sound.

Answer 2

Have you looked at OSGi ? You can load/unload bundles (basically .jar files with metadata) independently of each other, and optionally define dependencies between these (with a software lifecycle defined such that bundles are aware of other bundles being loaded/unloaded).

Answer 3

I have found the Jetty "contexts" concept very useful in handling applications (packaged as WAR's and with servlet context listeners), where the xml-file placed in contexts/ describe fully what you want to have started. When you remove the xml-file again, the thing described is stopped.

If you do not start a server connector you will just have a start-stop thing which sounds like what you are looking for.

Jetty can be made very small so the overhead is not bad.

Answer 4

No one stops you from sending binary and text data instead of HTML-pages using http protocol. That is whats servlets are for. So I would use the tomcat server.