Using a Servlet for a non-servlet application

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 s开发者_如何学运维ome 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?

Don't copy and paste code.

Write a re-usable class/module which handles storing the information in the database which can be used by both 1) the servlet and 2) standalone code which retrieves information from a HttpClient.

This way the same piece of code handles the same logic - how to store the information in the database - whether the information in question is being pushed to a servlet or being fetched from a remote URL.

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.

You could use, but you shouldn't, it is a very poor design.

If you have two different ways to access your application (one through servlets and other as standalone), you should create at leats three classes:

• One class that does all the work relating database, etc.
• One servlet that calls the first class
• One stand alone class (or whatever) that calls the first class

In this way, you don't copy/paste, and you can reuse your code (even you can have a third way to call the class that do the heavy work

If you want to reuse code, have this code as part of a "Service" or "Business Logic" layer that will be used both by your servlet and non servlet application.

Package the code as a jar and use it in both applications.