Hi,
Thank you all for the responses. In the end, the result does satisfy me that
much (non-portable and a huge web.xml are deal breakers for me). So I'm
going with an alternative route using tag handlers/files wich are very easy
to package and can pretty much do the same in a portable way. May be a RFE
for JEE6?
Regards
On Mon, Sep 15, 2008 at 7:15 PM, <glassfish_at_javadesktop.org> wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>