Home/ Questions/Q 3218140
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T15:29:35+00:00

I know ‘normal’ Java, but am new to the world of servlets, containers etc.

  • 0

I know ‘normal’ Java, but am new to the world of servlets, containers etc. Because of that I am not sure which approach is most sensible.

Situation: I have created a Servlet that receives information and stores it in a database. This database gets read by other applications.

Now what I need is an application that receives the exact same information and stores it in the same database. However this new application needs to pull this information from another server (I’ll be using httpClient for this) instead of it being pushed to it. Both applications will co-exist.

For this new applications I see the following two options:

  1. Make a stand alone application. For this I can copy paste a lot of the existing back-end code, but I will need to make some modifications (the servlet container offers a context, easy database connection pooling etc.) Further I might need to use some wrapper so this can work like a proper daemon that I can start, but also gracefully stop/restart etc.

  2. Make the new application part of a Servlet. That is: just start a new Thread in the init() of the servlet that will run the new application. This would allow me to reuse all the backend code I already have, without needing to rewrite any of it. I only need to write the code that does the HTTP-GET requests to the other server. With this approach it will also be easier to start and stop the service, because I can use the Servlet container for that.

Some info about the project: the backend code that parses and writes the data to the database has a few threads, but is not very complicated. Writing the code for the original servlet was about one week of work. With the existing code base I feel this new application should probably be 1, 2 days of work max.

The way I see it option 2 is easier. But it feels a bit like I would ‘abuse’ servlets.
So my question is: Aren’t servlets for applications that should handle requests, instead of applications that make request? Are there some huge drawbacks I don’t see here? Which option would make most sense?

tl;dr: Can I write an application that doesn’t serve requests as a Servlet?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Servlet containers are thread-managed environments. In general, don’t start your own threads in a servlet, or bad things can happen… starting and stopping the application context, for example – the appserver doesn’t know about the threads you might have started so won’t stop them with your app… (More detail in this SO question)

    I would try to extract the logic I need from the servlet into classes that don’t depend on the Servlet API, and redesign the servlet to make use of these classes. (Refactoring). The servlet API, as you note, is all about receiving requests and sending responses.

    I can re-use the logic in my new non-servlet classes anywhere I like, including a non-servlet part of the application that polls out pull that info.

    • 0