Hi there,
------
DISCLAIMER: This a Tomcat question, where the solution will likely require
some tinkering with the implementation. What I'm to do is probably a
non-standard use case. I think knowledge of the Tomcat internals is
required to answer this. I hope this question is appropriate for this list
-- if not I apologize in advance. Also, sorry for the length...
------
I'd like to be able to invoke a JSP on-demand from a Java class and redirect
the response output stream to a String. This could be used to dynamically
generate the body of an e-mail, for instance. The key difference is that
there isn't a *real* corresponding HTTP request or browser socket connection
which would trigger JSP compilation and execution.
I've come up with 3 potential solutions. Any input or comment on these from
this list is much appreciated.
------
SOLUTION 1: Connect to the Servlet Engine like a browser using a
URLConnection object and retrieve the response from there.
-> This solution is probably the most portable (across Servlet Engines) but
likely isn't the most performant.
------
SOLUTION 2: Using Tomcat Interceptors.
-> I don't know anything about these but would there be anyway to catch and
redirect the response using an Interceptor. I assume such a solution would
only work with Tomcat.
------
SOLUTION 3: A custom Interceptor Servlet with a custom Response object.
-> A custom method could be called on such a GenericServlet and these
servlet would include the body of the JSP using the
RequestDispatcher.include method. A custom Response object would output the
Writer stream to a String or StringBuffer.
I've attached some sample source code which outlines what I have in mind.
Could someone give me a reality check on whether this is even feasible or
advisable. Particularly with regard to rolling my own Response
implementation which redirects Writer to a String. Would this kind of
kludge cause any problems for Tomcat?
------
Any comments, help or suggestions that anyone can provide are much, much
appreciated. Also, I'd love to hear alternative solutions. Thanks so much.
Regards,
Sasha Haghani,
Toronto, Canada.