yOn Sat, 31 Mar 2001, Craig R. McClanahan wrote:
> On 31 Mar 2001 [EMAIL PROTECTED] wrote:
>
> > After all the generated code depends anyway on the details of the jasper
> > runtime - it extends jasper.runtime.HttpJspBase.
>
> Don't forget that you cannot make this assumption universally. The page
> author can use the <%@ page extends="com.mycompany.MyClass" %> to define
> their own superclass, so the generated code (at least in that case) needs
> to deal with not being a subclass of HttpJspBase.
No, what I meant was the jasper-generated servlet depends on runtime ( in most
of the cases, explicitely by the extend runtime.HttpJspBase, but also
implicitely ).
In theory it would be nice to use JspC to compile a JSP to a servlet,
deploy the servlet on a different container and have it run happily.
This doesn't work right now - but can be done ( and it's not very hard
). I looked a bit into this - and one thing I'm certain of is that we
can't do that by trying to generate a serf-contained servlet that has no
external dependencies ( or it would be to ugly/slow).
But it can be done by clearly separating all runtime dependencies and
providing a way to include them in the war. The intialization can also be
tweeked ( to do the JspFactoryImpl init ).
How usefull would that be - I don't know. It would allow a portable
pre-compiled WAR ( the current is dependent on having jasper, you can't
deploy it in a different container ).
I'm also interested in small-footprint configurations of tomcat - with
only the minimal stuff and a form of pre-compiled WAR ( all JSPs compiled,
web.xml pre-parsed so no parser would be required at runtime, the classes
and libs re-packaged in a more efficient form, etc) - but of course
jasper needs to be refactored first (since it's the hardest part in
making this happen ).
Costin
