Re: jakarta-tomcat-connectors/jk will no longer build
Costin, Costin Manolache wrote: No, the tomcat4 package shouldn't compile with tomcat5. I think we need a way to distinguish tomcat4 from tomcat5 in the conditions. Or a flag that is set by the tomcat5 build ( probably better ). I added a org.apache.ajp.tomcat5 package in jakarta-tomcat-connectors/jk. This package contains no classes as the org.apache.ajp.tomcat4 classes will need to be ported so that they do not use the HttpRequestBase class. Also, I made jakarta-tomcat-connectors/jk/build.xml handle concurrent building of the tomcat4 and tomcat5 packages when both Tomcat 4.x and Tomcat 5 are present. This was what was causing my build to break: build.xml was automatically detecting my Tomcat 4 build even when I had catalina.home set to my Tomcat 5 build. So, everything now builds fine except that the Ajp13 connector will not work with Tomcat 5 since there are no tomcat5 classes at this time. 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:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
jakarta-tomcat-connectors/jk will no longer build
Remy, Since the org.apache.catalina.connector.HttpResponseBase was removed from jakarta-tomcat-catalina, a clean Tomcat 5 build now breaks when compiling jakarta-tomcat-connectors/jk. Does HttpResponseBase need to be added back?: Thanks, Patrick [javac] Compiling 44 source files to /export/pluby/tomcat/jakarta-tomcat-connectors/jk/build/classes [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:75: cannot resolve symbol [javac] symbol : class HttpRequestBase [javac] location: package connector [javac] import org.apache.catalina.connector.HttpRequestBase; [javac] ^ [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:86: cannot resolve symbol -- 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: [PATCH] SSLSocket, CLIENT-AUTH, and JDK1.4
Bob,
You can check the JVM version more accurately using the
java.specification.version system property. It will always be 1.4
for J2SE 1.4.x so you can do the following:
if (1.4.equals(System.getProperty(java.specification.version)))
...
Patrick
Bob Herrmann wrote:
Before I commit this diff, I would like some eyes. This fixes a problem
with JSSE doing request for CERTS on an already established SSL Socket.
I am concerned that this change may not pass the sniff test as I check a
System.getProperty(java.vm).startsWith(1.4) to see if the extra
jiggle is needed on the SSLSocket - but my instincts tell me that is
colorfully kludgey. Ideas?
Index: util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
retrieving revision 1.1
diff -u -r1.1 JSSESupport.java
--- util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java4 Oct
2002 20:03:10 - 1.1
+++ util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java7 Oct
2002 20:15:14 -
@@ -66,6 +66,8 @@
import java.security.cert.CertificateFactory;
import javax.net.ssl.SSLSession;
import javax.net.ssl.SSLSocket;
+import javax.net.ssl.HandshakeCompletedListener;
+import javax.net.ssl.HandshakeCompletedEvent;
import java.security.cert.CertificateFactory;
import javax.security.cert.X509Certificate;
@@ -127,6 +129,9 @@
session.invalidate();
ssl.setNeedClientAuth(true);
ssl.startHandshake();
+ if ( System.getProperty(java.version).startsWith(1.4) ){
+ synchronousHandshake(ssl);
+ }
session = ssl.getSession();
jsseCerts = session.getPeerCertificateChain();
if(jsseCerts == null)
@@ -198,5 +203,44 @@
}
return buf.toString();
}
+
+/**
+ * JSSE in JDK 1.4 has an issue that requires us to do a read() to
+ * get the client-cert. As suggested by Andreas Sterbenz
+ */
+private static void synchronousHandshake(SSLSocket socket)
+throws IOException {
+InputStream in = socket.getInputStream();
+int oldTimeout = socket.getSoTimeout();
+socket.setSoTimeout(100);
+Listener listener = new Listener();
+socket.addHandshakeCompletedListener(listener);
+byte[] b = new byte[0];
+socket.startHandshake();
+int maxTries = 50; // 50 * 100 = example 5 second rehandshake
timeout
+for (int i = 0; i maxTries; i++) {
+try {
+int x = in.read(b);
+} catch (SocketTimeoutException e) {
+// ignore
+}
+if (listener.completed) {
+break;
+}
+}
+socket.removeHandshakeCompletedListener(listener);
+socket.setSoTimeout(oldTimeout);
+if (listener.completed == false) {
+throw new SocketTimeoutException(SSL Cert handshake
timeout);
+}
+}
+
+private static class Listener implements HandshakeCompletedListener
{
+volatile boolean completed = false;
+public void handshakeCompleted(HandshakeCompletedEvent event) {
+completed = true;
+}
+}
+
}
--
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: [VOTE] [4.0.5] [4.1.12] Security releases
Remy, Here's my votes. Patrick Tomcat 4.0.5 release ballot +1 [X] Yes, I approve this release -1 [ ] No, because: /ballot Tomcat 4.1.12 Stable release ballot +1 [X] Yes, I approve this release -1 [ ] No, because: /ballot -- 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: jakarta-servleapi-5
Bob, Good idea. Here's my vote. [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [X] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone 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: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
Remy, Remy Maucherat wrote: +1 from me. If we do that, that would mean commons-daemon is not going anywhere: - the interfaces will go away - the launcher code is supposed to end up in Ant If the launcher doesn't end up in Ant, then IMO we should create commons-launcher. Since it will take a while to migrate all of the functionality in the launcher to Ant, we should plan on the commons-launcher code being around a while. So, +1 for creating a separate commons-launcher repository. 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: [5] Session.logout()
Bob, You are correct that browsers keep passing the user/pass with each request. As for getting the browser to rechallenge, that is very tricky and would be hacky at best. I would expect that when Basic authentication is used and the last request caused Session.logout() to called, the next request (which will contain a valid user/pass), will effectively log the user in. Trying to make Basic authentication act exactly like FORM authentication is probably not realistic as the display of user/pass input screen is browser dependent. Effectively, the user is silently logging back in with the next visit. I believe that this still complies with the spec. I suspect that the real problem may be that the bug submitter's interpretation of the spec may be a bit inaccurate. Patrick Bob Herrmann wrote: The JSP spec 2.4 gives us Session.logout(), what do we do when using Basic authentication? Once challenged, the web browser keeps passing the user/pass (right?) so any ideas about how to get the browser to re-challenge the end user? (change the domain?) Cheers, -bob -- 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: VOTE: Restoring Tomcat examples: Which workspace?
Remy, Remy Maucherat wrote: I just got a bit lazy after finishing the repackaging in j-s-5, and thought I would do it the next day :-D I don't think it is lazy to put this off. Instead, I think we are all trying to tackle higher priority issues first. Speaking of higher priority issues, I would vote for resolving the getHeaders() problem since they are causing Watchdog failures. Are you and Costin comfortable with Steve Downey's latest proposal (headers are split on , for only the headers explicitly defined in the HTTP/1.1 specification)? 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: [VOTE] New committer: Jean-Francois Arcand
All, Jean-François Arcand has received several +1's and no -1's. So, Jean-François, congratulations! Can someone create an account for Jean-François Arcand? Thanks, Patrick Patrick Luby wrote: I would like to propose that we add Jean-François Arcand as a Tomcat committer. I believe he has submitted enough patches to show that he will be a positive contributor to Tomcat 5. Thanks, 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: Watchdog aggregation of headers may be incorrect
Remy, Remy Maucherat wrote: No, this is not correct. You are allowed to do that only if the application knows it makes sense to do so (ie, only when it call getHeaders). Some code to do that should be added in the adapter. This makes more sense than my original thoughts since the Watchdog failures are only happening in tests that invoke the getHeaders() method. No, this musn't be done there, as it would screw up many headers. Please read the chapter on multivalued headers in the HTTP/1.1 spec. Which class do you suggest that this conversion be done? I agree that putting where I suggested is not the right place. Thanks, 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: [5.0] [PROPOSAL] Refactored mapper
Remy, Remy Maucherat wrote: It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? 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: [PATCH] Xerces 2.0.1 also is buggy
Jean-François,
Can you also submit the patch to both BUILDING.txt and build.xml.
build.xml needs to use the cvsbuild target to download and build
Xerces since you can't reliably use downloadgz for nightly builds
since they disappear of the website after 2 weeks.
Patrick
Jean-francois Arcand wrote:
Hi,
Xerces 2.0.1 contains a bug that produce the error Remy reports earlier
this week :-(
Xerces 2.0.2 contains a bug that produce a StackTraceOverflow :-(
In order to supports schema and dtd, Xerces nightly build is the only
version that parse properly DTD and schema when validation is on. That's
a very good reason why we need to have by default validation turned off ;-)
Thanks,
-- Jeanfrancois
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.29
diff -u -r1.29 build.properties.default
--- build.properties.default 16 Aug 2002 17:03:19 - 1.29
+++ build.properties.default 16 Aug 2002 23:36:59 -
@@ -103,12 +103,12 @@
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
-# - Xerces XML Parser, version 2_0_1 -
-xerces.home=${base.path}/xerces-2_0_1
+# - Xerces XML Parser, version 20020815 or latter -
+xerces.home=${base.path}/xml-xerces
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.0.1.tar.gz
+xerces.loc=xml-xerces
# --
--
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][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin, [EMAIL PROTECTED] wrote: Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? 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: [5.0] [PROPOSAL] Validation/NamespaceAware
Jean-François, I would vote +1 as long as these two HOST attributes are optional attributes. In other words, if they are missing from server.xml, both default to false. I think that is what you are proposing but I just wanted to make sure. Patrick Jean-francois Arcand wrote: Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. Thanks, -- Jeanfrancois -- 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.0] [PROPOSAL] Refactored mapper
[EMAIL PROTECTED] wrote: The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I have heard that Pier is in the Expert Group. But I could be wrong. I think the Servlet 2.4 spec is going Public Final Draft this month (not sure exactly when), but you can e-mail the expert group directly at: [EMAIL PROTECTED] Also, the latest draft of the spec is at: http://www.jcp.org/jsr/detail/154.jsp 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: [5.0] [PROPOSAL] Refactored mapper
Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick [EMAIL PROTECTED] wrote: On Thu, 15 Aug 2002, Remy Maucherat wrote: Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what t spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I'm also curious to who is representing apache ( if any ) in the JSP spec - I'm still strugling to understand how the TLD stuff happened and nobody noticed or complained in any way - the whole 'config in web.xml' model is now screwed, with any file ( including jars ) potentially storing config for web applications. 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][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin, I took a look at InspectionUtils.guessInstall() and it looks OK. However, it has one limitation: it looks at the classpath to guess the install directory. This works in most cases, but does not work when the InspectionUtils class is loaded in a classloader. Since both the commons-launcher and some J2EE servers load Tomcat's Bootstrap class via a classloader, InspectionUtils.guessInstall() may not work correctly. The way I worked around this in commons-launcher was to invoke the getResource() resource on the class e.g. Bootstrap.class.getResource(/ + Bootstrap.class.getName() + .class) to get the classpath element that this main class was loaded from. This works even if another application is loading your application using a classloader. At this point, I could port this getResource() logic into InspectionUtils or I can put this code directly in Bootstrap.java. What is your preference? Patrick [EMAIL PROTECTED] wrote: On Thu, 15 Aug 2002, Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? Probably Bootrstrap is the best place - since it needs to construct the classpath to load CatalinaService ( so it needs it ). If you just include IntrospectionUtil from j-t-c you get it all - ( it is used in jk already ). All you need ( besides build.xml changes ) is: home= IntrospectionUtils.guessInstall(catalina.home, catalina.base, bootstrap.jar, org.apache.catalina.startup.CatalinaService); That will set catalina.home/catalina.base: - if only one is set the other will take that value. - if none is set, it'll look in CLASSPATH for bootstrap.jar and go one level up, or for org/apache... if classes/ is used - and set catalina.home fromt that. You don't need to port it - it is useable directly. ( well, you can cutpaste the method if you want, it's independent of the rest ) 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.0] [VOTE] Release numbering scheme and test releases
Remy, Here are my votes: ballot +1 [X] Tomcat 5 should use Tomcat 4.1 version numbering scheme and release management -1 [ ] Tomcat 5 should use something else (to be decided later) /ballot ballot +1 [ ] Start releasing milestones for Tomcat 5.0 on a regular basis soon -1 [X] No, later /ballot 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]
[VOTE] New committer: Jean-Francois Arcand
I would like to propose that we add Jean-François Arcand as a Tomcat committer. I believe he has submitted enough patches to show that he will be a positive contributor to Tomcat 5. Thanks, 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: [5.0] Build notes
All,
Couldn't we go a step farther and check any Apache dependencies into the
Tomcat cvs repository and remove them from build.properties.default and
build.xml's download target? Of course, we can't do this for some 3rd
party dependencies, but we can for stuff like Xerces,
commons-digester/logging, etc. I think that this would make the build
more reliable since Tomcat 5 is dependent on very specific versions of
Apache dependencies (e.g. Xerces 2.0.1 only).
I know that a lot of other Jakarta projects do this. Are there any
problems with this?
Patrick
Jayson Falkner wrote:
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/ mkdir
dir=${base.path}/ /target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/ /target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
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
Re: [5.0] Build notes
Costin, [EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- 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: [PATCH][Catalina] Use fully qualified URI for locating localschema
/catalina/startup/ContextConfig.java,v
retrieving revision 1.7
diff -u -r1.7 ContextConfig.java
--- ContextConfig.java8 Aug 2002 18:31:33 - 1.7
+++ ContextConfig.java10 Aug 2002 14:46:08 -
@@ -493,10 +493,9 @@
// to support servlet.jar that does not contains the schema
if (url != null){
tldDigester.setSchema(url.toString());
+tldDigester = registerLocalSchema(tldDigester);
}
-tldDigester = registerLocalSchema(tldDigester);
-
tldDigester.addRuleSet(new TldRuleSet());
return (tldDigester);
@@ -527,9 +526,8 @@
// to support servlet.jar that does not contains the schema
if (url != null){
webDigester.setSchema(url.toString());
+webDigester = registerLocalSchema(webDigester);
}
-
-webDigester = registerLocalSchema(webDigester);
webDigester.addRuleSet(new WebRuleSet());
return (webDigester);
--
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: [PATCH][Catalina] Use fully qualified URI for locating localschema
Jean-François, I just deleted my CVS repositories, rechecked them out, and reapplied *both* the jakarta-servletapi-5 and jakarta-tomcat-catalina patches. I did a build from scratch and I still get the same exception. Note: I am using the HEAD of commons-digester. Might there be a incompatibility in commons-digester? Patrick Jean-francois Arcand wrote: Patrick, you also have to apply the catalina pache where it is defined the local schema location (Constants.java). I made some change to avoid having Xerces resolving with the wrong URI. Thanks, Jeanfrancois. Patrick Luby wrote: Jean-François, When I apply this patch and your jakarta-servletapi-5 patch and build with the latest commons-digester, I get the following exception. I seems that with your patches, Xerces no longer looks locally for the XML files. Accordingly, I think we should figure out what is happening before these patches should be applied as these patches make it impossible for anyone running behind a firewall to run Tomcat. Patrick org.xml.sax.SAXParseException: src-import.0: Failed to read imported schema document 'http://www.w3.org/2001/xml.xsd'. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:141) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:358) at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaWarning(XSDHandler.java:1837) at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1298) at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1240) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:611) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:654) at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:403) at org.apache.xerces.impl.xs.XMLSchemaValidator.processJAXPSchemaSource(XMLSchemaValidator.java:2302) at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1632) at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:568) at org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:832) at org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java:568) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:796) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:752) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:927) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1519) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:585) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148) at org.apache.commons.digester.Digester.parse(Digester.java:1512) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:573) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:711) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:247) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216
Re: [PATCH][Catalina] Use fully qualified URI for locating localschema
Jean-François, Thanks for finding the missing patch to commons-digester. I committed that patch and now Tomcat 5 works with both of your patches to jakarta-servletapi-5 and jakarta-tomcat-catalina. BTW, with your patches, all of the JSP test failures in watchdog are gone and all JSP test pass. Patrick Patrick Luby wrote: Jean-François, I just deleted my CVS repositories, rechecked them out, and reapplied *both* the jakarta-servletapi-5 and jakarta-tomcat-catalina patches. I did a build from scratch and I still get the same exception. Note: I am using the HEAD of commons-digester. Might there be a incompatibility in commons-digester? Patrick Jean-francois Arcand wrote: Patrick, you also have to apply the catalina pache where it is defined the local schema location (Constants.java). I made some change to avoid having Xerces resolving with the wrong URI. Thanks, Jeanfrancois. Patrick Luby wrote: Jean-François, When I apply this patch and your jakarta-servletapi-5 patch and build with the latest commons-digester, I get the following exception. I seems that with your patches, Xerces no longer looks locally for the XML files. Accordingly, I think we should figure out what is happening before these patches should be applied as these patches make it impossible for anyone running behind a firewall to run Tomcat. Patrick org.xml.sax.SAXParseException: src-import.0: Failed to read imported schema document 'http://www.w3.org/2001/xml.xsd'. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:141) at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:358) at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaWarning(XSDHandler.java:1837) at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1298) at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1240) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:611) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:654) at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:403) at org.apache.xerces.impl.xs.XMLSchemaValidator.processJAXPSchemaSource(XMLSchemaValidator.java:2302) at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1632) at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:568) at org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:832) at org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java:568) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:796) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:752) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:927) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1519) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:585) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148) at org.apache.commons.digester.Digester.parse(Digester.java:1512) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:573) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:711) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:247) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
Tocmat 5 failing watchdog on all tests
All, After the commits this morning to jakarta-tomcat-catalina, all of the watchdog tests are failing for Tomcat 5. I suspect that this has something to do with Jean-Francois' patch this morning but I cannot be sure as the problem is that Tomcat 5 is throwing exceptions when parsing TLD files. This was not happening when a did a clean checkout and build this morning. So, can those that made commits today take a look at this? Thanks, 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: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
Remy, Remy Maucherat wrote: No, I'd rather do something according to the pre-proposal put forward by Costin that would be a refactoring of the whole startup and configuration code, rather than an evolution of the current code. I don't have much interest in trying to improve that code, as I think it's good enough (ie, it gets the job done). That makes sense. Trying to rework the startup stuff at the same time before Costin's pre-proposal is implemented would probably cause a lot more problems (or at least later rework) than waiting until after Costin's pre-proposl is implemented. 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: [5.0] Build notes
Bob, Bob Herrmann wrote: $ sed -e 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' build.properties.default t $ mv t build.properties.default You don't want to replace build.properties.default. Instead you want to put your customized file in build.properties. That way, if build.properties.default changes, you will know. Also, using build.properties prevents accidental commits to build.properties.default. 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: cvs commit: jakarta-tomcat-5 build2.xml
Costin, Costin Manolache wrote: It may be a good idea to move the ant tasks/types that you need from sandbox into oac.launcher. I think they should be in either tomcat or ant ( preferably). Later on, after things stabilise we can propose it for commons proper. I would like to see the syspropertyset, argset, and jvmargset data types and the conditional sysproperty, arg, and jvmarg elements moved to Ant. Also, I should be able to integrate the launch task attributes into Ant's java task. I just won't be able to do it for a few weeks since my employer has squeezed my spare time down to nothing. But I intend to post patches for this code so that it can go in Ant 1.6. The other half of the Launcher code is merely the bootstrapping of ant.jar (which is where the enhanced data types listed above would be). This code be added to Ant 1.6 very easily as all it does is instantiate a ClassLoader and classload ant.jar. This piece of code deserves more explanation. In the launcher, this bootstrapper is called LauncherBootstrap.class and resides in the same directory as the shell script that users use. Then, in Windows batch scripts, you put %0\..;%PATH% as the classpath when invoking Java. Since Windows sometimes makes %0 meaningless, %PATH% is used as the classpath. Since LauncherBootstrap.class is an unjarred class in %PATH% (since it is in the same directory as the script), it will get included in the classpath. LauncherBootstrap.class then just loads ant.jar since Java can reliably determine which directory LauncherBootstrap.class was loaded from. In essence, the whole bootstrapping process is a hack to get around the %0 problem on Windows 95, 98, ME, and sometimes 2000. So, it might be useful to include this bootstrapper in Ant so that the Ant batch scripts can find its classes. There were a few other things that are in the Launcher which may be useful if ported to Ant: - Catching of uncaught Errors (e.g. OutOfMemoryError) and gracefully exiting - Syncronized starting and stopping of the build process so that other applications (e.g. commons-daemon) can start Ant and kill Ant directly. - Retrieve localized strings so that we can localize BuildExceptions and echo and fail messages. If the Ant committers accept my patches, effectively moving all of the Launcher functionality into Ant 1.6, then I think the commons-launcher portion of commons-daemon can be made obsolete and commons-daemon could just use Ant 1.6 directly. Right now, commons-daemon needs both commons-launcher.jar *and* ant.jar. Let me know what you think of this approach. Thanks, 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: [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
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) 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. 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. 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. Patrick 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] -- 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
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: cvs commit: jakarta-tomcat-5 build2.xml
/** /
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
+/jar
+
+jar file=${build.dir}/lib/tomcat-commons.jar
+ fileset dir=${build.dir}/classes
+include name=org/apache/commons/**/
+ /fileset
+/jar
+jar file=${build.dir}/lib/tomcat.jar
+ fileset dir=${build.dir}/classes
+include name=org/apache/tomcat/**/
+include name=org/apache/jk/**/
+include name=org/apache/coyote/**/
+include name=org/apache/naming/**/
+include name=org/apache/catalina/**/
+ /fileset
+/jar
+jar file=${build.dir}/lib/jasper.jar
+ fileset dir=${build.dir}/classes
+include name=org/apache/jasper/**/
+include name=org/apache/taglibs/standard/**/
+ /fileset
+/jar
+
+jar file=${build.dir}/tomcat-full.jar
manifest=resources/catalina-main.manifest
+ fileset dir=${build.dir}/classes
+include name=**/
+ /fileset
+/jar
/target
target name=run
-java classname=org.apache.catalina.startup.Bootstrap
+property name=tools.jar location=${java.home}/../lib/tools.jar /
+echo message=Tools.jar = ${tools.jar}/
+java classname=org.apache.catalina.startup.Catalina fork=true
classpath location=${build.dir}/classes/
+ classpath refid=alljars /
+ classpath refid=jasperjars /
+ classpath location=${ant.home}/lib/xercesImpl.jar /
+ classpath location=${ant.home}/lib/xml-apis.jar /
+ classpath location=${ant.home}/lib/ant.jar /
+ classpath location=${java.home}/lib/rt.jar /
+ classpath location=${tools.jar} /
+ arg value=start /
+ sysproperty key=catalina.home value=${build.dir}/
+ sysproperty key=build.compiler value=jikes/
+ sysproperty key=java.endorsed.dirs
value=${ant.home}/lib:${java.home}/lib/
/java
/target
--
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: [PATCH] [jakarta-servletapi-5]
Jean-François, These are already in the jakarta-servletapi-5 workspace and will be available in servlet.jar with the patch to jakarta-servletapi-5/build.xml that I posted last night. So, this patch should *not* be applied. Patrick Jean-francois Arcand wrote: Hi , attached is the remaining XML schema that need to be available locally. src/share/dtd/j2ee_1_4.xsd src/share/dtd/web-app_2_4.xsd src/share/dtd/jsp_2_0.xsd src/share/dtd/jsptaglibrary_2_0.xsd Thanks, -- Jeanfrancois -- 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: New coyote branch
Justy, I verified that Tomcat 5 builds and runs and most of the servlet tests in Watchdog pass with the current Coyote connector. Of course, I don't think any of the changes in the proposed 2.4 spec have been implemented yet. Are there any changes to Coyote that are explicitly or implicitly required by the spec? Or is the problem that API changes to the javax/servlet classes that are required by the new spec will cause Coyote to not build? Thanks, Patrick [EMAIL PROTECTED] wrote: On Wed, 31 Jul 2002, Peter Lin wrote: Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like jakarta-tomcat-connectors has been branched yet. I checked the archives and saw the vote results where it was decided that the HEAD of jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would be branched. I'd like to request that this branch be created. Remy? The reason I ask is that I'm working on a servlet 2.4 servlet request events implementation which involves modifying CoyoteRequest.java. What kind of changes ? Coyote should be independent of servlet, if you need to add something you can add it to the main branch. 2.4 should be backward compatible - so it shouldn't change any behavior. 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: Daemon deps
Costin, Remy can probably comment on the commons-daemon.jar dependency. However, the commons-launcher.jar dependency is required for the scripts in the bin directory. Patrick [EMAIL PROTECTED] wrote: Would it be possible to remove the dependency on Daemon ? I see no reason why Daemon couldn't use introspection to call start/stop/destroy. 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: cvs commit: jakarta-tomcat-5 build.properties.default
Costin,
If these are required, shouldn't they be added to the BUILDING.txt
instructions and the build.xml's download task as well?
BTW, I just did a clean build without your 3 new dependencies and ran
watchdog against it (11 JSP test fail). I noticed that the
jakarta-tomcat-jasper/jasper2 build does not complain that these
dependencies are not available. If they are really required dependencies
of JSP, shouldn't the jasper2 build check for them and put them in its
build output?
Patrick
[EMAIL PROTECTED] wrote:
costin 2002/08/01 10:30:39
Modified:.build.properties.default
Log:
Add properties for log4j ( if you build in 1.3 ) and jaxen/saxpath.
The last 2 are needed by taglibs which is required by jasper2.
( the files are checked in taglibs )
Revision ChangesPath
1.14 +14 -1 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- build.properties.default1 Aug 2002 14:30:36 - 1.13
+++ build.properties.default1 Aug 2002 17:30:39 - 1.14
@@ -39,6 +39,7 @@
# - Default Base Path for Dependent Packages -
+#base.path=/usr/share/java
base.path=/usr/local
@@ -119,6 +120,18 @@
activation.home=${base.path}/jaf-1.0.1
activation.lib=${activation.home}
activation.jar=${activation.lib}/activation.jar
+
+# - Log4j -
+log4j.home=${base.path}/log4j
+log4j.jar=${log4j.home}/log4j.jar
+
+# - Jaxen ( required by taglibs/standard required by jasper ) -
+jaxen.home=${base.path}/jaxen-1.0-FCS
+jaxen.jar=${jaxen.home}/jaxen-full.jar
+
+# - Saxpath ( required by taglibs/standard required by jasper ) -
+saxpath.home=${base.path}/saxpath-1.0-FCS
+saxpath.jar=${saxpath.home}/saxpath.jar
# - Commons DBCP, version 20011030 or later -
--
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: Daemon deps
Costin, You can invoke Tomcat's main() directly. commons-launcher.jar is only required for the Launcher. The Launcher is really only a substitute for the old shell scripts. Ultimately, the Launcher uses reflection to invoke Tomcat's main() method. So, commons-launcher.jar is only a dependency if you want to distribute the catalina.[sh|bat] scripts in that are in the bin directory. If you are embedding Tomcat 5 (like Sun does with J2EE), you do not need commons-launcher.jar at all. Or, if you want to ship Tomcat with your own customized scripts (like Sun does with JWSDP), you do not need commons-launcher.jar either. Hope that clears things up, Patrick [EMAIL PROTECTED] wrote: On Thu, 1 Aug 2002, Patrick Luby wrote: Costin, Remy can probably comment on the commons-daemon.jar dependency. However, the commons-launcher.jar dependency is required for the scripts in the bin directory. Can you expand a bit ? Catalina itself should't depend on any of those - it should be possible to start it ( or embed it ) by just calling main(). If we want to use commons-daemon or launcher - that's fine, but that shouldn't require deps - launcher or daemon can use introspection. My 'favorite' method of starting will be JMX - I know one application that will use ant tasks to start tomcat, etc. I see no reason to have hard deps on any of those. Costin Patrick [EMAIL PROTECTED] wrote: Would it be possible to remove the dependency on Daemon ? I see no reason why Daemon couldn't use introspection to call start/stop/destroy. 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] -- 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: Daemon deps
Costin, After my last e-mail, I realized that there is one build dependency on commons-launcher.jar in jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaLaunchFilter.java. The good news is that Tomcat's main() has no runtime dependency on this class. It only has a build dependency because of the source directory that I put it in. I will move the CatalinaLaunchFilter class to its own separate package so that it can be easily excluded from the build if you are not using the Launcher in your distribution. Patrick [EMAIL PROTECTED] wrote: On Thu, 1 Aug 2002, Patrick Luby wrote: Costin, Remy can probably comment on the commons-daemon.jar dependency. However, the commons-launcher.jar dependency is required for the scripts in the bin directory. Can you expand a bit ? Catalina itself should't depend on any of those - it should be possible to start it ( or embed it ) by just calling main(). If we want to use commons-daemon or launcher - that's fine, but that shouldn't require deps - launcher or daemon can use introspection. My 'favorite' method of starting will be JMX - I know one application that will use ant tasks to start tomcat, etc. I see no reason to have hard deps on any of those. Costin Patrick [EMAIL PROTECTED] wrote: Would it be possible to remove the dependency on Daemon ? I see no reason why Daemon couldn't use introspection to call start/stop/destroy. 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] -- 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]
[PATCH] jakarta-servletapi-5
Please apply the attached patch. It adds all of the new *.xsd files to
the servlet.jar.
Also, please cvs remove the following file as it does not appear to be used:
src/share/dtd/web-app_2_3.dtd.backup
Thanks,
Patrick
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/build.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 build.xml
--- build.xml 16 Jul 2002 16:38:40 - 1.1.1.1
+++ build.xml 1 Aug 2002 04:24:42 -
@@ -71,16 +71,21 @@
!-- Servlet resources --
copy todir=${servletapi.build}/classes/javax/servlet/resources
-fileset dir=src/share/dtd
- include name=web-app*.dtd/
+fileset dir=src/share/dtd includes=*.dtd,*.xsd
+ exclude name=jsp*.dtd/
+ exclude name=jsp*.xsd/
+ exclude name=web-jsp*.dtd/
+ exclude name=web-jsp*.xsd/
/fileset
/copy
!-- JSP resources --
copy todir=${servletapi.build}/classes/javax/servlet/jsp/resources
fileset dir=src/share/dtd
- include name=web-jsptaglibrary*.dtd/
- include name=jspxml.*/
+ include name=jsp*.dtd/
+ include name=jsp*.xsd/
+ include name=web-jsp*.dtd/
+ include name=web-jsp*.xsd/
/fileset
/copy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] mbean-names [logging]
Bob,
Bob Herrmann wrote:
Just so I get an idea of the scale of changes.. Tomcat has a lot of code
that uses a pattern like this;
private void log(String message) {
Logger logger = null;
if (container != null)
logger = container.getLogger();
if (logger != null) {
logger.log(getName() + [ + container.getName() + ]:
+ message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();
System.out.println(getName() + [ + containerName
+ ]: + message);
}
}
Would the 5.0 logging look more like this ?? ( I am just changing the
System.out calls to instead defer to a commons-logging logger. )
private void log(String message) {
Logger logger = null;
if (container != null)
logger = container.getLogger();
if (logger != null) {
logger.log(getName() + [ + container.getName() + ]:
+ message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();
//import org.apache.commons.logging.Log;
//import org.apache.commons.logging.LogFactory;
Log log = LogFactory.getLog( containerName );
log.info( getName() + [ + containerName
+ ]: + message);
}
}
(Note that commons-logging is going to record the log method (and not
the caller's) method in the logging output)
+1 for this type of change. Even though commons-logging will record the
log method, IMHO this is an incremental improvement over using
System.out directly.
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]
[PATCH][jakarta-servletapi-5]
Attached is a patch that updates all of the Servlet 2.3 references to
Servlet 2.4 and JSP 1.2 references to JSP 2.0.
Can someone with commit access to the jakarta-servletapi-5 repository
please commit this patch?
Thanks,
Patrick
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
? diff.txt
Index: src/share/dtd/web-jsptaglibrary_2_0.dtd
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/dtd/web-jsptaglibrary_2_0.dtd,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 web-jsptaglibrary_2_0.dtd
--- src/share/dtd/web-jsptaglibrary_2_0.dtd 16 Jul 2002 16:38:40 - 1.1.1.1
+++ src/share/dtd/web-jsptaglibrary_2_0.dtd 30 Jul 2002 15:09:11 -
@@ -164,7 +164,7 @@
The listener-class element declares a class in the application that
must be registered as a web application listener bean. See the
-Servlet 2.3 specification for details.
+Servlet 2.4 specification for details.
--
!ELEMENT listener-class (#PCDATA)
Index: src/share/javax/servlet/jsp/tagext/TagInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/TagInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TagInfo.java
--- src/share/javax/servlet/jsp/tagext/TagInfo.java 16 Jul 2002 16:38:41 -
1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/TagInfo.java 30 Jul 2002 15:09:11 -
@@ -131,7 +131,7 @@
}
/**
- * Constructor for TagInfo from data in the JSP 1.2 format for TLD.
+ * Constructor for TagInfo from data in the JSP 2.0 format for TLD.
* This class is to be instantiated only from the TagLibrary code
* under request from some JSP code that is parsing a
* TLD (Tag Library Descriptor).
@@ -381,7 +381,7 @@
}
-// == JSP 1.2 TLD Information
+// == JSP 2.0 TLD Information
/**
Index: src/share/javax/servlet/jsp/tagext/TagVariableInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/TagVariableInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TagVariableInfo.java
--- src/share/javax/servlet/jsp/tagext/TagVariableInfo.java 16 Jul 2002 16:38:41
- 1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/TagVariableInfo.java 30 Jul 2002 15:09:11
+-
@@ -62,7 +62,7 @@
*
* This object should be immutable.
*
- * This information is only available in JSP 1.2 format
+ * This information is only available in JSP 2.0 format
*/
public class TagVariableInfo {
Index: src/share/javax/servlet/jsp/tagext/VariableInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/VariableInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 VariableInfo.java
--- src/share/javax/servlet/jsp/tagext/VariableInfo.java16 Jul 2002 16:38:41
- 1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/VariableInfo.java30 Jul 2002 15:09:11
+-
@@ -78,7 +78,7 @@
* p
* If a Fully Qualified Class Name is provided, it should refer to a
* class that should be in the CLASSPATH for the Web Application (see
- * Servlet 2.3 specification - essentially it is WEB-INF/lib and
+ * Servlet 2.4 specification - essentially it is WEB-INF/lib and
* WEB-INF/classes). Failure to be so will lead to a translation-time
* error.
*
@@ -87,7 +87,7 @@
* the class name must be that of a public class in the context of the
* import directives of the page where the custom action appears (will
* check if there is a JLS verbiage to refer to). The class must also
- * be in the CLASSPATH for the Web Application (see Servlet 2.3
+ * be in the CLASSPATH for the Web Application (see Servlet 2.4
* specification - essentially it is WEB-INF/lib and
* WEB-INF/classes). Failure to be so will lead to a translation-time
* error.
@@ -122,7 +122,7 @@
* IMG src=doc-files/VariableInfo-1.gif/
*
*p
- * The JSP 1.2 specification defines the interpretation of 3 values:
+ * The JSP 2.0 specification defines the interpretation of 3 values:
*
* ul
* li NESTED, if the scripting variable is available between
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] 5.0 jakarta-tomcat-5 building
Bob,
I just committed your patch. As for your questions, your subject was
very clear which repository this goes in. Also, I personally prefer mime
attachments as then I don't need to hack out all of a submitter's e-mail
content.
Thanks,
Patrick
Bob Herrmann wrote:
I had a near flawless build experience building tomcat 5.0.
I only had to reverse the digester and commons-logging in build.xml
This is because the digester now depends on commons-logging
Can someone please patch this in? Thanks.
Cheers,
-bob
P.S. Should patch files be attached as mime-attachments?
P.P.S. Does my subject line correctly direct this message?
(Is there supposed to be a [5.0] first or [PATCH] or...)
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml 30 Jul 2002 22:13:49 - 1.12
+++ build.xml 31 Jul 2002 02:26:50 -
@@ -480,16 +480,6 @@
param name=destfile value=${commons-collections.jar}/
/antcall
-antcall target=cvsbuild
- param name=location value=${commons-digester.loc}/
- param name=subdir value=${commons-digester.home}/
- param name=destfile value=${commons-digester.jar}/
-/antcall
-copy
- file=${commons-digester.home}/dist/commons-digester.jar
- tofile=${commons-digester.jar}
-/
-
!-- we need the release to happend, in the meantime use cvs...
antcall target=downloadgz
param name=sourcefile value=${commons-logging.loc}/
@@ -510,6 +500,17 @@
file=${commons-logging.home}/dist/commons-logging-api.jar
tofile=${commons-logging-api.jar}
/
+
+antcall target=cvsbuild
+ param name=location value=${commons-digester.loc}/
+ param name=subdir value=${commons-digester.home}/
+ param name=destfile value=${commons-digester.jar}/
+/antcall
+copy
+ file=${commons-digester.home}/dist/commons-digester.jar
+ tofile=${commons-digester.jar}
+/
+
antcall target=downloadgz
param name=sourcefile value=${regexp.loc}/
--
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: JDK 1.4 Logging
;
else if ( verbosity == DEBUG ) jlevel = Level.FINE;
logCallerStack( jlevel, message, throwable );
}
/**
* Writes the specified message to a the logger
*
* @param message A codeString/code specifying the message to be logged
*/
public void log(String message) {
logCallerStack( Level.INFO, message, null );
}
// Private Methods
/**
* Writes the specified message to a the logger and attempts to unroll
* the stack to include the Class and method of the caller. Trys to be
* clever by detecting other wrappers around logging (ie. frames with
* methods name log() and internalLog() are skipped in determing the
* messages stack of origin)
*
* @param jLevel A codejava.util.logging.Level/code instance to indicate the
desired logging level
* @param message A codeString/code specifying the message to be logged
* @param throwable The codeThrowable/code error or exception
*/
private void logCallerStack( Level jlevel, String message, Throwable throwable ){
// Hack (?) to get the stack trace.
Throwable dummyException=new Throwable();
StackTraceElement locations[]=dummyException.getStackTrace();
// Caller will be the third element
String cname=unknown;
String method=unknown;
// tomcat has methods named log() and internalLog() that are sometimes on the
stack
if( locations!=null locations.length 2 ) {
StackTraceElement caller=null;
for (int stackLevel=2;stackLevellocations.length;stackLevel++){
caller = locations[stackLevel];
method=caller.getMethodName();
if ( !method.equals(log) !method.equals(internalLog) ){
cname=caller.getClassName();
// method += [DEPTH +stackLevel+]; uncomment this to see how
much stack walking is going on.
break;
}
}
}
if( throwable==null ) {
jlog.logp( jlevel, cname, method, message );
} else {
jlog.logp( jlevel, cname, method, message, throwable );
}
}
// -- Lifecycle Methods
/**
* Add a lifecycle event listener to this component.
*
* @param listener The listener to add
*/
public void addLifecycleListener(LifecycleListener listener) {
lifecycle.addLifecycleListener(listener);
}
/**
* Get the lifecycle listeners associated with this lifecycle. If this
* Lifecycle has no listeners registered, a zero-length array is returned.
*/
public LifecycleListener[] findLifecycleListeners() {
return lifecycle.findLifecycleListeners();
}
/**
* Remove a lifecycle event listener from this component.
*
* @param listener The listener to add
*/
public void removeLifecycleListener(LifecycleListener listener) {
lifecycle.removeLifecycleListener(listener);
}
/**
* Prepare for the beginning of active use of the public methods of this
* component. This method should be called after codeconfigure()/code,
* and before any of the public methods of the component are utilized.
*
* @exception LifecycleException if this component detects a fatal error
* that prevents this component from being used
*/
public void start() throws LifecycleException {
// Validate and update our current component state
if (started)
throw new LifecycleException( alreadyStarted);
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
}
/**
* Gracefully terminate the active use of the public methods of this
* component. This method should be the last one called on a given
* instance of this component.
*
* @exception LifecycleException if this component detects a fatal error
* that needs to be reported
*/
public void stop() throws LifecycleException {
// Validate and update our current component state
if (!started)
throw new LifecycleException(notStarted);
lifecycle.fireLifecycleEvent(STOP_EVENT, null);
started = false;
}
}
--
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
Re: JDK 1.4 Logging
Bob, That would work. I forgot that Remy now puts out a JDK 1.4 build of Tomcat and using the build flags would allow it to be picked up by users of the JDK 1.4 builds. Patrick Bob Herrmann wrote: Humm... How about this instead (not that I am lazy)? $ cvs diff -u catalina/build.xml Index: catalina/build.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v retrieving revision 1.124 diff -u -r1.124 build.xml --- catalina/build.xml29 Jun 2002 01:00:04 - 1.124 +++ catalina/build.xml22 Jul 2002 16:31:07 - @@ -801,6 +801,8 @@ unless=jdk.1.3.present/ exclude name=org/apache/catalina/servlets/CGIServlet.java unless=jdk.1.3.present/ + exclude name=org/apache/catalina/logger/JdkLogger.java + unless=jdk.1.4.present/ exclude name=org/apache/naming/NamingService.java unless=compile.jmx/ exclude name=org/apache/naming/factory/DbcpDataSourceFactory.java On Mon, 2002-07-22 at 12:28, Patrick Luby wrote: Bob, This is a useful piece of code. However, your patch can't go into Tomcat as it will only compile with JDK 1.4. The standard builds of Tomcat that are downloadable from the jakarta.apache.org are built using JDK 1.3 and should be run without crashing Tomcat on JDK 1.2. So, if you would like this in Tomcat (and I think it would be a nice optional logger implementation), I think that you need to do the following: 1. Remove all of the following import statements and replace them with reflection calls so that the JDK 1.3 compiler can compile this class: import java.util.logging.Logger; import java.util.logging.Level; import java.util.logging.Formatter; import java.util.logging.Handler; import java.util.logging.LogRecord; 2. Catch any ClassNotFound and MethodNotFound exceptions that will occur when the code is run on JDK 1.2 or 1.3. Patrick Bob Herrmann wrote: Hi. I am trying to get Tomcat to log to JDK1.4's logging. I tried implementing a o.a.c.logging.Logger subclass that forwarded calls to commons-logging Log. This was unsatisfying because the commons-logger unrolls the stack and logs the class.method of my logger, not my logger's caller. I was tempted to change the commons-logger to allow for specifying a class and method on all its methods, but that would be a large change the commons-logger (involving changes and decisions about how this new information should be pushed down and handled with the other loggers it supports.) There is also some issues mapping tomcat verbosity levels, to common-logger log levels and then to JDK Logger levels. So I punted and implemented the code below. It is a o.a.c.logging.Logger which writes directly to JDK 1.4 Logging. It allowed me to unroll the stack in a way that fits well with tomcat (ignoring stack frames calling with method log() or method internalLog() which are uninteresting.) And allowed me to map verbosity to JDK Levels. Cheers, -bob /* * $Header: $ * $Revision: $ * $Date: $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL
Re: [PROPOSAL] Split the repo's
All, Patrick Luby wrote: I tend to agree with Jon on this issue. When I voted for a java-servletapi-5 repository, I made the - I think reasonable - assumption that the java-servletapi-5 repository would only contain the JSR-154 code. After all, the java-servletapi-4 repository has, for as long as I can remember, only contained javax.servlet.* classes. Oops. The javax.servlet.jsp.* packages have been in jakarta-servlet-4 for a long time. In any case, I tried seeing if this issue could be solved by merely moving the javax.servlet.jsp.* packages over to the jakarta-tomcat-jasper repository. Unfortunately, that breaks the jakarta-taglibs code that jakarta-tomcat-jasper depend on. I suspect that there are other projects that may expect the javax.servlet.jsp.* package to be in servlet.jar as well. :( So, even though I don't like the current structure and I think it would be cleaner to have the javax.servlet.jsp.* packages separated from the javax.servlet.* packages, separating them may cause a lot of pain for others who have come to depend on the current structure. I feel that I should take this into my vote and, hence, I am changing my vote to: [X] I don't want the API's split into separate repo's [ ] I don't care [ ] I want the API's split into separate repo's. 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: Cygwin Path for Tomcat 4.0.4
Boon, I have committed your patch to both the HEAD and 4.0 branch of Tomcat. Patrick Boon Hian Tek wrote: Hi, I am not sure if everyone else's configuration for cygwin is different. But I had to change the catalina.sh so that it converts the CATALINA_BASE to windows format path before it will work. not work for me # For Cygwin, switch paths to Windows format before running java if $cygwin; then JAVA_HOME=`cygpath --path --windows $JAVA_HOME` CATALINA_HOME=`cygpath --path --windows $CATALINA_HOME` CLASSPATH=`cygpath --path --windows $CLASSPATH` JSSE_HOME=`cygpath --path --windows $JSSE_HOME` fi /not work for me works now # For Cygwin, switch paths to Windows format before running java if $cygwin; then JAVA_HOME=`cygpath --path --windows $JAVA_HOME` CATALINA_HOME=`cygpath --path --windows $CATALINA_HOME` CATALINA_BASE=`cygpath --path --windows $CATALINA_BASE` CLASSPATH=`cygpath --path --windows $CLASSPATH` JSSE_HOME=`cygpath --path --windows $JSSE_HOME` fi works now Regards, Boon -- 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: [PROPOSAL] Split the repo's
Jon Scott Stevens wrote: [ ] I don't want the API's split into separate repo's [ ] I don't care [X] I want the API's split into separate repo's. -jon I tend to agree with Jon on this issue. When I voted for a java-servletapi-5 repository, I made the - I think reasonable - assumption that the java-servletapi-5 repository would only contain the JSR-154 code. After all, the java-servletapi-4 repository has, for as long as I can remember, only contained javax.servlet.* classes. My feeling is that the jakarta-tomcat-jasper code should have the java-servletapi-[4|5] repositories as a dependency but no JSP code should actually be checked into the java-serlvetapi-[4|5] repository. I am OK with the jakarta-tomcat-jasper build can extract all of the javax.servlet.* classes and put them into its own jar. However, JSR-154 requires no dependencies on JSR-152. Hence, putting JSP code in the Servlet repository forces a dependency that should not be there. 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: New branches and repositories
Craig, These modules are not accessible to the anoncvs user. Is there anything we need to do to make that work? Thanks, Patrick Craig R. McClanahan wrote: The new repositories (jakarta-servletapi-5, jakarta-tomcat-5, and jakarta-tomcat-catalina) have been set up with just a LICENSE file checked in. Craig On Fri, 12 Jul 2002, Remy Maucherat wrote: Date: Fri, 12 Jul 2002 10:52:22 +0200 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: New branches and repositories So it looks like the vote result (nearly everyone who voted +1 to the 5.0 proposal voted, and there's a clear majority for the winning choices) is: A) Use new jakarta-servletapi-5 (a root will need to create it) B) Use new jakarta-tomcat-catalina (a root will need to create it) C) Use HEAD of jakarta-tomcat-connectors (I will create the branch for Coyote 1.0) D) Use new jakarta-tomcat-5 (a root will need to create it) E) Use HEAD of jakarta-tomcat-jasper (I will create the branch for the current Jasper2 code) Remy -- 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] -- _ 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.0] [VOTE] New branches and repositories
Remy, Below are my votes. I like the idea of using repositories without versions numbers for the Catalina, Jasper, and Tomcat code. It always seemed to me to be a pain to create a new CVS repository every time there is a new release instead of just creating a branch for the old release. Patrick Remy Maucherat wrote: ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [ ] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [X] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- 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: Use TreeControl in apps?
Carsten, I am no licensing expert, but I believe that the Apache license allows you to use to any of the Tomcat source code (including the TreeControl). Patrick Carsten Burghardt wrote: Hi, I'm currently looking for a nice tree control to integrate in a struts project. Is it possible to integrate the TreeControl from the Tomcat 4.1-admin webapp? I didn't find any other good one... Regards, Carsten Burghardt -- 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: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
% org.apache.jasper.JspC %CMD_LINE_ARGS% :end 1.9 +6 -2 jakarta-tomcat-4.0/jasper/src/bin/jasper.sh Index: jasper.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jasper.sh 30 Jan 2002 22:13:50 - 1.8 +++ jasper.sh 1 Apr 2002 00:13:23 - 1.9 @@ -14,7 +14,7 @@ # JAVA_OPTS (Optional) Java runtime options used when the start, # stop, or run command is executed. # -# $Id: jasper.sh,v 1.8 2002/01/30 22:13:50 patrickl Exp $ +# $Id: jasper.sh,v 1.9 2002/04/01 00:13:23 patrickl Exp $ # - # OS specific support. $var _must_ be set to either true or false. @@ -68,6 +68,9 @@ CLASSPATH=$CLASSPATH:$i done CLASSPATH=$CLASSPATH:$JASPER_HOME/shared/classes +for i in $JAVA_HOME/jre/lib/ext/*.jar; do + CLASSPATH=$CLASSPATH:$i +done # For Cygwin, switch paths to Windows format before running java if $cygwin; then @@ -82,7 +85,8 @@ shift exec $_RUNJAVA $JAVA_OPTS $JASPER_OPTS \ --Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \ +-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS \ +-Djava.ext.dirs=$JAVA_EXT_DIRS -classpath $CLASSPATH \ -Djasper.home=$JASPER_HOME \ org.apache.jasper.JspC $@ -- 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] -- 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: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy, Remy Maucherat wrote: Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. BTW, I can eliminate the use of a separate classloader and put the jre/lib/ext directory in the existing catalinaLoader and sharedLoader instances. However, to do this, I need to change the getClassPath() method in JspEngineContext.java so that it returns a classpath that is consistent with the classloaders' search order. Right now, the getClassPath() method (which is used for all JSP compilation) returns a classpath in the exact opposite order of the order used by the sharedLoader classloader. I originally put the extra classloader in to work around this getClassPath() bug. However, given the JDK 1.4 differences in the classloader delegation behavior, I think it would be better for me to fix the getClassPath() problem and move the jre/lib/ext directory into the existing catalinaLoader and sharedLoader instances like we do for the endorsed directories. Costin, Does this sound reasonable to you? Thanks, 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: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy and Costin, I will reverse the patch since there are enough -1s on this. One question: should we continue to set the -Djava.ext.dirs= in the wrapper scripts? This disables the extensions but without any code change to Tomcat. Or do we want to revert back to the original scripts where the extensions are enabled by default? Patrick Remy Maucherat wrote: Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. I had missed that it was attempting to change the delegation model (apparently, Costin didn't, that's why he was complaining, I suppose ;-)). I'm -1 for the patch then; please revert it. The use case is clearly not worth introducing non-compliant behavior; I fully agree with Costin here: if the ext mechanism is broken, then it's up to the JDK to fix it. Remy -- 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]
Another proposal for java.ext.dirs
All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, 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: Another proposal for java.ext.dirs
Costin, [EMAIL PROTECTED] wrote: Are you sure we need all this ? The .sh/.bat is already too complex. A simple check ( in java ) for the things that we care about should be more than enough, adding another config option and env variable is too much. I have to admit that using the scripts is a messy way to handle this problem. I am still trying to find a way to get the java.endorsed.dirs property out of the scripts. The intent of the ext/ is to simplify the user's life - so they don't have to set CLASSPATH. It doesn't work out in most cases. I agree. It is one of those tradeoffs: you can customize your JDK, but it may not work with your applications. If we want to disable it - fine, but I don't like making the user's life even harder by forcing him to remember and set yet another env variable. I expect the 'regular' user will use ext/, most advanced users are well aware of the problems and they already know how to deal with that. I remain -0 - if you really think this is a problem that must be solved, I won't veto it. I don't think I will commit this proposed change. After thinking about it, I don't think a hacky script change is a real solution. Since this a problem that affects nearly all Java applications (ant complained when I forgot to delete the jaxp.jar that I put in my jre/lib/ext directory), I am starting to think that this may be a problem where the cure is more painful than the problem. Patrick Costin On Mon, 1 Apr 2002, Patrick Luby wrote: All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, 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] -- 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: servlet.jar, /ext, MANIFEST.MF
Christopher, I just committed the changes to the jakarta-tomcat-4.0 HEAD branch. Can you give it a try? With these changes, Tomcat should load its own bundled jar and class files before any of the jar files in the JDK's installed extensions are loaded. I tested this by putting servlet.jar in my JDK's jre/lib/ext directory and then inserted a broken version of the javax.servlet.http.HttpServlet class (my broken version extended Object and had no methods) into the jar so that if the servlet.jar in the JDK's jre/lib/ext directory is used, Tomcat will throw tons of exceptions. Let me know if you find any problems with my changes. Thanks, Patrick Christopher K. St. John wrote: Patrick Luby wrote: I can't help but think that there might be a way to point Tomcat to its bundled jars without losing access to any non-conflicting extensions. That would be better. (but the servletapi still should have the appropriate version info :-) ... have the class loaders in Bootstrap.java add the jars in the JVM's jre/lib/ext directory to the end of its search list. Hmm. To match the spec, I think there would need to be a new classloader on top of all of those. Something like: ExtClassLoader (pithed) | AppClassLoader (as normal) | Catalina /ext (new: loads /ext classes) | Common(as normal) ... Which means that stuff loaded from the classpath won't have access to extensions, so that's still not quite right. Since Tomcat closely controls what's on the classpath I'm not sure how much of an issues that is, but it's definitely a bit different than normal. I'd settle for just having Tomcat print an error message if there was a conflict, but if the classloader hacks can be made to work that would obviously be better. -- 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: JSP won't load but servlets do
Raphael, The real problem is this: java.lang.NoClassDefFoundError: sun/tools/javac/Main This means that the tools.jar file is not in Tomcat's classpath. Tomcat will look for this file in the %JAVA_HOME%\lib directory. If there is no tools.jar file in that directory, your problem is one of the following: 1. %JAVA_HOME% is set to the JDK's jre subdirectory - If this is the case, reset %JAVA_HOME% to the parent directory of your current %JAVA_HOME%. 2. %JAVA_HOME% points to a JRE installation - If this is the case (i.e. if there is no javac.exe command in your %JAVA_HOME%\bin directory) you need to install the full Java 2 SDK since Tomcat needs the javac compiler. Patrick Raphael Di Cicco wrote: Hi, I have installed a Jakarta Tomcat web server on a Windows 2000 server machine. To do that I have installed the JDK 1.3.1 and added the environment variable. Then I installed Tomcat 4.0.2 and added the environment variable. I can properly load the server main page by going to http://localhost:8080/ in this page I can test any servlet example : they are all working But when I try to use any JSP example I have an exception(http 500) : type Exception report message Internal Server Error description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: sun/tools/javac/Main at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:485) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at . root cause java.lang.NoClassDefFoundError: sun/tools/javac/Main at org.apache.jasper.compiler.SunJavaCompiler.compile(SunJavaCompiler.java:136) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:272) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:177) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:189) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at It used to work well before and I don't see anything wrong with my install, do you ? Is it because I am using Windows 2000 where I used to run Windows NT ? Thanks for your help Raphael -- 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: servlet.jar, /ext, MANIFEST.MF
Christopher, There is an easier solution, although it has limits. Since the Tomcat binaries include servlet.jar, we can put -Djava.ext.dirs= as an argument in the Tomcat scripts. This argument causes the JVM to ignore any jars in its jre/lib/ext directory so that there is no conflict between the jars shipped with your application (Tomcat in this case) and the jars in your JVM's jre/lib/ext directory. I think that this solution may also eliminate the vexing problem where the JSSE jars are in jre/lib/ext as well. Does this sound like a reasonable solution? If so, I can implement this in the Tomcat scripts with minimal effort. Patrick Christopher K. St. John wrote: The JDK documentation indicates that servlet.jar, as an official optional package, should be placed in the /lib/ext directory. [1] However, the Tomcat 4 documentation (well, the mailing list) indicates that servlet.jar should not be placed in /lib/ext. [2] Catalina should be able to detect problems using java.lang.Package methods to query the version of the provided javax.servlet packages. It looks like this would require: 1) jakara-servletapi-4 to provide a manifest with the appropriate version information. 2) Catalina to check the version information at some point, perhaps optionally. Is this a reasonable thing to do? I admit to a cosiderable amount of confusion over the balance between theory [3],[4],[5] and practice. Any feedback/clarification greatly appreciated. [1] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html 4th paragraph of the Introduction uses servlet.jar as an example of something that definitely belongs in /ext. I'm not trying to argue about it, I'm just pointing out that the documentation conflicts with common practice. I've gotten into arguments with people who insist it's ok because of the extensions spec says, specifically, that it is. [2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5523, ref Additional Comments, also: http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg15098.html ref para starting TOMCAT-USER gets 10 or so messages a week. [3] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html [4] http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html [5] SRV.9.7.1 Dependencies On Extensions. Yes, I know, it isn't quite the same thing. -- 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: servlet.jar, /ext, MANIFEST.MF
Christopher, Christopher K. St. John wrote: But wouldn't that mean that legitimate exetensions were ignored? Yes, they would be ignored. Although this is a limitation, it might be a reasonable one when you consider all the potential problems that can be caused by putting XML parsers, JSSE implementations, etc. that are different than the ones that Tomcat expects in your jre/lib/ext directory. 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: servlet.jar, /ext, MANIFEST.MF
Christopher, Christopher K. St. John wrote: That seems a bit hostile. The majority of stuff that could go into /ext is harmless. Ignoring it punishes users who correctly install the right extensions. You have a good point. Using -Djava.ext.dirs= is an all or nothing approach and may be too limiting. My proposal was based on idea that if you can't solve a hard-to-diagnose problem, you ought to at least make it obvious. I'd be worried that ignoring /ext solves one such problem but replaces it with another. I can't help but think that there might be a way to point Tomcat to its bundled jars without losing access to any non-conflicting extensions. Since Tomcat constructs its own class loader to load its bundled jars (including servlet.jar), one possible solution would be to set the -Djava.ext.dirs= in the scripts and then have the class loaders in Bootstrap.java add the jars in the JVM's jre/lib/ext directory to the end of its search list. This way, any conflicting extensions would be loaded after the bundled jars. We use a similar mechanism to work around the endorsed dirs mechanism with JDK 1.4. Does this seem to have potential? If it works, Tomcat would be able to isolate itself from conflicting extensions (i.e. we could eliminate the problem instead of just printing an error message) while still accessing the installed extensions (e.g. JSSE, etc.). 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: servlet.jar, /ext, MANIFEST.MF
Christopher, Let me try this out later this week. I will let you know if the hack works. Also, even if the hack does not check the version info of servlet.jar, I see know harm in adding it. Patrick Christopher K. St. John wrote: Patrick Luby wrote: I can't help but think that there might be a way to point Tomcat to its bundled jars without losing access to any non-conflicting extensions. That would be better. (but the servletapi still should have the appropriate version info :-) ... have the class loaders in Bootstrap.java add the jars in the JVM's jre/lib/ext directory to the end of its search list. Hmm. To match the spec, I think there would need to be a new classloader on top of all of those. Something like: ExtClassLoader (pithed) | AppClassLoader (as normal) | Catalina /ext (new: loads /ext classes) | Common(as normal) ... Which means that stuff loaded from the classpath won't have access to extensions, so that's still not quite right. Since Tomcat closely controls what's on the classpath I'm not sure how much of an issues that is, but it's definitely a bit different than normal. I'd settle for just having Tomcat print an error message if there was a conflict, but if the classloader hacks can be made to work that would obviously be better. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- 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: bug in catalina.sh
Fabien,
Since the $@ is necessary to preserve quoting of arguments with spaces in
them, changing it to $@ is not a really good solution. First off, which Unix
platform are you using? I know that the $@ works on Solaris and Linux and Mac
OS X.
Also, have you tried using ${@}? Most platfroms don't require the curly braces
to preserve quoting, but maybe yours does.
Patrick
Fabien Nisol wrote:
Hello,
I noticed a bug in catalina.sh that make some of us have problem starting
tomcat. The common error is that a message
usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ] [
-debug ] [ -nonaming ] { start | stop }
is printed in $CATALINA_HOME/logs/catalina.out
I began to look at this problem and I finally found the bug:
The problem is that at every line where catalina is started ($_RUNJAVA
...), command line arguments that are passed to the catalina.sh script are
passed using $_RUNJAVA javaargs catalinaClass $@ command (quotes
included) ... The problem : When only one argument is passed to the VM , in
Catalina.main(String args[]), args are { , command } and not {
command } ... ( starting catalina.sh start means starting java
javaargs class start, not java javaargs class start) ...
big problem in Catalina.arguments(String[] args) where the argument
(empty string) is not recognised and issues an error on stdout...
I think the problem could be corrected by replacing all $@ (with quotes)
occurence by $@ (without quotes) in catalina.sh
Are you ok with this or am I missing something??
Fabien Nisol
java Developer/Analyst consultant
--
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: [PATCH] Typo in catalina.bat
Christopher, Good catch. I just committed your patch to the HEAD and tomcat_40_branch branches. Patrick Christopher Elkins wrote: Hi, all. The patch below fixes a typo in catalina.bat. -- Christopher Elkins Index: catalina.bat === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.25 diff -u -r1.25 catalina.bat --- catalina.bat11 Feb 2002 20:26:24 - 1.25 +++ catalina.bat19 Mar 2002 16:57:33 - @@ -87,7 +87,7 @@ if not %1 == jpda goto noJpda set JPDA=jpda -if not %JPDA_ADDRESS% == got gotJpdaAddress +if not %JPDA_ADDRESS% == goto gotJpdaAddress set JPDA_ADDRESS=jdbconn :gotJpdaAddress shift -- 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: [PATCH] Allow configurable JPDA transport in catalina.bat
Christopher, I have committed this patch and have ported it to the catalina.sh script for Unix platforms as well. Patrick Christopher Elkins wrote: Hi, all. The patch below allows the JPDA transport used in jpda start to be set via an environment variable. Unfortunately, not all debuggers support the shared memory transport (e.g., JSwat), so these changes make it possible to use the socket transport without having to modify catalina.bat locally. Moreover, this patch cleans up the slightly inaccurate comment for JPDA_ADDRESS and includes my previous patch to fix a typo (with the subject [PATCH] Typo in catalina.bat). -- Christopher Elkins Index: catalina.bat === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.25 diff -u -r1.25 catalina.bat --- catalina.bat11 Feb 2002 20:26:24 - 1.25 +++ catalina.bat19 Mar 2002 17:20:17 - @@ -27,7 +27,10 @@ rem (JSSE) installation, whose JAR files will be added to the rem system class path used to start Tomcat. rem -rem JPDA_ADDRESS(Optional) Java runtime options used when the jpda start +rem JPDA_TRANSPORT (Optional) JPDA transport used when the jpda start +rem command is executed. The default is dt_shmem. +rem +rem JPDA_ADDRESS(Optional) JPDA address used when the jpda start rem command is executed. The default is jdbconn. rem rem $Id: catalina.bat,v 1.25 2002/02/11 20:26:24 patrickl Exp $ @@ -87,7 +90,10 @@ if not %1 == jpda goto noJpda set JPDA=jpda -if not %JPDA_ADDRESS% == got gotJpdaAddress +if not %JPDA_TRANSPORT% == goto gotJpdaTransport +set JPDA_TRANSPORT=dt_shmem +:gotJpdaTransport +if not %JPDA_ADDRESS% == goto gotJpdaAddress set JPDA_ADDRESS=jdbconn :gotJpdaAddress shift @@ -174,10 +180,10 @@ goto end :doJpda if not %SECURITY_POLICY_FILE% == goto doSecurityJpda -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=dt_shmem,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doSecurityJpda -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xrunjdwp:transport=dt_shmem,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :end -- 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: setting up tomcat to accept client certificate
Kunal, This is exactly how the code is supposed to work: the certificate is *not* fetched from the client if the parameter is set to 'false'. Patrick kunal kaviraj wrote: Hi All, Whenever I try to set the parameter clientAuth=true in the server.xml to accept client certificate from the user, after restarting Tomcat starts up well, but then I get 'Cannot find server' error when I try to access the https sites. But the http sites work perfectly. But when this parameter is set to 'false' https and http both works perfectly, though the client is not asked for certificate. The server certificate I am using has been generated by keytool. The client certificate is a third party one. I am using Tomcat standalone version 4.0.1 with jdk1.3.1 I have downloaded the jsse1.0.2 and put the 3 jar files in the jdk ext path. Any pointer will be really helpful. Thanks Kunal _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- 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: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Remy, +1 for all. Patrick Remy Maucherat wrote: There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to start with some limited changes at first. Most of these proposed changes are Coyote-related (hence the subject of the message), and all involve some refactoring / API additions. A) URI decoding refactoring. To avoid doing some URI decoding in many places in the pipeline, a decodedURI field (with associated getter/setter) should be added in the HttpRequest interface, and used in the Catalina pipeline. This also has the advantage to guarantee that no double URI decoding occurs (which can lead to URI-based security attacks). ballot [ ] +1 [ ] +0 [ ] -1: /ballot B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old connector, which has many shortcoming (slow performance on output, HTTP handling limitations and extreme complexity). Initial tests results and benchmarks with Coyote are extremely positive so far. ballot [ ] +1 [ ] +0 [ ] -1: /ballot C) Add better lifecycle handling in the resources. A start method is needed (which could be called 'allocate' to mirror the 'release' method), because it is currently not possible to restart a stopped context. In the 4.0 branch, the patch introducing the 'release' method must either be reverted, or these proposed changes must also be ported to 4.0. Thanks to Jean-Francois Clere for the report and debugging of this problem. ballot [ ] +1 [ ] +0 [ ] -1: /ballot D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT* be used for any new connector development. To make this more obvious, I'd like to deprecate all classes in this package and subpackages. The binaries will also be packaged in a separate JAR file (tentatively named catalina-legacy.jar). This package will continue to be maintained on a case by case basis. The facades will not be deprecated, and two new helper objects will be introduced to handle the need for fake req/resp when requesting a JSP precompilation with a load-on-startup (see bug 4518 for more details). ballot [ ] +1 [ ] +0 [ ] -1: /ballot E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor interface. Otherwise, the processor has no way to cleanly handle logging. commons-logging is already used by other j-t-c components. At the moment, the HTTP/1.1 processor logs problems as stack traces on the stderr; this needs to be improved. When I originally designed most of the base interfaces, commons-logging didn't exist yet, and I didn't feel like adding yet another logging interface. ballot [ ] +1 [ ] +0 [ ] -1: /ballot +1 for everything. Thanks for voting / commenting :) Remy -- 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: Newbie: Basic Question
Bhai, It is hard to tell what is going on without capturing what is appearing in the window that pops up. Try running catalina run. This will keep all output in the same window so that you can see the errors. Patrick Bhai wrote: Hi, I have downloaded the tomcat source from TC web and have built it and also created a distribution. But on my Win2K machine when I do catalina start from the CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME and the CATALINA_BASE, it appears to open a new command window, which it closes instantaneously. The port 8080 on my machine is not in use and looking at the task manager it does not appear that the java instance is running. Is there some other setting that I have to do other than setting the java home and catalina home in order to run the distribution/build. my catalina home is set to c:\...jakarta-tomcat-src\dist where ant created the distributables. Please point me in the right direction. Thanks. Bhai -- _ 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: Newbie: Basic Question
Bhai, The problem is that you have a '\' character at the end of %CATALINA_HOME%. Instead of the following: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ set CATALINA_HOME to the following: C:\Programs\jakarta-tomcat-4.0.3-src\dist Patrick Bhai wrote: Hi, I have downloaded the tomcat source from TC web and have built it and also created a distribution. But on my Win2K machine when I do catalina start from the CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME and the CATALINA_BASE, it appears to open a new command window, which it closes instantaneously. The port 8080 on my machine is not in use and looking at the task manager it does not appear that the java instance is running. Is there some other setting that I have to do other than setting the java home and catalina home in order to run the distribution/build. my catalina home is set to c:\...jakarta-tomcat-src\dist where ant created the distributables. Please point me in the right direction. Thanks. Bhai, It is hard to tell what is going on without capturing what is appearing in the window that pops up. Try running catalina run. This will keep all output in the same window so that you can see the errors. Patrick Hello Patrick, That ran and I could see the output which I have pasted below. C:\Programs\jakarta-tomcat-4.0.3-src\dist\bincatalina run Using CATALINA_BASE: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ Using CATALINA_HOME: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ Using CATALINA_TMPDIR: C:\Programs\jakarta-tomcat-4.0.3-src\dist\\temp Using JAVA_HOME: C:\j2sdk1.4.0 Exception during startup processing java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:1127) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas sLoader.java:992) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:218) It cannot find the catalina.class file that is present in the catalina.jar within the dist/servers/catalina.jar file. Can you help me out. Thanks. Bhai. -- 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: Install bug tomcat4.0 on Mac Osx
Paulo, I think you may have found the the problem. For those interested in using Mac OS X, the following must be done or you will run into the Mac Classic 31 character filename limit: 1. Unpack using the Mac OS X tool gnutar command line tool only. Don't let your browser do the unpacking as sometimes Netspace or IE will automatically unpack the download file using a Mac OS 9.x tool. 2. Unpack to a HFS+ disk. If you have unpack to a HFS formatted disk, you will run into the 31 character limit. Patrick Paulo Gaspar wrote: -Original Message- From: Karim Qazi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 12:39 AM To: [EMAIL PROTECTED] Subject: Install bug tomcat4.0 on Mac Osx I downloaded the release jakarta-tomcat-4.0-20020303.tar.gz and when unpacking this release, the servlet examples/WEB-INF/classes/SetCharacterEncodingFilter.class Is unpacking as SetCharacterEnclodingFilter.clas. This is causing the examples not to function correctly. Thought you'd like to know this. Karim Qazi -- 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: [Daemon] New commons component
Remy, Remy Maucherat wrote: Ok, I'll send then an email. And would participate in the project ? If it allows me to start Tomcat and all of the other tools (e.g. jspc, etc.) without shell or batch scripts, count me in. 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: [Daemon] New commons component
Pier, Pier Fumagalli wrote: Patrick... System.loadlibrary (or however is called), does the exact opposite of what we need... We ship a binary that will load the JVM library, we don't rely on the JVM binary to load a library... Maybe I should clarify what I am trying to do. I am trying to enable the use of setuid() within the existing Tomcat startup process (i.e. shell scripts). I definitely like your native launcher and the more I look at it, the more I like its sophisticated function. I just want to make the setuid() call available even if I haven't startup Tomcat using your native launcher. The way to do that is to use the Java-JNI method of creating a shared library that contains a function with a name that matches a demangled version of a public native Java method. Then, when Tomcat is started via a script (as it does now), the StandardServer class can do the following: - Invoke System.loadLibrary() - Bind all of the ports (if you are root, you can bind to ports = 1024) - If we are root, invoke a public native method that Java maps to the C function contained in the shared library. The C function would contain the setuid() C call to change the Java process to a non-root user The above method effectively does the same thing as your native launcher. The only difference is that I thought it might be a may to get your setuid code into the standard Tomcat installations much sooner since my proposed approach is compatible with the existing Tomcat configuration and startup. I think the only changes to support my proposed approach in your native code are the following: - Add a public static native method in DaemonLoader.java - Create a DaemonLoader.h file using javah - Implement the setuid() calls for the function defined in DaemonLoader.h in DaemonLoader.c. Specifically, I could just move the child process' code in the checkuser function here so that there is not duplication of code. - Add compiling and linking of DaemonLoader.c into a shared library that the Java System.loadLibrary() call can handle. - Add calling of this public static native method from Tomcat's StandardService.initialize() method (i.e. after all ports have been bound). Also, if you need to do some callbacks from Java into our native C code, the easiest thing is to register those right after invoking CreateJavaVM in JNI (and it works), rather than relying on an external library... I was thinking that once we have the above method implemented, we could try replacing the existing scripts with the native launchers. At that point, the System.loadLibrary() call in Tomcat could be removed since the native launcher could register the JNI C function that the public native method maps to. What do you think of the above approach? Thanks, 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: [Daemon] New commons component
Remy, Remy Maucherat wrote: I agree with Pier here. I think we should only try to implement daemon fnctionality using the appropriate wrapper. Implmenting it with standard Tomcat using scripts is a nasty hack. Somehow, Patrick doesn't seem to like my BootstrapService (which works perfectly well; it's even been in use for a long time through the NT service which ships with the Windows installer) :-( I admit it: I was trying to implement a hack. I am definitely warming up to the idea of jumping straight into Pier's scripts. After all of this discussion, it doesn't seem to be so much work to switch to a native launcher to implement the setuid() stuff. Plus, I agree with Remy that the use of shell scripts to launch Tomcat is a bit nasty. I like the idea of using Pier's launcher (I assume the Windows native code has a native launcher as well?) to be able to start Tomcat via a double-click on an executable and no MS-DOS window on Windows. 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: That wouldn't work - if the UID is changed before starting tomcat, then it can't listen on port 80. The uid must be changed after it start listening, like any unix program does. And the wrapper/invocator is just one way to start tomcat - I like the flexibility on startup. This is very true and was the reason I was pursuing the public native method approach. But Pier mentioned and passing a callback function to the JVM when he starts it. Maybe Pier could elaborate on this process? Basically, for Pier's callback approach to work, the callback function would need to be tied to invocation of the StandardServer.initialize() method. I haven't used any callbacks like he describes so I am curious about the mechanics. -- _ 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: [Daemon] New commons component
Remy, Remy Maucherat wrote: At the moment, it is only a NT service, I think. The exe wrapper can (and probably should) do both. I will admit that I am no Windows expert, but can't you just have a main() function that invokes start service code. Shutdown would be a little trickier as you need to send it a signal or some other event. 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: 1. I think combining the wrappers ( any of them ) with the platform-specific native code used inside tomcat is _bad_. One of the good things about tomcat is that it can be started/mebedded in many different ways. Creating a small jni library is quite trivial - MacOS may be different, but I'm sure they provide a way and we can support it ( if we want in-process and unix sockets there we'll have to do it anyway - that's jni based ). Keep them separated - it's more flexible. I have already wrote a quick test on Mac OS X. It works just like all other platforms. The only difference is that you need to link your shared library with -bundle and name it lib.jnilib instead of lib.so. After that, System.loadLibrary() will load the library. You don't even need to link to any of the JVM's libraries to do this. 2. The 'normal' way to do this, used by all unix daemons, by all other java servers ( including JavaWebServer and any other containers except tomcat ) is to use a (jni) call to chuid. It works, it's tested and clean. I'm sure this can be obfuscated or done using whatever callbacks mechanism ( opening all the resource in the wrapper, etc) , but doing it in the natural way is better IMHO. This is why I was pursuing this approach for the last 2 days. I have seen this type of code way back when I was porting the Java Web Server's JNI code to HP-UX, AIX, and DEC Unix a few years back. Also, I believe that Apache follows this same logic path (although it doesn't need JNI to get to the C function, of course). 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: [Daemon] New commons component
Pier, I took a quick look at the code and found the RegisterNative function. This looks like an interesting feature. I also found the same function in your daemons code. The picture is becoming much clearer. Let me try to get it working in the next few days with the callback function set to invoke setuid() and have the callback invoke (via Java reflection since it won't be there on Windows or standalone start. If I can get this to work, I will post the patches first so that all can inspect. Now that I understand this approach, it basically seems to work through the same logical steps (from a Tomcat Java code) perspective as invoking the callback function via JNI. In your approach, the function is preloaded for Java (no System.loadLibrary() required) and the Java code invokes the function like any other method (it just happens that the method doesn't exist at compile time but only at runtime). Thanks, Patrick Pier Fumagalli wrote: Pier Fumagalli [EMAIL PROTECTED] wrote: Few hours... Yeah, whatever... Trivial... Pier Part 1.2Type: Macintosh File Part 1.3Type: Macintosh File Name: make.sh make.shType: Bourne Shell Program (application/x-sh) Encoding: base64 Part 1.5Type: Plain Text (text/plain) -- _ 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: [Daemon] New commons component
Pier, Pier Fumagalli wrote: IMO, it's a waste of time... You shouldn't call setuid from Java, but the native code launching the VM should call appropriate methods at appropriate moments of the lifecycle... As I said before: 1) CreateJavaVM 2) call Tomcat-initialize() (bind to ports) 3) set uid/euid/gid/egid/groups 4) call Tomcat-start() (accept connections) 5) wait for signal 6) call Tomcat-stop() 7) exit process... All the code is already in place... Just need to be tied together... I agree. I got your sample code to work on Mac OS X 10.1 and, just for kicks, had Java invoke the callback that was registered. Since you have separated out the port binding into Tomcat-initialize(), you are also correct that I don't need to call the callback function from Java. I admit my thinking was still limited to the existing constraints of the StandardServer.start() method instead of the new bootstrap classes. Next thing I will do is take a look at the bootstrap classes and test out your recommendation. RegisterNative _is_ JNI... JNI is developed on two layers, call C from Java (maybe using System.loadLibrary()), and that's what everyone knows. Call Java from C (a little bit less known, but way more powerful)... We need a JVM invocation API, not a Java callback mechanism, IMO... We used the JVM invocation API when I was working on StarOffice. However, I never ran into the RegisterNative method. Although we don't need it for the setuid() calls, I think it might come in handy sometime. That's the beauty of JNI, you can do things that you won't even believe they exist, like compiling (loading) a class when NOT all its methods are there... It's the beauty of a Class seen as an Instance of an object (and IMO the biggest advantage over things like SmallTalk)... JG thought it out good... I admit that I kept expecting there to be more work to do. But you keep surprising me with what you have already implemented. Thanks for having the patience to walk me through this. 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: [Daemon] New commons component
Pier, Hmmm. I could only find the setuid() calls in the parent process that launches Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat could use to temporarily switch the user back to root immediately before binding a ServerSocket object and then switching the user back immediately after. Maybe that code already exists somewhere else? If so, let me know where it is and I will definitely use it. BTW, I like the native startup executable that you wrote. I made a proposal to this list last week about replacing our many shell scripts (which are causing alot of nasty problems on Windows) with a launcher that uses properties files to launch Tomcat or the other related tools. I had originally thought about having a Java read the properties which would then launch Tomcat. However, you native code, especialy with its support for signals and chrooting may be a better option. Sure, I would need the native code to read some properties files to get classpath and other configurable items, but then I could directly invoke Java to run the Tomcat classes. Thanks, Patrick Pier Fumagalli wrote: Patrick Luby [EMAIL PROTECTED] wrote: Remy, This is great news! I scanned through the Unix code and noticed that it uses the chmod'ing executables with setuid bits instead of performing a JNI call to the setuid() and seteuid() C functions before and after binding of a ServerSocket (i.e. the place you should need root access if you are binding to ports 1 through 1024). This type of approach eliminates the need for a controller and slave process. Then it's not my code... My code was written using setuid() and seteuid()... Actually, the copy I have here also supports CHROOTING of the whole JVM process, and real/effective group switching (as we say in Italy, 'na botte de fero). Pier -- 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: [Daemon] New commons component
Jean-Frederic, jean-frederic clere wrote: That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native). Where is the chmod()? The idea of making setuid() and setgid() from the JVM is also possible - I will try it - I was thinking that since all ServerSocket binding is that we could implement this as a static native method so that both Tomcat 3.x and 4.x could load the shared library and invoke the calls as close as possible to the actual point that a ServerSocket object binds to the socket. In Tomcat 4.x, I believe that this point is in the createSocket() method of each ServerSocketFactory class. If you don't have time, let me know and I can try this later this week. BTW, I have access to Linux, Solaris, and Mac OS X machines (the latter from my last job porting StarOffice to Mac OS X). So let me know where I can help out as I am intimately familiar with the unique process of getting JNI code to link on Mac OS X. -- 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: How easy would it be if that was possible ? For both hackers and developers :-) If we keep this as a public static void method, these could be used by any codebase (as long as they pulled in the .jar and shared library files). Changing the uid to root is certainly impossible AFAIK ( at least on unix, on NT everything is possible, but I hope not this one ). Well, of course the process would have to be started as root and the setuid to a non-root user happens at the start of the process. Then, the JNI calls allow you to invoke setuid to switch back to the saved uid which is root (since that is the uid of the parent process). The only issue that think that may be problematic is multi-threading since all threads get switched back to root momemtarily. The reason I am proposing this tricky approach is that, at least in Tomcat 4.x, the ServerSocket binding is not all in one place in the code or, AFAIK, right at the beginning of main(). Hence, it looks like it will be impractical to do all of the socket binding and then setuid to the non-root user without moving a lot of code around. I will continue to look at this, however, because of the threading issue . The other part is possible and I think it's a very good solution. My only worry here is how much resistance there would be for native executables to launch Tomcat and/or other tools. Of course, one could also launch Java directly so maybe this will make this idea more palatable. 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: If you have the time, writing this code as part of j-t-c/jk/native2/jni would be great :-) There are many things still missing there, like in-process support for 4.x and build procedure for other platforms ( we have ant-based support for libtool, win, netware - not sure if Mac supports libtool ). Mac OS X has libtool, it is just the location of the JNI libraries at link time and the need to create a shared library with a .jnilib extension (instead of a .dylib extension like regular shared libraries :-( ). These should be fairly minor. It's better to write the native code using APR, it avoids all the ifdefs and system specific code, and it's tested already in apache. I agree, I remember all of the special #ifdefs for the location of all of the headers for Mac OS X. Costin -- _ 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: [Daemon] New commons component
Henri, There should be no requirement for Tomcat to start as root. However, some may want to run Tomcat on a port 1024. In such cases, you need to start as root but most site admins want the process to setuid to a non-root user for security reasons. Patrick GOMEZ Henri wrote: Well, of course the process would have to be started as root and the setuid to a non-root user happens at the start of the process. Then, the JNI calls allow you to invoke setuid to switch back to the saved uid which is root (since that is the uid of the parent process). The only issue that think that may be problematic is multi-threading since all threads get switched back to root momemtarily. Did there is a reason to have Tomcat 3.3/4.0 started as root ? Since they listen on port 1024, there is really no need for them to be run as root. But for site admins task, having a signal handling in Tomcat is a real need to handle task like log rotate for example. +1000 to have such interface in TC 3.3/4.0 -- 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: On Tue, 19 Feb 2002, Patrick Luby wrote: My point was that after you drop the root priviledges, there's no way to get them back. I just double checked the manual, at least on linux. Hmmm. I picked this up from the Solaris man pages. It is probably best for me to focus my efforts on finding a good place in Tomcat 4.x to setuid to a non-root user like Apache does instead of pursuing this probably platform specific use of setuid. -- _ 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: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: That would be after all connectors have opened the ports, but before _any_ user code gets executed ( including the context init which trigers loading of on-startup servlets ). In Tomcat 4.x, the last port opened is in StandardServer.await() - this is the shutdown port. The bad news is that all of the connectors are started before this call. Hence, I suspect that there is, currently, a small window for user code to get executed before the setuid would be called in StandardServer.await(). Looks like the Tomcat 4.x code in Catalina.start() will need to be reworked. However, after a quick review of the code, I don't think it is that much work. All of the connectors bind to their ports in their initialize() method and no user code, AFAIK, is executed in this method. After all connectors are intialized(), only then are the connectors started. So, I am thinking that all I need to do is move the shutdown port binding out of StandardServer.await() and into StandardServer.initialize(). Since StandardServer.initialize() invokes initialize() on all of the connectors, I can put the setuid code at the end of the StandardServer.initialize() method. Of course, this is how I think it will work so I definitely need to try it out. Maybe later this week I will have some time to try this out and make sure that it actually works. Thanks, 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: [Daemon] New commons component
Remy, This is great news! I scanned through the Unix code and noticed that it uses the chmod'ing executables with setuid bits instead of performing a JNI call to the setuid() and seteuid() C functions before and after binding of a ServerSocket (i.e. the place you should need root access if you are binding to ports 1 through 1024). This type of approach eliminates the need for a controller and slave process. If there is interest out there, I can work up a proposal for implementing this type of setuid functionality. I has been a year or two since I did my last JNI coding, but I should be able to dig up some setuid code that I have done in the past. Thanks, Patrick Remy Maucherat wrote: Hi, I've added a new component to the commons subproject (in the sandbox), which is designed to allow Java programs to run as native operating system daemons (services under Windows NT). Because of its nature, this component contains a significant amount of native code. This component API and Unix code was developed by Pier Fumagalli as part of the Tomcat 4 project, but is fully generic and not tied in any way to Tomcat, so other server side applications may find it useful. The NT service code and related utilities were written by Jean-Frederic Clere. Thanks, Remy -- 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: Java home autodiscovery add-on
Henri,
GOMEZ Henri wrote:
What about adding this part in tomcat.sh (TC 3.3) and
catalina.sh/jasper.sh to help them discover JAVA_HOME on
at least Linux systems ?
+if [ -z $JAVA_HOME ]; then
+# Search for java in PATH
+JAVA=`which java`
+if [ -z $JAVA ] ; then
+JAVA_BINDIR=`dirname ${JAVA}`
+JAVA_HOME=${JAVA_BINDIR}/..
+fi
+# Default clean JAVA_HOME
+[ -z $JAVA_HOME -a -d /usr/lib/java ] JAVA_HOME=/usr/lib/java
+# Default IBM JAVA_HOME
+[ -z $JAVA_HOME -a -d /opt/IBMJava2-13 ] JAVA_HOME=/opt/IBMJava2-13
+# Another solution
+[ -z $JAVA_HOME -a -d /usr/java/jdk ] JAVA_HOME=/usr/java/jdk
+# madeinlinux JAVA_HOME
+[ -z $JAVA_HOME -a -d /usr/local/jdk1.2.2 ]
JAVA_HOME=/usr/local/jdk1.2.2
+# Kondara JAVA_HOME
+[ -z $JAVA_HOME -a -d /usr/lib/java/jdk1.2.2 ]
JAVA_HOME=/usr/lib/java/jdk1.2.2
+# Other commonly found JAVA_HOMEs
+[ -z $JAVA_HOME -a -d /usr/jdk1.2 ] JAVA_HOME=/usr/jdk1.2
+# Default Caldera JAVA_HOME
+[ -z $JAVA_HOME -a -d /opt/java-1.3 ] JAVA_HOME=/opt/java-1.3
+# Add other locations here
+if [ -z $JAVA_HOME ]; then
+echo No JAVA_HOME specified in ${TOMCAT_CFG} and no java found, exiting...
+exit 1
+ fi
In Tomcat 4.0.2 and later, the above code would, I believe, fit into the
bin/setclasspath.sh script. This script, which already checks that your
$JAVA_HOME contains a java, javac, and jdb command, would extend that
functionality. BTW, setclasspath.sh is source by all the executable Unix scripts
(e.g. catalina.sh, jasper.sh, etc.).
Something that the Tomcat 3.3 developers may want to take a look at in
setclasspath.sh is the setting of $JAVA_ENDORSED_DIRS environment variable. This
variable is used to construct a -Djava.endorsed.dirs= argument when
invoking Java in each of teh executable Unix scripts (Windows does the same in
setclasspath.bat). This property provides the ability for Tomcat to override the
default parser and other special classes that are bundled with JDK 1.4 with the
classes that are bundled with Tomcat. This eliminates the need for users to need
to copy jar files into their JDK's lib/endorsed directory (which would affect
all other Java applications).
= TC 4.0.2 conf :
# tomcat /etc/rc.d script example configuration file
# Use with version 1.07 of the scripts or later
# Where your java installation lives
# JAVA_HOME=/usr/java/jdk
JAVA_HOME=/opt/IBMJava2-13
# You can pass some parameters to java
# here if you wish to
#JAVACMD=$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3
# Where your tomcat installation lives
# That change from previous RPM where TOMCAT_HOME
# used to be /var/tomcat.
# Now /var/tomcat will be the base for webapps only
CATALINA_HOME=@@@TCHOME@@@
JASPER_HOME=@@@TCHOME@@@
CATALINA_TMPDIR=@@@TCHOME@@@/temp
# What user should run tomcat
TOMCAT_USER=tomcat4
# You can change your tomcat locale here
#LANG=en_US
# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)
# Just do not forget to export them :)
Many may not know this, but the above configuration file already exists in
Tomcat 4.0.2 and later. The configuration files are:
Windows: bin/setenv.bat
Unix: bin/setenv.sh
These files, by default, do not exist. However, if the user creates the above
file, they can override any environment variables that they like.
Something that the Tomcat 3.3 developers may want to take a look at is that each
Unix script in Tomcat 4.0.2 and later now resolves CATALINA_HOME independently
of the user's environment. This even works if the user invokes a softlink to the
script (pretty handy if you want to put a softlink to startup.sh and shutdown.sh
in /usr/bin on your system). This, and putting JAVA_HOME=JDK path in the
setenv.sh file, allows you to run Tomcat 4.0.2 or later from an /etc/rc.d or
/etc/inittab entry.
I have found a way to do this on Windows NT, 2000, and XP, but I have not had
enough time to refine it enough so that it won't break Windows 95, 98, and ME.
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: Java home autodiscovery add-on
Henri,
GOMEZ Henri wrote:
Yes bin/setclasspath.sh does many things and could be used.
My advice it that the name is too generic and should be renamed
when you install TC 3.x/4.x in a FHS way, ie execs in
/usr/bin, datas in /var/tomcat4 or /usr/share/tomcat4.
May be renamed to setcatalinacp.sh ?
I must admit that have all these *.sh files hanging around in the bin directory
annoys even me even though I created them. I have been thinking about (but never
enough time to implement) getting rid of these scripts entirely and replacing
them with a small Java class that does the following:
- The standard scripts, e.g. catalina.sh consist only of:
Resolve true location of $0 (existing code already does this)
Find java (almost any will do for this script)
java -classpath `basedir $0` \
org.apache.catalina.launcher.Launch ${@}
- This new Launch class then can parse both the command line arguments and
a new properties file (e.g. conf/tomcat.properties) to figure out all of the
stuff that is currently in the scripts as environment variables (e.g.
classpath, JAVA_HOME, CATALINA_OPTS, System properties, etc. After parsing
all the command line arguments and properties (which are currently done by
the scripts), this Launch class would fork another Java process with the
real $JAVA_HOME that the user has configured with all of the applicable
classpath, System properties, and command line arguments.
So what advantage is there to this? Although there is no change in the
functionality of the scripts, it would solve some of the following problems:
1. Windows has many problems in its handling of environment variables such as
%0 is always meaningful, some versions don't allow an '=' in an environment
variable value (particularly vexing for Java programs), some versions have
limited environment space, the 'for' command cannot handle paths with spaces
in them, etc. Using the above method, I have made the Launch do the work
that the script is doing now.
Since Java has not problems with the above when values are put in properties
file, a lot of these Windows problems go away. More important, we would now
have a _platform_independent_ way to configure settings for Tomcat since
Java properties don't require quoting or other items that are different on
Windows and Unix (even paths can be represented in a platform independent
manner if we so choose).
2. If implemented properly, the Launch class can use any Java found in your
path to bootstrap itself (OK, I will need at least Java 1.1). I can use a
JRE or JDK. Since Launch.class would invoke the real Java that I want to
use based on a property in the conf/tomcat properties file, this means
that we can bootstrap ourselves enough to:
- Provide more meaningful error messages than we can do with shell script
if and echo statements, particularly on Windows
- Provide (someday) localized error messages
- Use your Java searching algorithm for the Find a java part of each
script. This will allow us to bootstrap Java without causing changes to
which Java Tomcat actually runs with (i.e. Christopher's concern).
3. Last, but not least, make the launching of Tomcat completely independent
of the user's environment variables. The 2 big advantages that I see are:
- System integration is easier where environment variables are difficult
to use (e.g. you can put an icon in the Windows
Start-Programs menus, you can start Tomcat from /etc/inittab, you
can make Tomcat an NT service, etc.)
- On Windows, we can log stdout and stderr to a log file (like it already
does on Unix) instead of printing the output to a MS-DOS window (it is
difficult to redirect stderr in Windows batch scripts)
Is something worth pursuing for Tomcat 4? I am willing to volunteer the effort.
Especially since it will make the Windows startup more in line with the Unix
startup. For the record, I prefer Unix (any flavor) over Windows. However, I
realize that making Tomcat work reliably on Windows is important as there are a
lot of Windows users of Tomcat out there.
Excellent information that -Djava.endorsed.dirs. Could you give us an
example of it if for example we want to use xerces-2.0.0 and xalan-2.3.0
with Sun JDK 1.4.0-rc1 ?
In theory, with the current -Djava.endorsed.dirs setting, you could drop your
favorite xerces and xalan jars in common/endorsed (HEAD branch) or common/lib
(4.0.2 branch) and Tomcat will use those. Of course, you need to remove any
existing conflicting jars from those locations first and Tomcat may have
problems with some XML parser versions (i.e. bugs in Tomcat or the XML parser).
Patrick
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems
Re: [4.0.2] [VOTE] Final release
[X] +1 - I support this release and I will help [ ] +0 - I support this release [ ] -0 - I do not support this release, because: Patrick Remy Maucherat wrote: Hi, I'd like to propose to release the current code in the 4.0 branch as Tomcat 4.0.2 Final. This release includes lots of bugfixes and improvements, especially in the connectors area, which feature a dramatic improvement over what was available in Tomcat 4.0.1 (this alone justifies making a release IMO, given the amount of problems people are experiencing with the versions packaged in Tomcat 4.0.1). The remaining should-fix bugs resolution will be postponed until a later release. None of them were regression problems. The jakarta-tomcat and jakarta-tomcat-connectors repositories will be tagged with tomcat_402. The tomcat-warp / tomcat-util / warp source will be synced with the sources in the jakarta-tomcat-connectors repository. The binaries will be packaged and be made available for verification by other committers this week-end, and the release announcement will be posted early next week (Monday seems appropriate). As discussed yesterday, the binaries will include a minimal distribution designed to be run on JDK 1.4. ballot [ ] +1 - I support this release and I will help [ ] +0 - I support this release [ ] -0 - I do not support this release, because: /ballot Remy -- 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: [4.0.2] Bug list
Remy, Can I add integrate of the wrapper script from the HEAD branch to the list? The scripts should be fully compatible with the 4.0.2 branch code and they provide a few of the features noted in the documentation but missing from Windows: - Running in debug mode - Running in jwpda mode - Running with spaces in any of the path names I realize the 4.0.2 branch is really only doing maintenance work now, but it would be nice to put these scripts in if the opportunity arises (i.e. a 4.0.3 release comes out at some point). This also resolves Bugzilla bug 6108. Thanks, Patrick Remy Maucherat wrote: On Tue, 29 Jan 2002, Kevin Seguin wrote: 5647 has a patch associated with it that looks pretty good. i'm not even sure i understand 5483 yet :) There are 2 issues: - extracting the language from the Accept-Language: header. That should be implemented in tomcat ( and the servlet container ) - as with the charset detection, that's at a higher level than the connector. - serving the 'right' page based on the accept-language header. I believe there is a patch for 3.x, not sure if it was ever ported. In the context of Apache+tomcat, all static files will support the language header, using the apache convention and settings. I'm not sure this is the same as the standalone impl ( apache is based on extensions, index.html.en, while in 3.x it's based on dirs en/index.html - but I haven't checked ). Regadless of what's happening for static pages, there is no rule defined for jsps AFAIK, the jsp itself should use one of the existing taglibs or whatever to get the right language. A workaround - for jsps - is to use the header directly. For static files apache should deal with that without problems. A bigger problem, which is not easy to fix in jk1.x, is charset detection and setting, especially for the jni connector. That's going to improve a lot in jk2 and o.a.jk, almost the same code used for 3.3 will be used there too. I would mark this bug as LATER for now. Ok, thanks for the detailed explanation. I'll post it in bugzilla, and mark the bug as LATER. Thanks, Remy -- 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: OUT OF ENVIRONMENT SPACE
} /
+echo message=xerces2.jars.present(except JDK 1.4+ or
xerces1)=${xerces2.jars.present} /
echo message=--- Optional JARs --- /
echo message=dbcp.jar.present=${dbcp.jar.present} /
@@ -526,6 +556,7 @@
echo message=copy.pool.jar=${copy.pool.jar} /
echo message=copy.tyrex.jar=${copy.tyrex.jar} /
echo message=copy.xerces.jar=${copy.xerces.jar} /
+echo message=copy.xerces2.jars=${copy.xerces2.jars}/
/target
@@ -600,10 +631,14 @@
target name=copy-xerces.jar if=copy.xerces.jar
copy todir=${catalina.build}/common/lib file=${xerces.jar}/
/target
+ target name=copy-xerces2.jars if=copy.xerces2.jars
+copy todir=${catalina.build}/common/lib
file=${xercesImpl.jar}/
+copy todir=${catalina.build}/common/lib
file=${xmlParserAPIs.jar}/
+ /target
!-- === BUILD: Copy Static Files
=== --
- target name=build-static
depends=flags,flags.display,build-prepare,copy-activation.jar,copy-dbcp.jar,copy-jaas.jar,copy-jdbc20ext.jar,copy-jmx.jar,copy-jndi.jar,copy-jsse.jar,copy-jta.jar,copy-ldap.jar,copy-modeler.jar,copy-pool.jar,copy-tyrex.jar,copy-xerces.jar
+ target name=build-static
depends=flags,flags.display,build-prepare,copy-activation.jar,copy-dbcp.jar,copy-jaas.jar,copy-jdbc20ext.jar,copy-jmx.jar,copy-jndi.jar,copy-jsse.jar,copy-jta.jar,copy-ldap.jar,copy-modeler.jar,copy-pool.jar,copy-tyrex.jar,copy-xerces.jar,copy-xerces2.jars
!-- Executable Commands --
copy todir=${catalina.build}/bin
1.27 +4 -0 jakarta-tomcat-4.0/jasper/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/build.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- build.xml 4 Oct 2001 05:51:12 - 1.26
+++ build.xml 29 Jan 2002 02:42:25 - 1.27
@@ -23,6 +23,8 @@
pathelement location=${servlet.jar}/
pathelement location=${tools.jar}/
pathelement location=${xerces.jar}/
+pathelement location=${xercesImpl.jar}/
+pathelement location=${xmlParserAPIs.jar}/
pathelement location=${jasper.build}/shared/classes/
/path
@@ -32,6 +34,8 @@
pathelement location=${servlet.jar}/
pathelement location=${tools.jar}/
pathelement location=${xerces.jar}/
+pathelement location=${xercesImpl.jar}/
+pathelement location=${xmlParserAPIs.jar}/
pathelement location=${jasper.build}/shared/classes/
pathelement location=${jasper.build}/tests/
/path
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
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: cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.bat setclasspath.sh
All, I have added the required java.endorsed.dirs property to support JDK 1.4 (note: this has no effect with JDK 1.3). Although I verified that several servlets and JSP pages work without exceptions runing Tomcat both with and without -security, my testing was limited. So, those of you using JDK 1.4, please test it out and let me know if you find any problems. Thanks, Patrick [EMAIL PROTECTED] wrote: patrickl02/01/30 15:01:50 Modified:catalina/src/bin setclasspath.bat setclasspath.sh Log: Set java.endorsed.dirs property to common/lib so that the XML parser in common/lib overrides the parser bundled with JDK 1.4. This behavior is needed for Tomcat to behave under JDK 1.4 like it currently behaves in JDK 1.3 Revision ChangesPath 1.2 +2 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat Index: setclasspath.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- setclasspath.bat 15 Jan 2002 02:55:38 - 1.1 +++ setclasspath.bat 30 Jan 2002 23:01:50 - 1.2 @@ -1,7 +1,7 @@ rem --- rem Set CLASSPATH and Java options rem -rem $Id: setclasspath.bat,v 1.1 2002/01/15 02:55:38 patrickl Exp $ +rem $Id: setclasspath.bat,v 1.2 2002/01/30 23:01:50 patrickl Exp $ rem --- rem Make sure prerequisite environment variables are set @@ -31,7 +31,7 @@ set JAVA_OPTS= rem Set the default -Djava.endorsed.dirs argument -set JAVA_ENDORSED_DIRS= +set JAVA_ENDORSED_DIRS=%BASEDIR%\bin;%BASEDIR%\common\lib rem Set standard CLASSPATH rem Note that there are no quotes as we do not want to introduce random 1.2 +2 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh Index: setclasspath.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- setclasspath.sh 15 Jan 2002 02:55:38 - 1.1 +++ setclasspath.sh 30 Jan 2002 23:01:50 - 1.2 @@ -1,7 +1,7 @@ # - # Set CLASSPATH and Java options # -# $Id: setclasspath.sh,v 1.1 2002/01/15 02:55:38 patrickl Exp $ +# $Id: setclasspath.sh,v 1.2 2002/01/30 23:01:50 patrickl Exp $ # - # Make sure prerequisite environment variables are set @@ -30,7 +30,7 @@ JAVA_OPTS= # Set the default -Djava.endorsed.dirs argument -JAVA_ENDORSED_DIRS= +JAVA_ENDORSED_DIRS=$BASEDIR/bin:$BASEDIR/common/lib # Set standard CLASSPATH CLASSPATH=$JAVA_HOME/lib/tools.jar -- 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]
[VOTE] New Committer: Manveen Kaur
All, I would like to propose Manveen Kaur as a committer. She has provided a significant number of patches for the adminstration webapp and I think her contributions will be a big benefit to Tomcat. Please vote, Thanks, 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: [PATCH] for jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
Adrian, ¡Muchas gracias! Acabo de comitar tu patch. Patrick Adrian Almenar wrote: Its just a patch for better understanding in spanish. Cheers, Adrian Almenar Systems Development Department Conectium Limited --- Name: ApplicationResources_es.properties.diff ApplicationResources_es.properties.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable Part 1.3Type: Plain Text (text/plain) -- _ 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: [VOTE] New Watchdog Committer: Ryan Lubke
+1 Patrick Craig R. McClanahan wrote: NOTE: I'm posting this here because Watchdog was originally contributed to Apache along with Tomcat, and the Tomcat developer community will be substantially helped by Ryan's proposed efforts. I would like to nominate Ryan Lubke ([EMAIL PROTECTED]) as a committer on the Watchdog project. Ryan works on the servlet and JSP compliance tests for J2EE servers, and has volunteered to bring the Watchdog tests up to date with respect to testing for Servlet 2.3 and JSP 1.2 compliance. This will assist Tomcat developers in ensuring that Tomcat stays compliant with these specifications, as well as other container developers. Over the past few weeks, Ryan has posted several patches and improved tests here (on TOMCAT-DEV). I'd like him to be able to commit these directly. Votes, please? Craig McClanahan -- 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: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
Remy, That is a valid approach as well. I only selected starting the rest of the connectors because that seemed to be the least radical change in the existing functionality. Patrick Remy Maucherat wrote: patrickl01/11/29 09:18:10 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: Fix for situation where an SSL connector is enabled but external dependencies (e.g. no .keystore file, etc.) are not correctly installed. Previous to this change, Tomcat would never invoke Lifecycle.start() if any connectors threw an exception. Hence, Tomcat appear to be hung. With this change, Tomcat will now properly start all connectors that are properly configured and won't get hung up by any improperly configured connectors. If desired, I can backport this change to the tomcat_40_branch for the upcoming 4.0.2 release. I don't agree. If server.initialize throws an exception, why would we want to try to start it anyway (just in case it manages to be able to do something). I think we should not call await (and shutdown) if something went wrong during init. Remy -- 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: [VOTE] New Committer: Jazmin Jonson
+1 Patrick Amy Roh wrote: As Bill Barker suggested, I would like to propose Jazmin Jonson as a new committer. She has contributed a numerous patches to Tomcat4 admin application. Votes please? Amy Roh -- 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: cvs commit: jakarta-tomcat-4.0/catalina/src/bin setenv.shcatalina.sh tool-wrapper.sh
Jon, What I could do is not distribute the setenv.sh file and, instead, check for the existence of this file. If it exists (which would only occur if the user has created the file), then catalina.sh and tools-wrapper.sh would source it. I think that would comply with your requirement. Also, should we put the setenv.sh somewhere else as well. If the above sounds OK, I can cvs remove the setenv.sh file and make the sourcing conditional. Thanks, Patrick Jon Stevens wrote: on 11/27/01 2:34 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Index: setenv.sh === #!/bin/sh # - # setenv.sh - File to hold all user customizable environment variables # # $Id: setenv.sh,v 1.1 2001/11/27 22:34:25 patrickl Exp $ # - # To permanently set your JAVA_HOME environment variable, uncomment and # customize the following line with the absolute path to your JAVA_HOME # JAVA_HOME=/usr/java -1 I don't think that this file should exist in CVS if it is a user file. The problem being that if a user upgrades to a new version of Catalina, then they will risk overwriting this file. Instead, it should be documented that the file needs to be created in order to be used. -jon -- 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: cvs commit: jakarta-tomcat-4.0/catalina/src/binsetenv.shcatalina.sh tool-wrapper.sh
Jon, Jon Stevens wrote: [snip] Just as a side note, we need to be more cautious about upgrades and how users perform them. The server.xml is a big sore spot as well because that is another file that needs to be changed by the users. Thanks for catching this in my initial commit. I have removed the setenv.sh from the respository and the scripts only source the file if it exists. I also added this support for Windows as well. I still need to document this optional feature. Thanks, Patrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Changes to catalina.policy security constraints
Glenn, I noticed that with your changes to catalina.policy, both the admin and manager webapps throw the following exception. I know that you have set the Jasper jars to AllPermissions, but apparently this isn't enough. Any ideas what privileges are missing? Thanks, Patrick java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.servlet) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:272) at java.security.AccessController.checkPermission(AccessController.java:399) at java.lang.SecurityManager.checkPermission(SecurityManager.java:545) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1501) at java.lang.ClassLoader$1.run(ClassLoader.java:324) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:322) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:820) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3272) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3393) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:811) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:182) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:805) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:568) at java.lang.reflect.Method.invoke(Native Method) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:160) at org.apache.commons.digester.Digester.endElement(Digester.java:757) at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403) at org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1480) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1204) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) at org.apache.commons.digester.Digester.parse(Digester.java:1206) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:378) at org.apache.catalina.core.StandardHost.install(StandardHost.java:709) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:365) at org.apache.catalina.startup.HostConfig.run(HostConfig.java:634) at java.lang.Thread.run(Thread.java:484) -- _ 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: Unix passwords
Niklas, See my questions inline: If you agree but no one is wiling to adopt the task, I will. I suggest the possibility to add an 'crypt=TYPE' directive to the realm configuration. Currently, there already is a digest attribute for a Realm. The defualt in server.xml is no digest. But currently you can specify digest=MD5. I would assume that you want to use this existing attribute with a new MD5crypt option to minimize the amount of documentation changes. Documentation for the digest option is in the following source file in the jakarta-tomcat-4.0 source code: webapps/tomcat-docs/realm-howto.xml If you submit a patch to enable such a new digest option, be sure to submit a patch for the documentation as well. This leaves open the chance to implement other crypt-routines (as the unix-crypt requested prior on this list). Adding a digest=MD5 attribute to Realm makes sense if you put the usernames and passwords into the formats that are supported by the existing 3 Realms: Realm Format - -- MemoryRealm Stored in conf/tomcat-users.xml JNDIRealm Stored in your LDAP server JDBCRealm Stored in your relational database If you use any of the above 3 existing Realms, you would need to import all of your Linux usernames and passwords into the applicable data storage format. So, this brings up my next question: do you really want to access the native Linux (or other Unix variants) password validation functions? If so, I would implement a new Realm object to support this type of data storage format. For purposes of this discussion, we could call it a UnixRealm. You could still implement the MD5crypt as a digest option, this new Realm would do the work of invoking the native C functions with a the username and the password encrypted with whatever is specified in the digest attribute. Of course, this new Realm would require the use of JNDI to access the native functions so you would need to make sure that the build.xml files don't build this Realm if there is no C compiler or other required build tools. Just my 2 cents, Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _
