In theory this can be done.
In practice it's more difficult.
In theory, JSPs are simply servlets, and the JSP compiler translates the JSP page in to "plain ol' Java", which can then be compiled in to classes and packaged however you want.
This is, in fact, what the JSP compilers do.
Then, you simply need a web.xml that maps JSP urls to the actual classes. This is tedious, but doable. The major complaint against many of the JSP precompilers is that they actually skip that step and leave it to you (which is aggravating). Nonetheless, it's all doable and practical.
The dark side, however, is that although these generated classes are simply Servlets, and can be jarred up like any other class, they may have portability issues.
Specifically, when a JSP compiler creates a JSP Servlet, they inevitably extend some container specific classes.
For example, in Glassfish, a JSP Servlet has the following signature:
[code]
public final class MyJSPPageTest_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent
[/code]
This raises the portability concern. Although your JSPs are now packaged up as JARs, they have a container dependency. This is what will limit your portability.
Take the sample above. You'll notice it depends on "org.apache.*" classes, since Tomcat is an ancestor of the current Servlet and JSP implementation within Glassfish. Now, I don't know quite what version of Tomcat they started with in Glassfish, but even if I did, there's no guarantee that they actually are still compatible with that implementation. So, even though a Glassfish JSP may well rely on original Tomcat classes, there's no guarantee that a JSP created in Glassfish will work with ANY version of Tomcat, much less something like Weblogic or Websphere, or any other container. It might work with Tomcat, there's just no guarantee.
That's not to say all is lost. It may well be possible (and even practical) to include the dependencies within your application. At least with Glassfish, these container dependencies are actually redistributable. But you have to be aware that you're going to be pulling on a lose thread of a sweater if you try this. As you keep pulling to satisfy the dependencies, you don't quite know in advance how much of the entire sweater will unravel. It may just be the JSP runtime, but it may well be something else.
The other thing you can do, hurray for open source, is manage that little runtime environment yourself. After all, a JSP IS just a servlet. The details that make it really "JSP-ey" are it's ability to recompile on the fly after a page change, which is certainly something that is meaningless to you. So it may be practical to "fork" the surrounding JSP page runtime and remove any container dependencies (particularly those related to recompiling) for your project.
Finally, the Apache Jasper runtime is a JSP compiler and runtime. It's used in Tomcat, Jetty, it may be used in Glassfish (it was obviously the basis for the current implementation). It's pretty standalone, and you may well be able to simply incorporate it wholesale (i.e. as just jar files) in to your application. Then the combination of your JSP jars and the Jasper jars would be portable together.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=299395