cvs commit: jakarta-tomcat-4.0 gump.xml
rubys 2002/08/03 03:54:06 Modified:.gump.xml Log: tomcat-util needed by jakarta-cactus-sample-servlet-13 Revision ChangesPath 1.9 +1 -1 jakarta-tomcat-4.0/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/gump.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- gump.xml 2 Aug 2002 13:49:58 - 1.8 +++ gump.xml 3 Aug 2002 10:54:06 - 1.9 @@ -94,7 +94,7 @@ option project=jakarta-avalon/ option project=jakarta-avalon-phoenix/ depend project=jakarta-tomcat-coyote/ -depend project=jakarta-tomcat-util/ +depend project=jakarta-tomcat-util runtime=true/ depend project=jakarta-servletapi-4/ depend project=jakarta-regexp/ option project=junit / -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat gump.xml
rubys 2002/08/03 05:45:15 Modified:.gump.xml Log: Cactus needs org.apache.tomcat.startup.Main... Revision ChangesPath 1.10 +2 -0 jakarta-tomcat/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat/gump.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- gump.xml 31 Jul 2002 05:37:26 - 1.9 +++ gump.xml 3 Aug 2002 12:45:15 - 1.10 @@ -27,7 +27,9 @@ depend project=jsse/ depend project=jmx/ work nested=build/tomcat/classes/ + home nested=build/tomcat/ +jar name=tomcat.jar/ jar name=lib/common/tomcat_core.jar/ jar name=lib/common/core_util.jar/ jar name=lib/container/container_util.jar/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] launcher/deamon
Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] Components / optional / compat
Proposal: Let's split 5.0 code into several directories ( components - like in commons ). 'catalina' will remain the 'core' interfaces and required features ( i.e. the minimal stuff ). 'naming' for jndi stuff 'compat' for all the interfaces from 4.0 that we deprecate but preserve for backward compat ( Logger ? etc ). 'modules' for optional things. Launchers, specific realms, etc could go here. On a separate issue, there are few things that may be very usefull independent of tomcat, and even if we don't move them to commons we should try to make them independently useable: - naming - users - class loading - catalina has one of the most advanced loaders Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Costin, I plan to post a patch to Ant for the enhanced data types (e.g. syspropertyset) and the conditional java task elements (e.g. sysproperty with if and unless attributes) back to Ant as I think they would really enhance the Ant java task. I just haven't had time yet but I will do so eventually. As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me explain why we put it in the first place: 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. If the community chooses not to use the launcher, feel free to remove it from the Tomcat 5 build and restore the old scripts. Patrick Costin Manolache wrote: Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Patrick, the idea is great - the implementations details are a bit problematic :-) On Sat, 03 Aug 2002 09:04:18 -0700, Patrick Luby wrote: Costin, I plan to post a patch to Ant for the enhanced data types (e.g. syspropertyset) and the conditional java task elements (e.g. sysproperty with if and unless attributes) back to Ant as I think they would really enhance the Ant java task. I just haven't had time yet but I will do so eventually. I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case the current ant ( even 1.5 ) seems to have all the elements it needs to start tomcat ( cactus and anteater are doing it ). As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me I don't think the 'community' wants something - and I must admit I had very little idea of this going on. If _you_ think this is a good idea - you must make a more explicit proposal, make sure everyone is aware of this, eventually have a vote and add some documentation ( a spec / the proposal / whatever ). I think it is an excelent idea and I would love to see it happen - but I don't like the implementation details I'm seeing so far. Depending on commons-sandbox and reinventing things that are already in ant, or doing things slightly differently than ant is doing is not very good. You can add the tasks that you need in tomcat, and 'antlib' is very likely to happen for ant1.6 ( the current feeling is that ant optional tasks should be split ). 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). And also: 5. make tomcat startup easy to automate from ant ( all the test frameworks will benefit ) 6. use a well-known format ( path, etc ) to describe the env. 7. reuse open-source code instead of reinventing the wheel ( ant ). 8. Add extra features - like multiple profiles ( using different targets ), ability to easily execute 'pre/post' tasks ( like generating the apache config files ) And I can go on - there are many other benefits. Nobody is arguing ( at least not me ) on the benefits of the idea. From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. I think it adds quite a bit on both unix and windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. I disagree ( twice )- the bat scripts are not simple, and you _don't_ have to add dependencies to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. I partially agree - the scripts are well tuned and work, so there's no reason to drop them. At least in 3.3 we did a lot of simplifications - like 'guessing' tomcat.home, etc - so a lot of stuff can be removed. If the community chooses not to use the launcher, feel free to remove it from the Tomcat 5 build and restore the old scripts. I'm not the 'community' - but I agree with 'choosing' :-) Make a proposal, have a vote - that's the only way to know what the community chooses. Costin Patrick Costin Manolache wrote: Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Costin, Costin Manolache wrote: I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case the current ant ( even 1.5 ) seems to have all the elements it needs to start tomcat ( cactus and anteater are doing it ). Basically, commons-launcher classloads the ant.jar bundled with Tomcat 5 (Jasper2 also classloads Ant 1.5). commons-launcher is just a wrapper for bootstrapping Ant plus some custom tasks and data types. I don't use Ant's scripts because Ant' batch script suffers the same Windows problems as every other batch based program: 1. You can't run the application in the background (Ant's java task does a Process.waitFor() on all forks) 2. Ant must be launched with a DOS batch script that is subject to the same DOS shell flakiness as the old Tomcat scripts had (e.g. %0 sometimes does not contain a path, the for command sometimes cannot handle spaces in paths, environment variables cannot handle = characters in them, etc.) 3. Ant cannot be detached from a DOS shell I did not want to reinvent Ant. I merely wanted to use its XML structure. In essence, like Jasper2, I am embedding Ant in my tool. Isn't this what code reuse is all about? As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me I don't think the 'community' wants something - and I must admit I had very little idea of this going on. I mentioned the community because Bill Barker voiced some reservations about including commons-launcher. If _you_ think this is a good idea - you must make a more explicit proposal, make sure everyone is aware of this, eventually have a vote and add some documentation ( a spec / the proposal / whatever ). This was included in Remy's Tomcat 5 proposal. It was under an item, IIRC, entitled Tomcat 5 will use the Launcher used in Sun's JWSDP product. Since the Tomcat 5 proposal got approved, I assumed it was my responsibility to put the Launcher into Tomcat 5. I generally don't try to push features into Tomcat as I have very little spare time. I think it is an excelent idea and I would love to see it happen - but I don't like the implementation details I'm seeing so far. Depending on commons-sandbox and reinventing things that are already in ant, or doing things slightly differently than ant is doing is not very good. Again, I am not reinventing Ant. I am using Ant's functionality only as an embedded library. In fact, in the Sun JWSDP product, its Launcher did not use Ant at all and focused only on fixing the DOS problems and running with a DOS shell. The use of Ant was a nice way to expose the scripting of the tool instead of burying the scripting in Java code. You can add the tasks that you need in tomcat, and 'antlib' is very likely to happen for ant1.6 ( the current feeling is that ant optional tasks should be split ). 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). And also: 5. make tomcat startup easy to automate from ant ( all the test frameworks will benefit ) 6. use a well-known format ( path, etc ) to describe the env. 7. reuse open-source code instead of reinventing the wheel ( ant ). 8. Add extra features - like multiple profiles ( using different targets ), ability to easily execute 'pre/post' tasks ( like generating the apache config files ) And I can go on - there are many other benefits. Nobody is arguing ( at least not me ) on the benefits of the idea. From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. I think it adds quite a bit on both unix and windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. I disagree ( twice )- the bat scripts are not simple, and you _don't_ have to add dependencies to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. I partially agree - the scripts are well tuned and work, so there's no reason to drop them. They work fine on Unix. On Windows, they work fine *if* you: 1. Always define %CATALINA_HOME% (%0 is
cvs commit: jakarta-tomcat gump.xml
rubys 2002/08/03 11:44:37 Modified:.gump.xml Log: Get directory correct for tomcat.jar Revision ChangesPath 1.11 +1 -1 jakarta-tomcat/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat/gump.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- gump.xml 3 Aug 2002 12:45:15 - 1.10 +++ gump.xml 3 Aug 2002 18:44:37 - 1.11 @@ -29,7 +29,7 @@ work nested=build/tomcat/classes/ home nested=build/tomcat/ -jar name=tomcat.jar/ +jar name=lib/tomcat.jar/ jar name=lib/common/tomcat_core.jar/ jar name=lib/common/core_util.jar/ jar name=lib/container/container_util.jar/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat gump.xml
rubys 2002/08/03 11:51:23 Modified:.gump.xml Log: util will be needed at runtime Revision ChangesPath 1.12 +1 -1 jakarta-tomcat/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat/gump.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- gump.xml 3 Aug 2002 18:44:37 - 1.11 +++ gump.xml 3 Aug 2002 18:51:23 - 1.12 @@ -22,7 +22,7 @@ depend project=xml-xerces/ depend project=jakarta-ant/ depend project=jakarta-servletapi/ -depend project=jakarta-tomcat-util/ +depend project=jakarta-tomcat-util runtime=true/ depend project=jakarta-tomcat-connectors/ depend project=jsse/ depend project=jmx/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat gump.xml
rubys 2002/08/03 15:43:59 Modified:.gump.xml Log: facade needed by cactus Revision ChangesPath 1.13 +1 -0 jakarta-tomcat/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat/gump.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- gump.xml 3 Aug 2002 18:51:23 - 1.12 +++ gump.xml 3 Aug 2002 22:43:59 - 1.13 @@ -34,6 +34,7 @@ jar name=lib/common/core_util.jar/ jar name=lib/container/container_util.jar/ jar name=lib/container/tomcat_modules.jar/ +jar name=lib/container/facade22.jar/ javadoc nested=build/tomcat/webapps/ROOT/javadoc/ nag to=[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat gump.xml
rubys 2002/08/03 15:47:30 Modified:.gump.xml Log: jasper-runtime.jar needed by cactus Revision ChangesPath 1.14 +1 -0 jakarta-tomcat/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat/gump.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- gump.xml 3 Aug 2002 22:43:59 - 1.13 +++ gump.xml 3 Aug 2002 22:47:30 - 1.14 @@ -32,6 +32,7 @@ jar name=lib/tomcat.jar/ jar name=lib/common/tomcat_core.jar/ jar name=lib/common/core_util.jar/ +jar name=lib/common/jasper-runtime.jar/ jar name=lib/container/container_util.jar/ jar name=lib/container/tomcat_modules.jar/ jar name=lib/container/facade22.jar/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java
luehe 2002/08/03 16:29:21
Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
jasper2/src/share/org/apache/jasper/compiler Compiler.java
Generator.java JspRuntimeContext.java
TagFileProcessor.java
jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
Log:
Store tag file .java and .class files in standard location
(/tagfiles/org/apache/jsp/), regardless of the original tag file
path, and add this standard location to the compilation classpath for
JSP pages
Revision ChangesPath
1.14 +44 -32
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JspCompilationContext.java1 Aug 2002 23:29:36 - 1.13
+++ JspCompilationContext.java3 Aug 2002 23:29:21 - 1.14
@@ -115,16 +115,20 @@
protected boolean reload = true;
protected URLClassLoader jspLoader;
-protected URL [] outUrls = new URL[1];
+protected URL[] outUrls = new URL[1];
protected Class servletClass;
protected boolean isTagFile;
protected TagInfo tagInfo;
// jspURI _must_ be relative to the context
-public JspCompilationContext(String jspUri, boolean isErrPage, Options options,
- ServletContext context, JspServletWrapper jsw,
+public JspCompilationContext(String jspUri,
+ boolean isErrPage,
+ Options options,
+ ServletContext context,
+ JspServletWrapper jsw,
JspRuntimeContext rctxt) {
+
this.jspUri = canonicalURI(jspUri);
this.isErrPage = isErrPage;
this.options=options;
@@ -146,9 +150,11 @@
this.rctxt=rctxt;
}
-public JspCompilationContext(String tagfile, TagInfo tagInfo,
+public JspCompilationContext(String tagfile,
+ TagInfo tagInfo,
Options options,
- ServletContext context, JspServletWrapper jsw,
+ ServletContext context,
+ JspServletWrapper jsw,
JspRuntimeContext rctxt) {
this(tagfile, false, options, context, jsw, rctxt);
@@ -200,8 +206,8 @@
return outputDir;
}
-public void setOutputDir( String s ) {
-this.outputDir=s;
+public void setOutputDir(String s) {
+this.outputDir = s;
}
/**
@@ -396,17 +402,23 @@
if (jspPath != null) {
return jspPath;
}
-String dirName = getJspFile();
-int pos = dirName.lastIndexOf('/');
-if (pos 0) {
-dirName = dirName.substring(0, pos + 1);
-} else {
-dirName = ;
-}
-jspPath = dirName + getServletClassName() + .java;
-if (jspPath.startsWith(/)) {
-jspPath = jspPath.substring(1);
-}
+
+ if (isTagFile) {
+ jspPath = tagfiles/org/apache/jsp/ + tagInfo.getTagName() + .java;
+ } else {
+ String dirName = getJspFile();
+ int pos = dirName.lastIndexOf('/');
+ if (pos 0) {
+ dirName = dirName.substring(0, pos + 1);
+ } else {
+ dirName = ;
+ }
+ jspPath = dirName + getServletClassName() + .java;
+ if (jspPath.startsWith(/)) {
+ jspPath = jspPath.substring(1);
+ }
+ }
+
return jspPath;
}
@@ -508,7 +520,7 @@
public void compile() throws JasperException, FileNotFoundException {
createCompiler();
-if (jspCompiler.isOutDated()) {
+ if (jspCompiler.isOutDated()) {
try {
jspCompiler.compile();
reload = true;
@@ -518,7 +530,7 @@
throw new JasperException(
Constants.getString(jsp.error.unable.compile),ex);
}
-}
+ }
}
/** True if the servlet needs loading
@@ -568,24 +580,24 @@
return servletClass;
}
-public void createOutdir() {
+public void createOutdir(String dirPath) {
File outDirF = null;
try {
URL outURL = options.getScratchDir().toURL();
-
Re: [5] launcher/deamon
On Sat, 3 Aug 2002, Patrick Luby wrote: Basically, commons-launcher classloads the ant.jar bundled with Tomcat 5 (Jasper2 also classloads Ant 1.5). commons-launcher is just a wrapper for bootstrapping Ant plus some custom tasks and data types. I don't use Ant's scripts because Ant' batch script suffers the same Windows problems as every other batch based program: There are 2 issuses here: - how you run the program - I assume you need a .bat or something to run java with the right parameters. It can be just java -jar, but you still need that. - extensions to ant's Exec ( to detach, etc ). I think those should be contributed to ant, and only if they refuse them keep them in tomcat. Same for the startup script. I mentioned the community because Bill Barker voiced some reservations about including commons-launcher. I also have reservations - I see no reason to require it, at least not until commons-launcher is stable and released. java -jar tomcat.jar should be enough ( I almost got it working for 5.0, and it works very well for 3.3 ). This was included in Remy's Tomcat 5 proposal. It was under an item, IIRC, entitled Tomcat 5 will use the Launcher used in Sun's JWSDP product. Since the Tomcat 5 proposal got approved, I assumed it was my That assumes that everyone knows how JWSDP works :-) Even if this was included in Remy's proposal - it seems many people are not very aware of this. I partially agree - the scripts are well tuned and work, so there's no reason to drop them. They work fine on Unix. On Windows, they work fine *if* you: 1. Always define %CATALINA_HOME% (%0 is not always reliable) 2. You don't have spaces in %CATALINA_HOME% (for loops do not work with spaces on some Windows versions) 3. You don't use any of the %JAVA_OPTS% or %CATALINA_OPTS% environment varables (batch scripts on some versions of Windows will abort if there are = characters in the environment variable) 4. You don't want stderr to be logged to a file (stderr cannot be redirected in a DOS shell) Have you looked at tomcat(3) Main.java ? It works the same on windows and unix, and all it needs is 'java -jar'. All logic to find TOMCAT_HOME is in java. Of course, passing JAVA_OPTS is a different story - and I'm not sure running a java program to set the options and run another program is a good solution ( the startup time will be pretty big - it is already too big for my taste ). So I think having multiple options is good - the service wrapper ( C ), the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process. If we add most logic inside the starter ( creating CLASSATH, detect TOMCAT_HOME, etc ) the external starter can be simple enough. The vote to put it in was already made in the Tomcat 5 proposal. So I think voting on it again is redundant. If someone would like to propose its removal, I am OK with that and I can even do the removal for them. I was sugesting 'vote' more as a way to get more people aware of this. As I mentioned, I didn't know that the launcher will be required or the BATs will no longer be used. And I suspect other people were in the same situation. If not a vote - at least a spec describing the 5.0 startup mechansim(s), checked into CVS. The problem is not on removing the launcher, but on making sure other mechanisms are still possible and we keep it optional at least until commons-launcher has a 1.0 release, enough documentation and stability. Unfortunately, I really don't have much spare time available right now to push for acceptance of this new piece of code. So, if anyone is really uncomfortable with this code or they don't think it is ready for use in Tomcat yet, I will have no hurt feelings if we want it to be taken out. In fact, I would find that understandable since I have not been able to find the time to write up the documentation for the tool. Nobody has time. I would say it's best to leave it in - as an optional component ( and just change build.xml to detect if it is available ). When you or anyone finds the time to document it and get launcher released or merged into ant - we can discuss making it the 'default' startup. But I will opose making it the 'only' startup mechanism. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11449] New: - Attribute has no value, related to quotation mark
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11449. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11449 Attribute has no value, related to quotation mark Summary: Attribute has no value, related to quotation mark Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: OS/2 Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using Tomcat under Netbeans; they include v4.04 final as far as I know.. When I try compiling a JSP containing this line: jsp:setProperty name=counter property=appBase value=%= application.getRealPath() % / I get Attribute has no value The cause of the bug seems to be %= application.getRealPath() %.. When you remove it, the problem goes away. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Costin, [EMAIL PROTECTED] wrote: On Sat, 3 Aug 2002, Patrick Luby wrote: I also have reservations - I see no reason to require it, at least not until commons-launcher is stable and released. java -jar tomcat.jar should be enough ( I almost got it working for 5.0, and it works very well for 3.3 ). java -jar has one big problem: how do you set java.endorsed.dirs? This java.endorsed.dirs problem is one of the primary reasons the Launcher forks a child JVM. Since java.endorsed.dirs must be set when you invoke the JVM (setting in main() has no effect), you need to use the -Djava.endorsed.dirs=... command line argument with JDK 1.4. And since setting java.endorsed.dirs in a batch script proved flaky due to the %0 problem in some Windows versions, I had to fork a child JVM. If you find a way around this without forking, let me know because the one thing I don't like about my Launcher implementation is the need to fork a child JVM. Have you looked at tomcat(3) Main.java ? It works the same on windows and unix, and all it needs is 'java -jar'. All logic to find TOMCAT_HOME is in java. See my JDK 1.4 and java.endorsed.dirs issue above. The java -jar works great on JDK 1.2 and JDK 1.3, but not JDK 1.4 when you need a custom XML parser and, unfortunately, the default JDK 1.4 parser does not have the XML schema support that Tomcat 5 needs so we need to set java.endorsed.dirs. Of course, passing JAVA_OPTS is a different story - and I'm not sure running a java program to set the options and run another program is a good solution ( the startup time will be pretty big - it is already too big for my taste ). A more efficient solution is a native program that uses the Java Invocation API to load the JVM and run the target application's main(). I did not go that route only because I did not want to put native C code into Tomcat. But that might be the best course of action in the long run. So I think having multiple options is good - the service wrapper ( C ), the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process. If we add most logic inside the starter ( creating CLASSATH, detect TOMCAT_HOME, etc ) the external starter can be simple enough. Makes sense. I was sugesting 'vote' more as a way to get more people aware of this. As I mentioned, I didn't know that the launcher will be required or the BATs will no longer be used. And I suspect other people were in the same situation. If not a vote - at least a spec describing the 5.0 startup mechansim(s), checked into CVS. The problem is not on removing the launcher, but on making sure other mechanisms are still possible and we keep it optional at least until commons-launcher has a 1.0 release, enough documentation and stability How about this: I revert the build back to the old scripts and those scripts are copied into the distribution's bin directory. Then, if commons-launcher is available, the new scripts (with a different name such as catalina-launcher.sh so that old scripts don't get overwritten) and commons-launcher also get copied into the distribution's bin directory. This way, people can try it out and suggest improvements if they want to, but the old scripts will still be the default. This switch won't take much time to make. Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: documentation
I was thinking of specifically the Root path issue you explained to me. My idea was just a short 2-4 paragraphs about using full path in server.xml and other ways to work around it. So it would be tomcat specific, though I haven't tested it with other webservers, so it might exist in other servers also. peter --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Fri, 2 Aug 2002, Peter Lin wrote: Date: Fri, 2 Aug 2002 12:31:28 -0700 (PDT) From: Peter Lin [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: documentation I was looking through the Tomcat 4 docs today to see if there was documentation on setting up ServletContextListener in web.xml. If there isn't an existing version, I would like to write one up and submit it to the group for consideration. What do people think of the idea? I went through most of the config related pages and didn't see any documentation on it. Doesn't the servlet spec count as documentation for this? http://java.sun.com/products/servlet/download.html Tomcat's docs focus on what is unique to Tomcat (such as the stuff in server.xml). The web application deployment descriptor (web.xml) is portable across all containers, so we (or any other container) don't need to document it explicitly. peter lin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
On Sat, 03 Aug 2002 18:07:08 -0700, Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: On Sat, 3 Aug 2002, Patrick Luby wrote: I also have reservations - I see no reason to require it, at least not until commons-launcher is stable and released. java -jar tomcat.jar should be enough ( I almost got it working for 5.0, and it works very well for 3.3 ). java -jar has one big problem: how do you set java.endorsed.dirs? This java.endorsed.dirs problem is one of the primary reasons the Launcher forks a child JVM. Since java.endorsed.dirs must be set when you invoke the JVM (setting in main() has no effect), you need to use the -Djava.endorsed.dirs=... command line argument with JDK 1.4. And since setting java.endorsed.dirs in a batch script proved flaky due to the %0 problem in some Windows versions, I had to fork a child JVM. If you find a way around this without forking, let me know because the one thing I don't like about my Launcher implementation is the need to fork a child JVM. First of all, there is no need to do that for 1.3, and that's what most people are using. Second, endorsed.dirs is a problem only if you want to replace the javax. or org.xml/w3c packages. And it's a stupid thing - I think we can get over it, there are far too many problems. We can still use a different parser/xslt if needed. Unfortunately the endorsed.dirs ( and requiring this in command line ) is stupid, and can't be fixed. Hopefully 1.4.2 or other VMs will fix this - if not we should just live with it. Have you looked at tomcat(3) Main.java ? It works the same on windows and unix, and all it needs is 'java -jar'. All logic to find TOMCAT_HOME is in java. See my JDK 1.4 and java.endorsed.dirs issue above. The java -jar works great on JDK 1.2 and JDK 1.3, but not JDK 1.4 when you need a custom XML parser and, unfortunately, the default JDK 1.4 parser does not have the XML schema support that Tomcat 5 needs so we need to set java.endorsed.dirs. Again, AFAIK you don't need endorsed to use a different parser. And 'schema support' is needed only for validation - and hopefully we stop the stupid practice of validating the same file every time we start tomcat, even if it is not modified. In 3.3 we save a timestamp when we validate and save more 1/2 of the startup time for a webapp. With schema validation it'll be much worse. If the user really wants the web.xml validated by a schema ( which IMHO is plain stupid - tomcat is going to process every piece of information from it anyway ) - we can just spawn a java process with the right endorsed.dirs for validation. After all this will be nothing compared with the overhead of schema validation. Of course, passing JAVA_OPTS is a different story - and I'm not sure running a java program to set the options and run another program is a good solution ( the startup time will be pretty big - it is already too big for my taste ). A more efficient solution is a native program that uses the Java Invocation API to load the JVM and run the target application's main(). I did not go that route only because I did not want to put native C code into Tomcat. But that might be the best course of action in the long run. :-) Why do people believe you need Invocation or some other fancy things? A fork()/exec() is enough if you only want a replacement for a .bat file. Tomcat does use native code already - the service stuff on windows and the jk code. The jk code can also be used for chuid() - quite important in some cases. So I think having multiple options is good - the service wrapper ( C ), the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process. If we add most logic inside the starter ( creating CLASSATH, detect TOMCAT_HOME, etc ) the external starter can be simple enough. Makes sense. I was sugesting 'vote' more as a way to get more people aware of this. As I mentioned, I didn't know that the launcher will be required or the BATs will no longer be used. And I suspect other people were in the same situation. If not a vote - at least a spec describing the 5.0 startup mechansim(s), checked into CVS. The problem is not on removing the launcher, but on making sure other mechanisms are still possible and we keep it optional at least until commons-launcher has a 1.0 release, enough documentation and stability How about this: I revert the build back to the old scripts and those scripts are copied into the distribution's bin directory. Then, if commons-launcher is available, the new scripts (with a different name such as catalina-launcher.sh so that old scripts don't get overwritten) and commons-launcher also get copied into the distribution's bin directory. This way, people can try it out and suggest improvements if they want to, but the old scripts will still be the default. This switch won't take much time to make. +1 As I said, I like the idea of using an ant xml file for the
cvs commit: jakarta-tomcat-5 build2.xml
costin 2002/08/03 20:48:50
Modified:.build2.xml
Log:
A more functional build file.
It now creates a fully functional tomcat ( there are few problems with
jasper tough ).
Also added a task that starts tomcat from ant - with 1.4 you need
fork=true ( I'll try to make few changes to ant classloader to avoid
this ).
I'm also trying 'everything in a jar' model - there are cases when
you don't need the complex hierarchy.
Note that the generated tomcat.jar is 2.8M, out of which 1.6 is
tomcat. That's not very bad - if we move backward compat stuff
into tomcat-compat and split some 'optional' functionality we
can get well bellow 1M.
( that includes tomcat33 code - i.e. 300k, most of it not used at
the moment, only some non-duplicated modules will be ported )
Revision ChangesPath
1.3 +120 -3jakarta-tomcat-5/build2.xml
Index: build2.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build2.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build2.xml1 Aug 2002 20:31:15 - 1.2
+++ build2.xml4 Aug 2002 03:48:50 - 1.3
@@ -28,7 +28,7 @@
property name=jtc.home
value=${basedir}/../jakarta-tomcat-connectors/
- property name=build.dir value=${basedir}/build/tomcat5/
+ property name=build.dir value=${basedir}/build/
property name=log4j.jar value=${base.path}/log4j/log4j.jar/
@@ -44,6 +44,14 @@
pathelement location=${jta.jar}/
pathelement location=${log4j.jar}/
/path
+
+ patternset id=static.res
+include name=**/*.properties /
+include name=**/*.dtd /
+include name=**/*.tld /
+include name=**/*.xsd /
+include name=**/*.xml /
+ /patternset
path id=jasperjars
pathelement location=${jaxen.jar}/
@@ -86,8 +94,25 @@
/src
exclude name=org/apache/tomcat/util/net/PureTLS* /
exclude name=org/apache/commons/logging/impl/LogKitLogger.java /
- exclude name=org/apache/commons/modeler/Modeler.java /
+
+ !-- Fail with GCJ --
+ exclude name=org/apache/commons/collections/DoubleOrderedMap.java /
+ exclude name=org/apache/tomcat/util/log/CommonLogHandler.java /
/javac
+copy toDir=${build.dir}/classes
+ fileset dir=${commons.home}/modeler/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/util/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${commons.home}/digester/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${commons.home}/logging/src/java
+patternset refid=static.res /
+ /fileset
+/copy
/target
target name=tomcat
@@ -111,6 +136,40 @@
exclude name=org/apache/tomcat/ant/Tomcat3Precompiler.java /
exclude name=org/apache/catalina/startup/BootstrapService.java /
/javac
+
+copy toDir=${build.dir}/classes
+ fileset dir=${catalina.home}/catalina/src/share
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/coyote/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/http11/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/jk/java
+patternset refid=static.res /
+ /fileset
+/copy
+
+copy toDir=${build.dir}/classes
+fileset dir=${api.home}/src/share
+ include name=**/*.properties/
+/fileset
+/copy
+
+!-- Servlet/JSP resources - work around stupid src layout --
+copy todir=${build.dir}/classes/javax/servlet/resources
+fileset dir=${api.home}/src/share/dtd
+ include name=web-app*.dtd/
+/fileset
+/copy
+copy todir=${build.dir}/classes/javax/servlet/jsp/resources
+ fileset dir=${api.home}/src/share/dtd
+include name=web-jsptaglibrary*.dtd/
+include name=jspxml.*/
+ /fileset
+/copy
/target
@@ -129,11 +188,69 @@
exclude name=org/apache/taglibs/standard/lang/jstl/test/** /
exclude
name=org/apache/taglibs/standard/lang/jstl/parser/jsp20/ELParser.java /
/javac
+copy toDir=${build.dir}/classes
+ fileset dir=${jasper.home}/src/share
+patternset refid=static.res /
+ /fileset
+ fileset dir=${taglibs.home}/standard/src
+patternset refid=static.res /
+ /fileset
+/copy
+ /target
+
+ target name=jar
+ description=Create jars
+mkdir dir=${build.dir}/lib /
+jar file=${build.dir}/lib/servlet.jar
+ fileset dir=${build.dir}/classes
+include name=javax/servlet/**/
+ /fileset
+
Re: cvs commit: jakarta-tomcat-5 build2.xml
Costin,
If it helps, you can exclude org/apache/catalina/launcher/** from the
build if you are not using commons-launcher. This package is only used
by the Launcher's XML files and has no other packages depend on this
package.
Also, I noticed that you are compiling the ${taglibs.home}/standard/src
directory. If it helps, you don't need to do this as the expression
language classes are already compiled and checked into the
jakarta-tomcat-jasper/jasper2/lib/jsp20el.jar.
Patrick
[EMAIL PROTECTED] wrote:
costin 2002/08/03 20:48:50
Modified:.build2.xml
Log:
A more functional build file.
It now creates a fully functional tomcat ( there are few problems with
jasper tough ).
Also added a task that starts tomcat from ant - with 1.4 you need
fork=true ( I'll try to make few changes to ant classloader to avoid
this ).
I'm also trying 'everything in a jar' model - there are cases when
you don't need the complex hierarchy.
Note that the generated tomcat.jar is 2.8M, out of which 1.6 is
tomcat. That's not very bad - if we move backward compat stuff
into tomcat-compat and split some 'optional' functionality we
can get well bellow 1M.
( that includes tomcat33 code - i.e. 300k, most of it not used at
the moment, only some non-duplicated modules will be ported )
Revision ChangesPath
1.3 +120 -3jakarta-tomcat-5/build2.xml
Index: build2.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build2.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build2.xml 1 Aug 2002 20:31:15 - 1.2
+++ build2.xml 4 Aug 2002 03:48:50 - 1.3
@@ -28,7 +28,7 @@
property name=jtc.home
value=${basedir}/../jakarta-tomcat-connectors/
- property name=build.dir value=${basedir}/build/tomcat5/
+ property name=build.dir value=${basedir}/build/
property name=log4j.jar value=${base.path}/log4j/log4j.jar/
@@ -44,6 +44,14 @@
pathelement location=${jta.jar}/
pathelement location=${log4j.jar}/
/path
+
+ patternset id=static.res
+include name=**/*.properties /
+include name=**/*.dtd /
+include name=**/*.tld /
+include name=**/*.xsd /
+include name=**/*.xml /
+ /patternset
path id=jasperjars
pathelement location=${jaxen.jar}/
@@ -86,8 +94,25 @@
/src
exclude name=org/apache/tomcat/util/net/PureTLS* /
exclude name=org/apache/commons/logging/impl/LogKitLogger.java /
- exclude name=org/apache/commons/modeler/Modeler.java /
+
+ !-- Fail with GCJ --
+ exclude name=org/apache/commons/collections/DoubleOrderedMap.java /
+ exclude name=org/apache/tomcat/util/log/CommonLogHandler.java /
/javac
+copy toDir=${build.dir}/classes
+ fileset dir=${commons.home}/modeler/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/util/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${commons.home}/digester/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${commons.home}/logging/src/java
+patternset refid=static.res /
+ /fileset
+/copy
/target
target name=tomcat
@@ -111,6 +136,40 @@
exclude name=org/apache/tomcat/ant/Tomcat3Precompiler.java /
exclude name=org/apache/catalina/startup/BootstrapService.java /
/javac
+
+copy toDir=${build.dir}/classes
+ fileset dir=${catalina.home}/catalina/src/share
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/coyote/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/http11/src/java
+patternset refid=static.res /
+ /fileset
+ fileset dir=${jtc.home}/jk/java
+patternset refid=static.res /
+ /fileset
+/copy
+
+copy toDir=${build.dir}/classes
+fileset dir=${api.home}/src/share
+ include name=**/*.properties/
+/fileset
+/copy
+
+!-- Servlet/JSP resources - work around stupid src layout --
+copy todir=${build.dir}/classes/javax/servlet/resources
+fileset dir=${api.home}/src/share/dtd
+ include name=web-app*.dtd/
+/fileset
+/copy
+copy todir=${build.dir}/classes/javax/servlet/jsp/resources
+ fileset dir=${api.home}/src/share/dtd
+include name=web-jsptaglibrary*.dtd/
+include name=jspxml.*/
+ /fileset
+/copy
/target
@@ -129,11 +188,69 @@
exclude name=org/apache/taglibs/standard/lang/jstl/test/** /
