tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [VOTE] Proposed jspc refactoring
Date Thu, 07 Nov 2002 18:38:49 GMT
Remy has a point - the current code is not very clean, and doesn't
seem to be tested/maintained enough.

I use the ant tasks - and I have a feeling many other users of jspc
are doing the same. 

Removing the CLI and keeping the basic functionality seems like 
a good idea.

For example compiling a jsp page outside a webapp can't work
in all cases - if it has includes, etc it needs to resolve, it 
needs taglib definitions from WEB-INF, etc. I can't see any
good reason to keep it if it's half broken by definition.

Also - compiling the java files is the job of <javac>, 
and the mapping and web.xml fragment generation can be 
more easily done using only the ant tasks.

I would go even further - since we are already using ant to 
compile the java to .class, it may be a good idea to make the
.jsp->.java task 'first class'.

In any case - the task is supported ( at least by me, it seems Henri is 
using it as well ).
If there are people who want to support the CLI and the other 
options - then we can keep them, but if not - I think it's better
to remove them or mark as unsupported.

Costin 



Hans Bergsten wrote:

> Remy Maucherat wrote:
>> Hi,
>> 
>> jspc is IMO overly complex, with many features nobody knows how to use,
>> and nobody cares to test (hence sometimes some of them are randomly
>> broken during Jasper refactorings).
> 
> I will not formally vote on this, because I've been inactive in this
> project for so long I feel I need to familiarize myself with the
> current code base before I can exercise my voting priviledges. But I
> do have some comments, see below.
> 
>> I propose that:
>> - In Tomcat 5, all jspc options are removed, in favor of allowing only
>> the webapp mode (with its relevant options). This webapp mode would
>> generate code and classes which should be deployed in the work
>> directory, exactly the same as if they were dynamically compiled by
>> Jasper (which has the big advantage of using only one big operation mode
>> for everything). Single file mode is IMO useless (dynamic compilation
>> works fine).
> 
> I agree with you regading single file mode, but not with the rest.
> 
>> - In Tomcat 4.1, the options will stay in for compatibility, but the
>> usage help will be modified to be the same as Tomcat 5.
> 
> I'm not sure what you mean by this proposal. Are you saying that the
> TC 4.1.x version would have a usage message (documentation) that doesn't
> match its features? If so, why? If there will be differences between the
> TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
> base for each version, each with documentation that correctly reflects
> their features.
> 
>> It has to be noted that:
>> - The JSP runtime is now very efficient. The old webapp mode (with its
>> static web.xml) is a hack (and a 100% proprietary one at that).
> 
> Efficiency is not all that important here, since precomiplation is
> done before deployment (that's the whole idea, right ;-)
> 
> Not sure what you mean with "100% proprietary". The web.xml file (or
> fragment) that is generated is defined by the servlet spec.
> 
>> - Precompilation should only occur at webapp deployment time in the
>> general case (the generated code is closely tied to the Jasper runtime
>> release).
> 
> I don't agree. It's very handy to be able to generate a JAR file with
> all JSP pages for an application and deploy it to many different
> container instances (Tomcat or others, as long as jasper-runtime.jar
> is included). There are many users that want to keep the production
> environment as simple (and small in embedded systems, for instance) as
> possible, and deploying precompiled JSP pages lets me use a production
> environment without the JSP compiler and use JRE instead of the JDK.
> 
>> - Additional features could be added to the manager servlet to, for
>> example, cause precompilation of the deployed webapp in a separate
>> process.
> 
> That's a separate thing, more of a container feature than JSPC in my
> mind.
> 
>> - I am -1 to returning to the old "webapp" option behavior (ie, the
>> generated files should by default be deployed in the work directory, not
>> /WEB-INF/classes).
> 
> Why not discuss what the problems with the current options are, and
> try to find a solution instead? Like I've said, it's been a while since
> I was actively involved with Tomcat development, but I know that in
> Tomcat 4.0.4, JSPC seemed to work fine with all options available at
> the time. How did Jasper2 break things? If I understand what the main
> problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
> afraid I don't have enough cycles to get into Tomcat 5 at the moment).
> 
> Hans




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message