Headless java servlet?

Question

I've got a stand alone, headless, java server app that does a bunch of queue-based processing against a database that I'm thinking of migrating into a java app server. I've got plenty of back-end java experience and a bit of JSP, but not a lot of servlet experience.

It seems like the approach would be to just wrap my app into a servlet and have it deploy on startup (and make sure that it only one instance gets deployed).

Few questions:

1) Since my app doesn't have any HTTP (or other) request/response mechanism, would it be silly to implement a servlet that has no URL mappings? Looking at the API, would I just implement a GenericServlet and just leave the service() method empty?

2) Another portion of my java app opens/manages it's own network sockets (non-HTTP) to accept a stream of incoming data. I think it would take quite a bit of work to get it to fit into the servlet request/response model. Is it ok that a servlet opens/manages its own network sockets?

3) We also have a bunch of web apps (currently in coldfusion) that are not very well integrated with the java app (in that they can only communicate via the DB). We are looking at railo (another servlet) and I'm trying to figure out how easy it would be for the coldfusion/railo apps (running in the same app server) to communicate directly with each other. Maybe a web page that displays current runtime stats/metrics of the java engine, and eventually invoking some of the business logic in the java engine as well.

Thanks, Brian

Answer 1

1. Servlets are a generic mechanism that are not specifically tied to the HTTP world (despites the fact that HttpServlets are used in 99.999% of cases). You could subclass the Servlet class to implement, say, a MailServlet that would respond to mail events - but as far as I know, current webservers support only HTTP mappings.

2. Sockets belong to the Java EE world, and it is considered a Bad Thing to launch custom threads in this environment - and you most certainly would need to do that if you open sockets (for polling data, etc.)

Answer 2

If you don't want to intercept on HTTP requests, then just don't extend HttpServlet. This makes no sense. If you actually want to execute it as a "background task" on webapp's startup and stop it on webapp's shutdown, then just implement ServletContextListener accordingly.

public class Config implements ServletContextListener {

    private YourApp yourApp;

    public void contextInitialized(ServletContextEvent event) {
        yourApp = new YourApp();
        yourApp.start();
    }

    public void contextDestroyed(ServletContextEvent event) {
        yourApp.stop();
    }

}

which you can register in web.xml as follows:

<listener>
    <listener-class>com.example.Config</listener-class>
</listener>

If YourApp actually doesn't fire the task in a separate thread, then you'll need to wrap it up in a Runnable and execute it using ExecutorService. E.g.

public class Config implements ServletContextListener {

    private ExecutorService executor;

    public void contextInitialized(ServletContextEvent event) {
        executor = Executors.newSingleThreadExecutor();
        executor.submit(new YourApp()); // YourApp should implement Runnable.
    }

    public void contextDestroyed(ServletContextEvent event) {
        executor.shutdown();
    }

}

If, after all, your webapp does nothing else than that, then I question the value of running it in a servletcontainer. Instead rather just run it as a standalone Java application using the main() method.