Fire off an internal ServletRequest in Tomcat

Question

I am using Quartz to schedule background tasks for a web application. Some of these tasks just fire off requests against the same web application.

I want to avoid depending on any kind of network settings (for example a request with my own domain name might not be routed properly if made from within the data center). Is there a Java API to fire off a ServletRequest and have it handled by Tomcat internally (without any actual HTTP involved)?

I still want to wrap the work into a Servlet request rather than calling the Java code for the background tasks directly, so that I can go back to regular HTTP request as a configuration option.

Tomcat-specific code is acceptable.

Answer 1

Interesting notion. There's certainly no standard API for this, and I don't think there's a published Tomcat-specific mechanism either.

What would be receiving the request? A servlet? JSP? Spring controller? Depending on that, and depending on what the target does, you may possibly be able to invoke the target directly, rather than routing it through the container.But if you have JSPs, a stack of filters, and other servlet intricacies, this likely isn't an option.

If on the offchance you're using Spring, then your Quartz job could just be wired up directly with the controller and it'd be easy as you like. Are you that lucky?

Answer 2

What do you want to get from that scheduled tasks? Standard web-server behavior is to get HTTP request and respond with particular data. I assume that your tasks don't need that, i.e. you want just to perform particular processing which codebase resides within the web-application.

If the assumption above is correct you can just decouple servlet/jsp logic from business-processing logic and call business-logic layer classes directly from your scheduled tasks.

Answer 3

Use URLConnection, or apache-commons httpclient with localhost / 127.0.0.1 - thus it will be routed properly.

Answer 4

The servlet code is having too much responsibilities. Refactor it to a plain vanilla Java class and let the task class access it (or the other way round, let it visit the task class). If necessary, make wisely use of the ServletContext.

If you elaborate a bit more about the actual problem and functional requirement for which you think that this is the solution, we may come up with much better suggestions.