Re: [VOTE] Proposed jspc refactoring
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). ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot Note: Users may vote, but only committers have binding votes. Remy -- 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
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: mailto:tomcat-dev- [EMAIL PROTECTED] 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
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [VOTE] Proposed jspc refactoring
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: mailto:tomcat-dev- [EMAIL PROTECTED] 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
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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 jspc 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: 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 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). ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot 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: 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
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: 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 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 ? ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot Note: Users may vote, but only committers have binding votes. So I'm -1 on removing the options -- 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 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: ballot +1 [X] Remove the options -1 [ ] Do not remove the options /ballot I have look again in the code ;-) 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
ballot +1 [ ] Remove the options -1 [X] Do not remove the options /ballot 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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. ballot +1 [ ] Remove the options -1 [X] Do not remove the options /ballot 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
/fileset
fileset dir=${tomcat.home}/common/lib
include name=*.jar/
/fileset
pathelement location=${build.dir}/classes/
path refid=all_other_jars/
/classpath
/taskdef
jasper2 verbose=0
package=my.package
compile=true
validateXml=false
uriroot=${webapp.dir}
webXmlFragment=${build.dir}/generated_web.xml
outputDir=${build.dir}/src/my/package /
loadfile property=generated_web.xml
srcFile=${build.dir}/generated_web.xml /
replace file=${jspui.webapp.dir}/WEB-INF/web.xml
token=lt;!--GENERATED_JSPS--gt;
value=${generated_web.xml} /
javac destdir=${build.dir}/classes
optimize=off
debug=on
srcdir=${build.dir}/src
classpath refid='...' /
include name=my/package/** /
/javac
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).
ballot
+1 [ ] Remove the options
-1 [ ] Do not remove the options
/ballot
Note: Users may vote, but only committers have binding votes.
Remy
--
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
Costin Manolache wrote:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
/fileset
fileset dir=${tomcat.home}/common/lib
include name=*.jar/
/fileset
pathelement location=${build.dir}/classes/
path refid=all_other_jars/
/classpath
/taskdef
jasper2 verbose=0
package=my.package
compile=true
validateXml=false
uriroot=${webapp.dir}
webXmlFragment=${build.dir}/generated_web.xml
outputDir=${build.dir}/src/my/package /
loadfile property=generated_web.xml
srcFile=${build.dir}/generated_web.xml /
replace file=${jspui.webapp.dir}/WEB-INF/web.xml
token=lt;!--GENERATED_JSPS--gt;
value=${generated_web.xml} /
javac destdir=${build.dir}/classes
optimize=off
debug=on
srcdir=${build.dir}/src
classpath refid='...' /
include name=my/package/** /
/javac
I'm using a similar way with jspc from Tomcat 3.3.2-dev :
java classname=org.apache.jasper.JspC
classpath refid=jspc.classpath/
arg line=
-d ${build.dir}/src
-uriroot ${build.dir}/dst
-webinc ${build.dir}/dst/WEB-INF/jsp.xml
-webapp ${build.dir}/dst /
/java
javac srcdir=${build.dir}/src
destdir=${build.dir}/classes
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
excludes=bas*,status*
classpath refid=jsp.compile.classpath/
/javac
mkdir dir=${build.dir}/dst/WEB-INF/lib/
jar jarfile=${build.dir}/dst/WEB-INF/lib/${wname}-jsps-${jarext}.jar
basedir=${build.dir}/classes/
--
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
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
RE: [VOTE] Proposed jspc refactoring
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
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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: 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 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: 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 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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 ? ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot 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
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
Re: [VOTE] Proposed jspc refactoring
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 javac, 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 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
RE: [VOTE] Proposed jspc refactoring (how I use jspc)
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 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
Re: [VOTE] Proposed jspc refactoring
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 jspc 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: 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 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). ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
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). ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot Note: Users may vote, but only committers have binding votes. 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
