tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Trollinger" <jaka...@trollingers.com>
Subject RE: [VOTE] Proposed jspc refactoring
Date Thu, 07 Nov 2002 19:23:36 GMT
I have to time to go through and fix all the options (including cleaning
up the code) but I would like to see what options are actually used (or
would like to be used if they work)

I also have no problems maintaining jscp as I use it a lot and have
customized it to do what I want.  

I would just like some direction to go with..

John

> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
> Sent: Thursday, November 07, 2002 1:39 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [VOTE] Proposed jspc refactoring
> 
> 
> 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>
> 


--
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