I'm trying to solve a couple of problems, hopefully someone can help. JSP seems like a natural choice for doing things like generating XML (whether for consumption by a web browser or not). The XML generation process could be considered a mapping between an internal data format and some XML format compliant with a DTD specified by a third party. Considering this, say I actually want to do something with the XML afterwards besides returning it in an HTTP response. For instance, maybe I want to write it into a byte[] and pass it on to some message oriented middleware? To actually get ahold of this XML output stream, I have come up with a few options. The first option is to have a servlet/jsp open an http connection to its container, supplying the appropriate arguments for the requested JSP to generate the desired XML output. The integration between the two systems is triggered by a request to the servlet engine by a user's web browser, which then requests the generation of an XML file by making an http request back to the container. This is clunky, somewhat messy, and probably not a good idea from a resource standpoint. The second option is to somehow embed the JSP execution portion of Tomcat and feed it request/response objects that can be programmatically tied to whatever implementation of an output stream that I like. This way, my interface for accessing the XML output programmatically is not limited to an http request/response cycle, yet I can utilize the JSP engine for its templating strenghts and produce XML output outside of the scope of the http protocol. I also have a need to use a templating engine to perform some Java code generation. JSP again seems natural, but I have the exact same problem. I don't want my interface for requesting a Java source file generation be the http protocol. Has anyone done something like this? Any suggestions? Thanks for any help! -matt -- matthew c. mead mmead (at at at) goof (dot dot dot) com (you know what to do to email me) http://www.goof.com/~mmead/
