Is it possible to call a JSP outside of the confines of a Request/Response? How does one do that? We have a backend system that is regenerating small HTML chunks/nuggets. These nuggets are mostly things like dropdowns or other page elements. I would like the front end people able to create these easily (i.e. without deep knowledge of JAVA), and JSP seems like an obvious choice. The problem arises when my Thread is going through its regen loop, and it comes across one of these files that need to be updated. I would like the ability to "invoke" the JSP and get a return string, which I then write to a file, mark for future regeneration, etc. The regeneration and that loop isn't the problem. I just simply don't know how to "invoke" a JSP from within backend code- i.e. I do not have an HTTPServletRequest or Response at that time and do not want to create one if possible. I simply want to say "invoke the JSP with these parameters, and give me back the HTML string". I don't even know if "invoke" is the right terminology- hence the quotes. If I'm stuck, I'll probably create a small pool of Request/Response Pairs that won't interfere with the request handling aspect that's going on in the Servlet side of the application. Any ideas? Thanks in advance for yor input.
JSPs exist only within the context of a JSP engine which exists inside a Servlet container which exists inside a web application server where it is called on receiving a request for a URI registered for it. No, you will need a request/response cycle. But why not wrap the backend code in some custom tags? Those can then be used by your web people easily, all they'll need is a manual describing parameters, and the line to add to their JSPs to load the appropriate TLD. If you also give them JSTL to play (you should, it's really nice) with there's no need for any scriptlet code anywhere.
scott p laplante
Joined: Mar 12, 2004
Thanks for the response. Unfortunate info, but expected. What other options might i have? The basic requirements are: -- inherently not end-user request-based (the point of generating the HTML chunks in the backend is to avoid end users taking the generation hit, which can be large at times) -- mix of object-access code and HTML tags (similar to JSP, we'll have HTML tags interspersed with getters on the object(s) passed in) -- as easily as possible to generate and maintain (would like to avoid writing individual classes with stringBuffer.append(...) to write characters to the resultString, as creation/updates will be done by front-end folk)
Some ideas I've entertained, to give you an idea of what I'm thinking: -- write an HTML-parser using regexp and use reflection to run the object getters. (would be hard AND certainly re-inventing the wheel) -- send an HTTP request through the loopback device, sending objects as request parameters (undesireable since it'll have to be throttled and/or would be unnecessarily clogging the request pool) -- set up a mini-servlet engine on the side to handle these requests apart from tomcat (harder to maintain, memory hog, another possible bottleneck...)
any ideas or advice? the main problem is that some of these HTML chunks take non-neglible time to generate (which is why we're re-genning them without user-prompts), and they can be regenerated when loads are low, so as to tread as lightly as possible. i appreciate any ideas or information or leads. thanks very much.
It is a very bad idea to generate the html code from the backend. Oracle has an API to generate jsps, but it is really not the best way to go about it. I can go into more details if you are interested. The best way to go about it is to query the database, cache the result for as long as necessary, then build the form elements based on the cached result.
SCJP, SCWCD, SCBCD, IBM CSD WebSphere v5, <br />A+, MCP 2000 and 2000 server, CST, and few incompleted certification tracks.<br /> <br />Ivory Coast<br /> <br />Analyze your web Request/Response @ <a href="http://webtools.servehttp.com" target="_blank" rel="nofollow">http://webtools.servehttp.com</a> down for a while...
scott p laplante
Joined: Mar 12, 2004
We are not "generating the html code from the backend". The source of our HTML tags and content is still front end code. What we ARE trying to do is to pre/re-generate HTML blocks (from JSP) that take a long time or are resource-intensive. Imagine a JSP file which requests an XML from a very slow server and returns the xmlString. If we did this based on a user-request, the user would wait a very long time to see the page. Instead, we are pre-fetching or pre-generating this XML block and caching it for a period of time. When the cache expires, we still do not want this hit to be taken by a user. So we have, basically, a backend Thread that loops through and tries to re-generate the XML file, again caching it for a period of time. The problem we are up against is that we cannot seem to invoke the JSP without already being within an HTTPServletRequest/Response cycle(see my comments above). My example was fake, by the way, but appropriate to demonstrate the problem I am trying to tackle- i.e. not exposing long generation times to our end users. User-requests should be done very fast. As an aside, when regenerating, we ARE running the regen request through the loopback device (for throttling purposes), but by the time we've figured out that it requires JSP to be generated (instead of, say XSL or XPath), we are well into the backend code and do not (nor should not) know what an HTTPServletRequest/Response is.