Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote:
> Glenn Nielsen wrote:
> > Remy Maucherat wrote:
> > [...]
> > I agree that JSPC needs to be simplified and that the webapp mode should
> > be retained.  But the webapp mode should allow for a war file to be
> > generated
> > which is self contained including the precompiled JSP classses.  And for
> > the
> > generated war to be able to run from the war file with no need to unpack
> > it.
>
> Why add this to JSPC? Isn't it already very easy to use external tools
> to create the WAR file (the jar command, ant's war task, etc)? I have
> no objections to cleaning up the JSPC code, but I would like it to
> stay focused on it's its main task: convert JSP source to servlet
> source. I have sometimes wished for automatic compilation of the servlet
> source to class files, but in the name of simplicity and separation of
> concerns, I think it's better handled by other tools.
>
In one way, it would be better to have the JSPC do the java compilation, 
because it can tell exactly what the environment is supposed to be. The 
libraries that are available, etc. It's reproduceable in ant, but it's not a 
terribly expensive option to maintain in jasper2, since it follows the same 
path as the runtime compiler.

> > Also I agree that this feature is a proprietary feature of Tomcat and we
> > should no longer try to generate a war that can be deployed in any
> > container.
>
> Why not? This works today (at least in TC 4.0.4) and I find it very
> handy to be able to create a JAR file for all my JSPs that I know I
> can deploy to any container along with the jasper-runtime.jar. If there
> are issues with this that I don't know about, please tell me. Otherwise
> I see no reason to remove this capability.
>
> If you can use JSPC to create the servlet source and web.xml fragments,
> it's easy to use other tools to compile the source and create a WAR with
> all other parts of the app (servlets, taglibs, web.xml, static stuff,
> etc.) and deploy it to Tomcat or any other container. As far as I can
> see, there's no need for a proprietary solution to get this to work.
>
>  > [...]
>
> Hans


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

It's better to look at it as a compiler. It's output happens to be java, but 
it acts a whole lot more like a compiler than a precompiler. Precompilers are 
usually more like macro preprocessors. 

On Friday 08 November 2002 07:05 am, John Trollinger wrote:
> I have to disagree with this, jspc is a pre compiler, not a webapp
> packager.
>
>
> John
>
> > I agree that JSPC needs to be simplified and that the webapp
> > mode should be retained.  But the webapp mode should allow
> > for a war file to be generated which is self contained
> > including the precompiled JSP classses.  And for the
> > generated war to be able to run from the war file with no
> > need to unpack it.
> >
> > Also I agree that this feature is a proprietary feature of
> > Tomcat and we should no longer try to generate a war that can
> > be deployed in any container.
> >
> > There may be a way to do this:
> >
> > Put the generated JSP class files in a /WEB-INF/jspwork/
> > directory.  This work directory would only be used by jasper
> > for loading jsp pages, the normal work directory would still
> > be used for all other things.
> >
> > Add the "jspwork" attribute to the DefaultContext and Context
> > config elements. This attribute would specify the directory
> > path within the war file to use for loading the JSP page
> > classes from by Jasper.
> >
> > This would allow JSPC to create a war file which was self
> > contained including the precompiled JSP page classes and be
> > runnable directly from the war or unpacked into a directory.
> >
> > +1 if we modify Tomcat & Jasper to support precompiled JSP
> > pages running
> > +from a
> > self contained war file.
> >
> > Regards,
> >
> > Glenn
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> >  [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Steve Downey]

I dislike this option immensely. It's entirely contrary to what JSPC is for. 
It's a tool for generating servlets from JSP that do not require the entire 
JSP machinery. It produces a web.xml file that maps each jsp page to the 
generated servlet. The generated servlets are portable between servlet 
engines. They can be compiled by a normal java compiler. In short, they are 
very much unlike the output in the work directory.

What you are proposing is the same as the precompile option on the URL. 
Here's a script that will do it for all compliant JSP engines
find  . -name '*jsp' -printf "http://`echo $HOSTNAME`/%P?jsp_precompile\n" \
 | xargs -n 1 lynx -head -source


On Thursday 07 November 2002 04:23 am, 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 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).
> - 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.
>
> 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).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
> - 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).
>
> 
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> 
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

Costin Manolache wrote:

Hans Bergsten wrote:



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


"CLI" as in ...? Sorry, I'm not familar with this acronym.



Command line interface. jspc.sh, main() and the argument processing.


Ah, I should have known ;-)


Just use the jspc task in ant. My understanding is that ant's 
 can also generate code for other  containers, so one 
extra benefit.

But why should we require Ant? Isn't it better to refactor the code
so that the CLI interface and the Ant task can use the same core,
just using different interfaces?


[...]

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


Not sure I follow. If you mean to do this in addition to fixing
JSPC (with the -webapp option), it's okay with me.



Basically add an execute() method and setters to Compiler, and 
calling jasper indirectly, using the ant task. 

Jasper will be a very large ant task. That means we could 
switch jasper versions ( or other jsp impl ), it could be used
in other containers or applications, etc.

Are you saying pretty much what I said above: a common core that can
be used both a an Ant task implementation and a CLI?


( well, I'm not volunteering for that - but I think it would
be a nice idea for 5.0 ).


I agree that this type of refactoring is better targetted for TC 5.
For TC 4.1.x I suggest we just fix what's broken. I still haven't
heard what _is_ broken, though. Can someone tell me? I'll start
running some test soon (this weekend, most likely) with TC 4.1.14
(or .15 if it's available by then) and see what I'll find.

> [...]

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

Glenn Nielsen wrote:

Remy Maucherat wrote:
[...]
I agree that JSPC needs to be simplified and that the webapp mode should
be retained.  But the webapp mode should allow for a war file to be 
generated
which is self contained including the precompiled JSP classses.  And for 
the
generated war to be able to run from the war file with no need to unpack 
it.

Why add this to JSPC? Isn't it already very easy to use external tools
to create the WAR file (the jar command, ant's war task, etc)? I have
no objections to cleaning up the JSPC code, but I would like it to
stay focused on it's its main task: convert JSP source to servlet
source. I have sometimes wished for automatic compilation of the servlet
source to class files, but in the name of simplicity and separation of
concerns, I think it's better handled by other tools.


Also I agree that this feature is a proprietary feature of Tomcat and we
should no longer try to generate a war that can be deployed in any 
container.

Why not? This works today (at least in TC 4.0.4) and I find it very
handy to be able to create a JAR file for all my JSPs that I know I
can deploy to any container along with the jasper-runtime.jar. If there
are issues with this that I don't know about, please tell me. Otherwise
I see no reason to remove this capability.

If you can use JSPC to create the servlet source and web.xml fragments,
it's easy to use other tools to compile the source and create a WAR with
all other parts of the app (servlets, taglibs, web.xml, static stuff,
etc.) and deploy it to Tomcat or any other container. As far as I can
see, there's no need for a proprietary solution to get this to work.

> [...]

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[John Trollinger]

I have to disagree with this, jspc is a pre compiler, not a webapp
packager.


John

> I agree that JSPC needs to be simplified and that the webapp 
> mode should be retained.  But the webapp mode should allow 
> for a war file to be generated which is self contained 
> including the precompiled JSP classses.  And for the 
> generated war to be able to run from the war file with no 
> need to unpack it.
> 
> Also I agree that this feature is a proprietary feature of 
> Tomcat and we should no longer try to generate a war that can 
> be deployed in any container.
> 
> There may be a way to do this:
> 
> Put the generated JSP class files in a /WEB-INF/jspwork/ 
> directory.  This work directory would only be used by jasper 
> for loading jsp pages, the normal work directory would still 
> be used for all other things.
> 
> Add the "jspwork" attribute to the DefaultContext and Context 
> config elements. This attribute would specify the directory 
> path within the war file to use for loading the JSP page 
> classes from by Jasper.
> 
> This would allow JSPC to create a war file which was self 
> contained including the precompiled JSP page classes and be 
> runnable directly from the war or unpacked into a directory.
> 
> +1 if we modify Tomcat & Jasper to support precompiled JSP 
> pages running 
> +from a
> self contained war file.
> 
> Regards,
> 
> Glenn
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Jeanfrancois Arcand]

I am +1 of refactoring the code and do something less "overly complex". 
I just have a look at the code and start speaking french. ;-)

I can help if needed.

-- Jeanfrancois

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

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).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate 
process.
- 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).


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Glenn Nielsen]

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

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).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.
- 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).


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.

Remy


I agree that JSPC needs to be simplified and that the webapp mode should
be retained.  But the webapp mode should allow for a war file to be generated
which is self contained including the precompiled JSP classses.  And for the
generated war to be able to run from the war file with no need to unpack it.

Also I agree that this feature is a proprietary feature of Tomcat and we
should no longer try to generate a war that can be deployed in any container.

There may be a way to do this:

Put the generated JSP class files in a /WEB-INF/jspwork/ directory.  This work
directory would only be used by jasper for loading jsp pages, the normal work
directory would still be used for all other things.

Add the "jspwork" attribute to the DefaultContext and Context config elements.
This attribute would specify the directory path within the war file to use for
loading the JSP page classes from by Jasper.

This would allow JSPC to create a war file which was self contained including
the precompiled JSP page classes and be runnable directly from the war or
unpacked into a directory.

+1 if we modify Tomcat & Jasper to support precompiled JSP pages running from a
self contained war file.

Regards,

Glenn




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

Hans Bergsten wrote:

>> Removing the CLI and keeping the basic functionality seems like
>> a good idea.
> 
> "CLI" as in ...? Sorry, I'm not familar with this acronym.

Command line interface. jspc.sh, main() and the argument processing.

Just use the jspc task in ant. My understanding is that ant's 
 can also generate code for other  containers, so one 
extra benefit.

And if jspc becomes first-class - we'll stop the 
nightly gump test failures for ant :-) ( JSPC is 
actually tested by gump - part of ant tests ).

( there are failures - but it seems they happen only
in gump env, and I wasn't yet able to fix them ).

>> 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'.
> 
> Not sure I follow. If you mean to do this in addition to fixing
> JSPC (with the -webapp option), it's okay with me.

Basically add an execute() method and setters to Compiler, and 
calling jasper indirectly, using the ant task. 

Jasper will be a very large ant task. That means we could 
switch jasper versions ( or other jsp impl ), it could be used
in other containers or applications, etc.

( well, I'm not volunteering for that - but I think it would
be a nice idea for 5.0 ).


BTW, a separate issue would be extending the JMX support
to jasper. We use JMX mostly for configuration, but that's
only a small part of what can be done. We can extract 
informations or control jasper at runtime ( recompile, set
jikes, etc ). And jasper would be even easier to embed.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring (how I use jspc)

[Sean Reilly]

For what it's worth, here's how I benefit from jspc on a regular basis.

I'm one of the principal developers of a fairly high-traffic site powered by tomcat 
4.1.12.
We use jspc for correctness checking as part of our compile cycle, for two reasons:

a)To enforce valid jsp tag use (required attributes present, etc)
b)We use a jstl validator to keep over-enthusiastic web developers from using 
scriptlets in jsp pages

Including jsp checking in the compile cycle (and inflicting bodily harm on developers 
who cvs commit without compiling ;-) is a big help in keeping code quality high.

It's been mentionied in this thread (I think by Remy), that
"Efficiency is not all that important here, since precomiplation is done before 
deployment"
I would respectfully disagree on this point.

Not including jsp compilation, our entire build cycle, from a stock tomcat zip to a 
running tomcat instance with deployed webapps (including all servlet compilation and 
source code style checking) takes about 35 seconds.
Using ant's incremental capabilities, a non-complete build often takes less than 10 
seconds.  I love that our developers can compile at the drop of a hat, and I encourage 
this as often as I can.

So to me, efficiency is very important; the faster, the better.  Right now, a jsp 
precompilation for 120 jsp pages (which we can put off until production deployment to 
organizational peculiarities) takes 54 seconds... longer than the rest of our build 
cycle put together.  I would love for jsp compile checking to be performed as part of 
a regular developer's build cycle, and the faster JspC gets, the easier that is.  
Also, we do use incremental jsp compiles on a regular basis.

Also, I would love to deploy precompiled jsps to production, but conformance to the 
jsp and servlet specs is important to us, so a servlet compliant way (as opposed to 
the "copying to the work directory" solution) would be a positive feature for us.

So to sum up, we jspc an entire webapp at a time, but love incremental compilation 
(which is the only reason I can think of that someone would need to only compile a 
single jsp), and the faster the process is, the better.

Thanks,
Sean

PS:  Also, if you're looking for an example of the kind of performance you can get 
from a tomcat-powered server (as many people in the user's list seem to be), we're 
probably a pretty good example.  We served 52,708 page views yesterday (of definitely 
non-static content) from two dual p3 800mhz boxes, and when cpu usage goes over 5% on 
either machine, we get seriously upset.

http://usediron.point2.com

Sean Reilly
Programmer, Point2 Technologies, Inc.
(306) 955-1855
[EMAIL PROTECTED]



-Original Message-
From: John Trollinger [mailto:jakarta@;trollingers.com]
Sent: Thursday, November 07, 2002 1:24 PM
To: 'Tomcat Developers List'
Subject: RE: [VOTE] Proposed jspc refactoring


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: [EMAIL PROTECTED]
> 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 , 
> 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 ma

RE: [VOTE] Proposed jspc refactoring

[John Trollinger]

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: [EMAIL PROTECTED]
> 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 , 
> 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 syst

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

Costin Manolache wrote:

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.

"CLI" as in ...? Sorry, I'm not familar with this acronym.


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.

Right, I agree.


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

Even though I see one advantage with including compilation to class
files in JSPC (simlicity, no need to set up Ant, which is not always
available in the web app developers environment), I wasn't aware of
the -compile option until this week (since it's not documented).
I'm okay with removing it and handle compilation in other ways.


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

Not sure I follow. If you mean to do this in addition to fixing
JSPC (with the -webapp option), it's okay with me.


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.

See above.

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

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 , 
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:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Craig R. McClanahan]

On Thu, 7 Nov 2002, Henri Gomez wrote:

> Date: Thu, 07 Nov 2002 12:43:45 +0100
> From: Henri Gomez <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] Proposed jspc refactoring
>
> 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 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).
> > - 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 would say that we're extensively JSPC in ant tasks to generate servlet
> (.java), compile via javac and then put all the classes in a .jar which
> will be included in the final .war (in lib) which include the jsp
> mapping generated by JSPC.
>
> With this methodology, we're sure that what we deploy on our production
> will works (no jsp compilation error on users browser), no time spent in
> compilation at runtime, easy deployement since the WAR alleady included
> everything.
>

An additional advantage for some folks is that you can run the resulting
webapp on a JRE instead of a JDK.

> So what did you means by classes which should be deployed in work
> directory ?
>
> > - 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).
>
> It's not my opinion, JSP are nothing more than servlet after all and
> why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?
>
> Also consider massive web hosting situation with many tomcats running
> the same WebApps (with differents settings and JVM owner).
>
> Having everything in a .war (ie data + precompiled jsp in .class or
> .jar) make life easier for web admins since upgrading a version is just
> to replace a .war by a new one.
>
> With your proposed solution, they will have update the war, clean the
> work directory (by hand ?) and move the new classes in the work
> directory. Also did Manager/Admin will be updated for such task ?
>
> > 
> > +1 [ ] Remove the options
> > -1 [ ] Do not remove the options
> > 
> >
> > Note: Users may vote, but only committers have binding votes.
>
> So I'm -1 on removing the options
>
>

I'm -1 on removing the options unless they are replaced with equivalent
functionality that *does* work correctly and *is* maintained.  (Basically,
this is J-F's "do not remove and fix" option.

Craig


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

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

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
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

Remy Maucherat wrote:

> Costin Manolache wrote:
> 
>> To clarify - I agree jspc has a lot of broken options and
>> features. My use case is:
>>
>> Removing the CLI or any other options is fine for me. I don't need
>> jspc to compile or do any fancy thing - just compile JSPs to servlets
>> and generate the web.xml fragment.
> 
> 
> Actually, I don't care about any use case of jspc (which is good as it's
> broken).
> I was just trying to help out fix bugs, and thought it would be better
> to try to provide user friendly tools (instead of bloated and broken
> ones). I'll focus on some other area of the code then.

I do care about this use case, and I'm pretty sure it's not broken.

I have no problem with deprecating the other features and CLI - 
if nobody is maintaining them it would be better to cut them. But
I use this feature ( and intend to fix it if it brakes )

 
> BTW, no matter how I look at it, the practice of generating servlets
> seems really ugly to me (of course, there are so many ugly things about
> JSPs, I guess it's only one of them).

:-) 

It's not that bad -  generating servlets is one of the things I like 
in jsp.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

Another big advantage of using JSP -> servlet is that you didn't have
security problems of code exposure ;)




Hey, stop making fun of me, and get back to work ;-)


Oui patron ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

Henri Gomez wrote:



> BTW, no matter how I look at it, the practice of generating servlets
> seems really ugly to me (of course, there are so many ugly things
> about JSPs, I guess it's only one of them).


Another big advantage of using JSP -> servlet is that you didn't have
security problems of code exposure ;)



Hey, stop making fun of me, and get back to work ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

BTW, no matter how I look at it, the practice of generating servlets 
seems really ugly to me (of course, there are so many ugly things about 
JSPs, I guess it's only one of them).

Another big advantage of using JSP -> servlet is that you didn't have
security problems of code exposure ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[Martin Algesten]

What about trying to argue for why an error page returns error code 200?

Martin

-Original Message-
From: Remy Maucherat [mailto:remm@;apache.org] 
Sent: 07 November 2002 16:10
To: Tomcat Developers List
Subject: Re: [VOTE] Proposed jspc refactoring


Costin Manolache wrote:

> To clarify - I agree jspc has a lot of broken options and features. My

> use case is:
>
> Removing the CLI or any other options is fine for me. I don't need 
> jspc to compile or do any fancy thing - just compile JSPs to servlets 
> and generate the web.xml fragment.


Actually, I don't care about any use case of jspc (which is good as it's

broken).
I was just trying to help out fix bugs, and thought it would be better 
to try to provide user friendly tools (instead of bloated and broken 
ones). I'll focus on some other area of the code then.

BTW, no matter how I look at it, the practice of generating servlets 
seems really ugly to me (of course, there are so many ugly things about 
JSPs, I guess it's only one of them).

Remy


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

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

Costin Manolache wrote:


To clarify - I agree jspc has a lot of broken options and
features. My use case is:

Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the web.xml fragment.



Actually, I don't care about any use case of jspc (which is good as it's 
broken).
I was just trying to help out fix bugs, and thought it would be better 
to try to provide user friendly tools (instead of bloated and broken 
ones). I'll focus on some other area of the code then.

BTW, no matter how I look at it, the practice of generating servlets 
seems really ugly to me (of course, there are so many ugly things about 
JSPs, I guess it's only one of them).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

Costin Manolache wrote:

To clarify - I agree jspc has a lot of broken options and
features. My use case is:


  


  


  



  








   
  
  



I'm using a similar way with jspc from Tomcat 3.3.2-dev :

	
		
		
	


   
	



	





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

To clarify - I agree jspc has a lot of broken options and
features. My use case is:


  


  


  



  








   
  
  



Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the web.xml fragment.

Costin

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 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).
> - 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.
> 
> 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).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - 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).
> 
> 
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> 
> 
> Note: Users may vote, but only committers have binding votes.
> 
> Remy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

As someone who is actually using jspc ...


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

-1

I actually need real java classes, with a package name I can customize 
and deployed in an arbitrary directory  (outside tomcat tree).


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

Not sure which 'webapp mode', but generating the web.xml fragment is
an essential feature and 100% standard - it translates JSPs to servlets
and generates the web.xml declarations. After the operation you'll have
very servlets in a standard web.xml.

As for jasper runtime - it can be included in the webapp ( just like any
library ). AFAIK the runtime doesn't depend on tomcat.

> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).

I need precompilation at build time - the distributed .war will have only
servlets.

> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - 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).

Again, I must -1 this too.



> 
> 
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> 

I agree jspc needs some refactoring - and only the 'webapp' mode should
be preserved, but I think my use case is valid and should be preserved.

At the moment I only use jasper inside ant - so removing the CLI completely,
removing the javac compilation and so on would be fine ( for me ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[John Trollinger]

> 
> 
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> 

I think some of the options are useless and should go away, but some of
them are (or could be usefull if they worked).

Right now I don't think jspc meets many peoples needs, maybe it is time
to find out the needs of users for jspc and implement those correctly.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[jean-frederic clere]

Remy Maucherat wrote:

jean-frederic clere wrote:




The problem is that keeping the options is where the work has to be 
done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.



I don't really agree, as I think it's just too complex for users right 
now (too many useless options).

Ok, my vote is:

+1 [X] Remove the options
-1 [ ] Do not remove the options


I have look again in the code ;-)





Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

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 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).
- 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 would say that we're extensively JSPC in ant tasks to generate servlet 
(.java), compile via javac and then put all the classes in a .jar which
will be included in the final .war (in lib) which include the jsp 
mapping generated by JSPC.

With this methodology, we're sure that what we deploy on our production
will works (no jsp compilation error on users browser), no time spent in
compilation at runtime, easy deployement since the WAR alleady included
everything.

So what did you means by classes which should be deployed in work 
directory ?

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

It's not my opinion, JSP are nothing more than servlet after all and
why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?

Also consider massive web hosting situation with many tomcats running
the same WebApps (with differents settings and JVM owner).

Having everything in a .war (ie data + precompiled jsp in .class or 
.jar) make life easier for web admins since upgrading a version is just
to replace a .war by a new one.

With your proposed solution, they will have update the war, clean the
work directory (by hand ?) and move the new classes in the work 
directory. Also did Manager/Admin will be updated for such task ?


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.


So I'm -1 on removing the options



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

jean-frederic clere wrote:




The problem is that keeping the options is where the work has to be 
done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.


I don't really agree, as I think it's just too complex for users right 
now (too many useless options).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[jean-frederic clere]

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

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).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.
- 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).


+1 [ ] Remove the options
-1 [ ] Do not remove the options



The problem is that keeping the options is where the work has to be done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.



Note: Users may vote, but only committers have binding votes.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: