Running multiple servlet instances
Hi, some time ago there was a discussion about implementing a cache of instances for single thread model servlets in Tomcat (just like JServ did). Does anyone know the latest status, i.e. is someone working on it? Alain
Re: Running multiple servlet instances
On Tue, 14 Aug 2001, Alain SMEDTS wrote: Hi, some time ago there was a discussion about implementing a cache of instances for single thread model servlets in Tomcat (just like JServ did). Does anyone know the latest status, i.e. is someone working on it? I don't know of anyone working on it at the moment, although (at least for Tomcat 4) it would be a fairly straightforward exercise. Personally, I don't think STM should be encouraged -- it misleads people into thinking they don't have to deal with multiple thread issues, and still runs into scalability problems when you hit the maximum configured number of instances for each given servlet. But I'd commit a patch to enable this if someone really wanted it. Alain Craig
Re: Running multiple servlet instances
Craig R. McClanahan wrote: I don't know of anyone working on it at the moment, although (at least for Tomcat 4) it would be a fairly straightforward exercise. I think I have seen support for this in the code (see org.apache.catalina.core.StandardWrapper), but I've also heard that the STM servlet support is not as robust as it could be. Anyone with more direct (codewise) experience on this care to comment? Personally, I don't think STM should be encouraged -- it misleads people into thinking they don't have to deal with multiple thread issues, and still runs into scalability problems when you hit the maximum configured number of instances for each given servlet. But I'd commit a patch to enable this if someone really wanted it. While I agree that people should think about threading issues from the get-go, and ideally always use multithreaded servlets, there are always cases where (somehow) large amounts of non-threadsafe servlet code gets written. When the dev team finally figures out how they've gone wrong, they usually don't want to rewrite the whole app, they just want it to work. Of course if you are building a high-traffic webapp you will want to make sure everything is multithreaded, but for many low-traffic apps, single-threaded models (while arguably uglier from a design standpoint) perform just fine. - jonathan.
Re: getKeystorePass() method?
Craig R. McClanahan wrote: On Mon, 13 Aug 2001, Christopher Cain wrote: I'm in the process of cleaning up the 4.0 SSLServerSocketFactory, and it occurs to me that I find the getKeystorePass method offensive. There should never be any reason to retrieve the keystore password once it's set, and it makes me uncomfortable having the method there. I'm not sure if it could somehow be called from a webapp, It cannot. Correct me if I am wrong, but this is because the classes used by each webapp are loaded by a webapp-specific classloader, right? but it could certainly be called from a malicious module. It can. And again, this is correct because the malicious module would be loaded by the same classloader used to load the tomcat core classes, right? I'm working on a module to allow administrators to remove the password from server.xml, this method becomes a security hole. I think the idea of removing passwords from config files, or at least having the option to do so, is a great one. Keep us posted on the status of your module. :) There should never be a way to display passwords in any system. Agreed, *especially* in the case of plaintext passwords. - jonathan.
Re: Running multiple servlet instances
On Tue, 14 Aug 2001, Jonathan Cobb wrote: Craig R. McClanahan wrote: I don't know of anyone working on it at the moment, although (at least for Tomcat 4) it would be a fairly straightforward exercise. I think I have seen support for this in the code (see org.apache.catalina.core.StandardWrapper), but I've also heard that the STM servlet support is not as robust as it could be. Anyone with more direct (codewise) experience on this care to comment? There is infrastructure on which to build STM support if you want it. But, in effect, the current code keeps a pool size of 1. Anyone who wants to submit the appropriate patches to configure and manage a cache of instances is welcome to. Personally, I don't think STM should be encouraged -- it misleads people into thinking they don't have to deal with multiple thread issues, and still runs into scalability problems when you hit the maximum configured number of instances for each given servlet. But I'd commit a patch to enable this if someone really wanted it. While I agree that people should think about threading issues from the get-go, and ideally always use multithreaded servlets, there are always cases where (somehow) large amounts of non-threadsafe servlet code gets written. When the dev team finally figures out how they've gone wrong, they usually don't want to rewrite the whole app, they just want it to work. Of course if you are building a high-traffic webapp you will want to make sure everything is multithreaded, but for many low-traffic apps, single-threaded models (while arguably uglier from a design standpoint) perform just fine. I've seen lots of people (even on single user web apps) get bit by simultaneous access to their session attributes. It's not really an app architecture issue; it's something that the developer should be aware of but doesn't tend to think about, because STM seems to promise that those issues have been dealt with. - jonathan. Craig
Re: getKeystorePass() method?
On Tue, 14 Aug 2001, Jonathan Cobb wrote: Craig R. McClanahan wrote: On Mon, 13 Aug 2001, Christopher Cain wrote: I'm in the process of cleaning up the 4.0 SSLServerSocketFactory, and it occurs to me that I find the getKeystorePass method offensive. There should never be any reason to retrieve the keystore password once it's set, and it makes me uncomfortable having the method there. I'm not sure if it could somehow be called from a webapp, It cannot. Correct me if I am wrong, but this is because the classes used by each webapp are loaded by a webapp-specific classloader, right? That's part of the reason an app cannot do this. The more important reason is that SSLServerSocketFactory (and all the other Catalina internal classes) are loaded from a class loader that is *not* in the hierarchy visible to web apps. The only internal classes that a web app sees are the facade objects around the Servlet APIs (such as the class that implements HttpServletRequest). but it could certainly be called from a malicious module. It can. And again, this is correct because the malicious module would be loaded by the same classloader used to load the tomcat core classes, right? Yes. Classes loaded from the internal class loader (including valves) have pretty much free rein inside the server. I'm working on a module to allow administrators to remove the password from server.xml, this method becomes a security hole. I think the idea of removing passwords from config files, or at least having the option to do so, is a great one. Keep us posted on the status of your module. :) There should never be a way to display passwords in any system. Agreed, *especially* in the case of plaintext passwords. - jonathan. Craig
Re: [PATCHES] SSL Sockets
Christopher Cain at [EMAIL PROTECTED] wrote: Pier P. Fumagalli wrote: Err... Warp doesn't (yet) support TLS sockets, but, since you changed the signature, I believe it needs to go in :) :) :) I figured that you are already answering enough mail on how to build Warp, so I best not change any signatures out from under you ;-) PRRT :) :) :) :) Anyway, can someone else tell me thoughts on his patch? Check/Review it? So that someone can commit it (or not!) :) Pier
ContextEjb related deploy classes
Forgive me if this is the wrong list to post to, but since it's a source related question (as opposed to a use question) I thought this list would be appropriate for my question. I'm reading through the source code and trying to understand the whole startup process -- how org.apache.catalina.startup.Catalina gets everything up and running. Unfortunately, I'm at loggerheads on one particular point. When the default server.xml file is parsed and the examples context is created, there are some sample tags like Environment/ Resource/ Parameter/ and Ejb/. I realise that these tags correspond to classes in the org.apache.catalina.deploy package and that the classes are added to the StandardContext and accessed through various find methods. Reading through the servlet spec (2.3pfd) it seems to me the purpose of these tags is to clue the web app as to what J2EE resources it has available. For example, the ejb-ref/ tag provides the web app with the name (among other things) of an EJB so it can get a naming context and look up the EJB. Is this right? Here's where I'm lost. I can't find any methods in javax.servlet.ServletContext that would provide access to the ContextEjbs (or any of the other deploy classes). In other words, StandardContext has the findEjb(String) method, but I don't see how javax.servlet.ServletContext or org.apache.catalina.core.ApplicationContext is able to access these deploy elements. Or have I completely misunderstood the purpose of the Environment/ Resource/ Parameter/ and Ejb/ tags? In any respect, I'd greatly appreciate a good dollop of enlightenment. Thanks, Alex
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util CGIProcessEnvironment.java
pier01/08/14 11:50:10 Modified:.RELEASE-NOTES-4.0-B8.txt catalina/docs/appdev build.xml.txt deployment.html installation.html processes.html source.html catalina/docs/appdev/sample build.bat build.sh build.xml catalina/docs/dev/xdocs building.xml catalina/src/share/org/apache/catalina/servlets CGIServlet.java catalina/src/share/org/apache/catalina/util CGIProcessEnvironment.java Log: Changed references to TOMCAT_HOME into CATALINA_HOME. Thanks to Dennis Doubleday dday at mail.yourfit.com for noticing. Revision ChangesPath 1.3 +12 -4 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B8.txt Index: RELEASE-NOTES-4.0-B8.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B8.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- RELEASE-NOTES-4.0-B8.txt 2001/08/10 14:14:15 1.2 +++ RELEASE-NOTES-4.0-B8.txt 2001/08/14 18:50:09 1.3 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.0-B8.txt,v 1.2 2001/08/10 14:14:15 pier Exp $ +$Id: RELEASE-NOTES-4.0-B8.txt,v 1.3 2001/08/14 18:50:09 pier Exp $ @@ -72,6 +72,14 @@ BUG FIXES AND IMPROVEMENTS: == +-- +Generic Bug Fixes: +-- + +Documentation: Updated all references to TOMCAT_HOME in the documentation to +be CATALINA_HOME. (Thanks to Dennis Doubleday for noticing) + + -- Catalina Bug Fixes: @@ -107,12 +115,12 @@ * If you wish to make the JAXP/1.1 RI XML parser available to all web applications, simply move the jaxp.jar and crimson.jar files from - the $TOMCAT_HOME/jasper directory to the $TOMCAT_HOME/lib directory. + the $CATALINA_HOME/jasper directory to the $CATALINA_HOME/lib directory. * If you wish to make another XML parser that is JAXP/1.1-compatible available to all web applications, install that parser into the - $TOMCAT_HOME/lib directory and remove jaxp.jar and crimson.jar - from the $TOMCAT_HOME/jasper directory. It has been reported that + $CATALINA_HOME/lib directory and remove jaxp.jar and crimson.jar + from the $CATALINA_HOME/jasper directory. It has been reported that Xerces 1.3.1 can be used in this fashion, but 2.x alpha releases can not be. 1.2 +3 -3 jakarta-tomcat-4.0/catalina/docs/appdev/build.xml.txt Index: build.xml.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/appdev/build.xml.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.xml.txt 2001/02/14 22:26:33 1.1 +++ build.xml.txt 2001/08/14 18:50:09 1.2 @@ -16,7 +16,7 @@ build file. The values specified can be overridden at run time by adding a -Dname=value argument to the command line that invokes Ant. This technique is normally used to copy the values of the ANT_HOME - and TOMCAT_HOME environment variables into the ant.home and + and CATALINA_HOME environment variables into the ant.home and tomcat.home properties, which are normally not defined explicitly. app.name Base name of this application, used to @@ -25,7 +25,7 @@ deploy.home The name of the directory into which the deployment hierarchy will be created. Normally, this will be the name of a - subdirectory under $TOMCAT_HOME/webapps. + subdirectory under $CATALINA_HOME/webapps. dist.home The name of the base directory in which distribution files are created. @@ -46,7 +46,7 @@ tomcat.home The name of the base directory in which Tomcat has been installed. This value is normally set automatically from the value - of the TOMCAT_HOME environment variable. + of the CATALINA_HOME environment variable. In the example below, the application being developed will be deployed to a subdirectory named myapp, and will therefore be accessible at: 1.2 +4 -4 jakarta-tomcat-4.0/catalina/docs/appdev/deployment.html Index: deployment.html === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/appdev/deployment.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- deployment.html 2001/02/14 22:26:33 1.1 +++
Re: ContextEjb related deploy classes
On Tue, 14 Aug 2001, Alex Garrett wrote: Forgive me if this is the wrong list to post to, but since it's a source related question (as opposed to a use question) I thought this list would be appropriate for my question. I'm reading through the source code and trying to understand the whole startup process -- how org.apache.catalina.startup.Catalina gets everything up and running. Unfortunately, I'm at loggerheads on one particular point. When the default server.xml file is parsed and the examples context is created, there are some sample tags like Environment/ Resource/ Parameter/ and Ejb/. I realise that these tags correspond to classes in the org.apache.catalina.deploy package and that the classes are added to the StandardContext and accessed through various find methods. Yes, that's right. Reading through the servlet spec (2.3pfd) it seems to me the purpose of these tags is to clue the web app as to what J2EE resources it has available. For example, the ejb-ref/ tag provides the web app with the name (among other things) of an EJB so it can get a naming context and look up the EJB. Is this right? Yes. The place to look for information about how an application uses this stuff is in the J2EE Platform Specification (down near the bottom): http://java.sun.com/j2ee/download.html In particular, look at Chapter 5: Naming. The intent of the JNDI support in Tomcat 4 is to provide a compatible environment for accessing env-entry, resource-ref, and resource-env-ref values in Tomcat stand alone -- i.e. everything except EJBs -- in a fashion that is identical to what you use on J2EE servers. See below for more. Here's where I'm lost. I can't find any methods in javax.servlet.ServletContext that would provide access to the ContextEjbs (or any of the other deploy classes). In other words, StandardContext has the findEjb(String) method, but I don't see how javax.servlet.ServletContext or org.apache.catalina.core.ApplicationContext is able to access these deploy elements. Or have I completely misunderstood the purpose of the Environment/ Resource/ Parameter/ and Ejb/ tags? In any respect, I'd greatly appreciate a good dollop of enlightenment. Let's say that what you want to do is access a connection pool (i.e. an implementation of javax.sql.DataSource) as you are building a web app on Tomcat 4, and you want to use exactly the same code that you will use when the app is deployed on a J2EE server -- something like this: Context initialContext = new InitialContext(); DataSource ds = (DataSource) initialContext.lookup(java:comp/env/jdbc/EmployeeAppDB); Connection conn = ds.getConnection(); ... use this Connection ... conn.close(); // Return connection to the pool Now, in your application's web.xml, you declare a reference to this connection pool, but without details: resource-env-ref resource-env-ref-namejdbc/EmployeeAppDb/resource-env-ref-name resource-env-ref-typejavax.sql.DataSource/resource-env-ref-type /resource-env-ref The actual linkage of this connection pool to a real database happens inside Tomcat 4's server.xml file -- see the declaration of the /examples context. Thanks, Alex Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java
craigmcc01/08/14 12:30:07
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Do not load jndi.jar on a JDK 1.3 or later system, in *any* of the three
class loaders we are creating (because it is built in to the JDK in 1.3).
Previously, we were checking this only for the common classloader.
Submitted by: Rajiv Mordani [EMAIL PROTECTED]
Revision ChangesPath
1.22 +43 -23
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Bootstrap.java2001/07/22 20:25:13 1.21
+++ Bootstrap.java2001/08/14 19:30:07 1.22
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.21 2001/07/22 20:25:13 pier Exp $
- * $Revision: 1.21 $
- * $Date: 2001/07/22 20:25:13 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.22 2001/08/14 19:30:07 craigmcc Exp $
+ * $Revision: 1.22 $
+ * $Date: 2001/08/14 19:30:07 $
*
*
*
@@ -85,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.21 $ $Date: 2001/07/22 20:25:13 $
+ * @version $Revision: 1.22 $ $Date: 2001/08/14 19:30:07 $
*/
public final class Bootstrap {
@@ -116,10 +116,20 @@
debug = 1;
}
+// Check to see if JNDI is already present in the system classpath
+boolean loadJNDI = true;
+try {
+Class.forName(javax.naming.Context);
+loadJNDI = false;
+} catch (ClassNotFoundException e) {
+}
+
// Construct the class loaders we will need
-ClassLoader commonLoader = createCommonLoader();
-ClassLoader catalinaLoader = createCatalinaLoader(commonLoader);
-ClassLoader sharedLoader = createSharedLoader(commonLoader);
+ClassLoader commonLoader = createCommonLoader(loadJNDI);
+ClassLoader catalinaLoader =
+createCatalinaLoader(commonLoader, loadJNDI);
+ClassLoader sharedLoader =
+createSharedLoader(commonLoader, loadJNDI);
Thread.currentThread().setContextClassLoader(catalinaLoader);
@@ -215,20 +225,14 @@
/**
* Construct and return the class loader to be used for loading
* of the shared system classes.
+ *
+ * @param loadJNDI Should we load JNDI classes if present?
*/
-private static ClassLoader createCommonLoader() {
+private static ClassLoader createCommonLoader(boolean loadJNDI) {
if (debug = 1)
log(Creating COMMON class loader);
-// Check to see if JNDI is already present in the system classpath
-boolean loadJNDI = true;
-try {
-Class.forName(javax.naming.Context);
-loadJNDI = false;
-} catch (ClassNotFoundException e) {
-}
-
// Construct the class path for this class loader
ArrayList list = new ArrayList();
@@ -263,9 +267,11 @@
String filenames[] = directory.list();
for (int i = 0; i filenames.length; i++) {
String filename = filenames[i].toLowerCase();
-if ((!filename.endsWith(.jar)) ||
-(filename.indexOf(bootstrap.jar) != -1) ||
-((!loadJNDI) (filename.indexOf(jndi.jar) != -1)))
+if (!filename.endsWith(.jar))
+continue;
+if ((!loadJNDI) filename.equals(jndi.jar))
+continue;
+if (filename.equals(bootstrap.jar))
continue;
File file = new File(directory, filenames[i]);
try {
@@ -293,8 +299,12 @@
/**
* Construct and return the class loader to be used for loading
* Catalina internal classes.
+ *
+ * @param parent Parent class loader to be assigned
+ * @param loadJNDI Should we load JNDI classes if present?
*/
-private static ClassLoader createCatalinaLoader(ClassLoader parent) {
+private static ClassLoader createCatalinaLoader(ClassLoader parent,
+boolean loadJNDI) {
if (debug = 1)
log(Creating CATALINA class loader);
@@ -332,7 +342,10 @@
}
String filenames[] = directory.list();
for (int i = 0; i filenames.length; i++) {
-
Re: ContextEjb related deploy classes
Thanks for the help! I was still confused as to how the web app gets the information, but what you gave me pointed me to the StandardContext.createNamingContext() method and it all makes perfect sense, now. Incidentally, as I continue to try to understand the codebase, I'll probably have similar questions. I'll try to puzzle out the answers by reading the code, specs, and list archives, but lacking that, is this the appropriate place to ask questions about the source, or should that be confined to tomcat-user? Thanks again, Alex Let's say that what you want to do is access a connection pool (i.e. an implementation of javax.sql.DataSource) as you are building a web app on Tomcat 4, and you want to use exactly the same code that you will use when the app is deployed on a J2EE server -- something like this: Context initialContext = new InitialContext(); DataSource ds = (DataSource) initialContext.lookup(java:comp/env/jdbc/EmployeeAppDB); Connection conn = ds.getConnection(); ... use this Connection ... conn.close(); // Return connection to the pool Now, in your application's web.xml, you declare a reference to this connection pool, but without details: resource-env-ref resource-env-ref-namejdbc/EmployeeAppDb/resource-env-ref-name resource-env-ref-typejavax.sql.DataSource/resource-env-ref-type /resource-env-ref The actual linkage of this connection pool to a real database happens inside Tomcat 4's server.xml file -- see the declaration of the /examples context.
Re: ContextEjb related deploy classes
On Tue, 14 Aug 2001, Alex Garrett wrote: Thanks for the help! I was still confused as to how the web app gets the information, but what you gave me pointed me to the StandardContext.createNamingContext() method and it all makes perfect sense, now. Incidentally, as I continue to try to understand the codebase, I'll probably have similar questions. I'll try to puzzle out the answers by reading the code, specs, and list archives, but lacking that, is this the appropriate place to ask questions about the source, or should that be confined to tomcat-user? For qustions about Tomcat internals, you'll do better here. And, if you volunteered to write up the answers as docs that can be included with Tomcat, we'll be *very* motivated to answer those questions. :-) Thanks again, Alex Craig Let's say that what you want to do is access a connection pool (i.e. an implementation of javax.sql.DataSource) as you are building a web app on Tomcat 4, and you want to use exactly the same code that you will use when the app is deployed on a J2EE server -- something like this: Context initialContext = new InitialContext(); DataSource ds = (DataSource) initialContext.lookup(java:comp/env/jdbc/EmployeeAppDB); Connection conn = ds.getConnection(); ... use this Connection ... conn.close(); // Return connection to the pool Now, in your application's web.xml, you declare a reference to this connection pool, but without details: resource-env-ref resource-env-ref-namejdbc/EmployeeAppDb/resource-env-ref-name resource-env-ref-typejavax.sql.DataSource/resource-env-ref-type /resource-env-ref The actual linkage of this connection pool to a real database happens inside Tomcat 4's server.xml file -- see the declaration of the /examples context.
[PATCH] SSL phase two
The second phase of cleanup ended up being pretty undramatic. The Jikes
problems I was seeing ended up being the fact that I have the SSL jars
as installed extensions in the jre/lib/ext, so Jikes didn't have
explicit access to them (which I would have known immediately if I had
paid attention to the initial compile errors ... oh well :-)
Anyway, this is just the filling out of the javadoc comments, so
SSLServerSocketFactory is now fully doc'ed. Since the first patch hasn't
been applied yet, I'm including a
SSLServerSocketFactory.patch.combined file which has the changes from
last time as well as these, against the current cvs source. I'm also
attaching SSLServerSocketFactory.patch.javadocs, which is simply the
new javadocs fill-ins without everything in the previous patch (in case
anyone applied my previous patch to their local tree, or if anyone wants
to see just this piece by itself).
The next and final SSL patch will actually fix the multiple-entry store
problem.
- Christopher
--- catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java Sun
Jul 22 13:25:12 2001
+++ catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory-new.java Tue
+Aug 14 13:42:27 2001
@@ -66,6 +66,8 @@
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
+import java.security.UnrecoverableKeyException;
+import java.security.KeyManagementException;
import java.security.Security;
import java.security.cert.CertificateException;
import javax.net.ServerSocketFactory;
@@ -146,24 +148,48 @@
*/
private String algorithm = SunX509;
+/**
+ * Return the current certificate encoding algorithm.
+ *
+ * @return the certificate encoding algorithm
+ */
public String getAlgorithm() {
return (this.algorithm);
}
+/**
+ * Set the certificate encoding algorithm.
+ *
+ * @paramalgorithm the certificate encoding algorithm
+ */
public void setAlgorithm(String algorithm) {
this.algorithm = algorithm;
}
/**
- * Should we require client authentication?
+ * Require client authentication?
*/
private boolean clientAuth = false;
+
+/**
+ * Returns whether or not client authentication required.
+ *
+ * @return codetrue/code if client authentication is required for
+ * secure connections, otherwise codefalse/code
+ */
public boolean getClientAuth() {
return (this.clientAuth);
}
+
+/**
+ * Set the client authentication mode for secure connections.
+ *
+ * @param clientAuth codetrue/code if client authentication should be
+ * required, otherwise codefalse/code
+ */
public void setClientAuth(boolean clientAuth) {
this.clientAuth = clientAuth;
}
@@ -175,10 +201,23 @@
*/
private KeyStore keyStore = null;
-public KeyStore getKeyStore() throws IOException {
+/**
+ * Returns a codeKeyStore/code object representing the containing store
+ * for this socket's certificate.
+ *
+ * @return the codeKeyStore/code containing this socket's
+ * authenticating certificate
+ */
+public KeyStore getKeyStore()
+throws KeyStoreException, IOException, NoSuchAlgorithmException,
+ CertificateException,UnrecoverableKeyException,
+ KeyManagementException
+{
+
if (sslProxy == null)
initialize();
return (this.keyStore);
+
}
@@ -188,34 +227,66 @@
private String keystoreFile =
System.getProperty(user.home) + File.separator + .keystore;
+
+/**
+ * Returns the path to the keystore file containing the certificate
+ * associated with this socket.
+ *
+ * @return a string of the fully-qualified path to the keystore
+ */
public String getKeystoreFile() {
return (this.keystoreFile);
}
+
+/**
+ * Specify the path to the keystore file containing the certificate for
+ * this socket.
+ *
+ * @param keystoreFile the fully-qualified path to the keystore
+ */
public void setKeystoreFile(String keystoreFile) {
this.keystoreFile = keystoreFile;
}
/**
- * Password for accessing the key store file.
+ * The password for accessing the certificate keystore file.
*/
private String keystorePass = changeit;
+
+/**
+ * Returns the password for the certificate keystore file.
+ *
+ * @return the keystore password
+ */
public String getKeystorePass() {
return (this.keystorePass);
}
+
+/**
+ * Sets the password for the keystore certificate file.
+ *
+ * @param keystorePass the keystore password
+ */
public void setKeystorePass(String keystorePass) {
this.keystorePass = keystorePass;
}
/**
- * Storeage type of the key
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JikesJavaCompiler.java
seguin 01/08/14 13:52:43
Modified:jasper/src/share/org/apache/jasper/compiler
JikesJavaCompiler.java
Log:
two fixes:
1) normalize the classpath jikes is invoked with so that it
doesn't contain file urls like /c:/tomcat/webapps/...
on windows, which makes jikes barf.
2) add +E option to jikes command line so that error output
parsing works.
Revision ChangesPath
1.5 +30 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java
Index: JikesJavaCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JikesJavaCompiler.java2001/02/08 13:37:54 1.4
+++ JikesJavaCompiler.java2001/08/14 20:52:43 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java,v
1.4 2001/02/08 13:37:54 glenn Exp $
- * $Revision: 1.4 $
- * $Date: 2001/02/08 13:37:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java,v
1.5 2001/08/14 20:52:43 seguin Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/08/14 20:52:43 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.IOException;
import java.io.File;
import java.io.ByteArrayOutputStream;
+import java.util.StringTokenizer;
/**
* A Plug-in class for specifying a 'jikes' compile.
@@ -110,7 +111,30 @@
* Set the class path for the compiler
*/
public void setClasspath(String classpath) {
- this.classpath = classpath;
+//
+// normalize the paths in the classpath. this
+// is really only an issue with jikes on windows.
+//
+// sometimes a path the looks like this:
+///c:/tomcat/webapps/WEB-INF/classes
+// will show up in the classpath. in fact, this
+// *always* happens with tomcat4. jikes on windows
+// will barf on this. the following code will normalize
+// paths like this (all paths, actually) so that jikes
+// is happy :)
+//
+
+StringBuffer buf = new StringBuffer(classpath.length());
+StringTokenizer tok = new StringTokenizer(classpath,
+ File.pathSeparator);
+while (tok.hasMoreTokens()) {
+String token = tok.nextToken();
+File file = new File(token);
+buf.append(file.toString());
+buf.append(File.pathSeparator);
+}
+
+this.classpath = buf.toString();
}
/**
@@ -162,6 +186,7 @@
-classpath, quote + classpath + MicrosoftClasspath + quote,
-d, quote + outdir + quote,
-nowarn,
++E,
quote + source + quote
};
} else {
@@ -170,6 +195,7 @@
//XXX - add encoding once Jikes supports it
-classpath, quote + classpath + MicrosoftClasspath + quote,
-nowarn,
++E,
quote + source + quote
};
}
Nightly builds for 3.3
Hi, Nightly builds for 3.3 are out, it seems somehow they are destabilising the system and Pier asked me to find a different machine. I'll try to do that, the sourceforge build machines seems nice ( but I'll have to do some tricks ), or I could use my home machine ( which seems to be faster anyway ). This isn't a big deal, most development in the 3.3 main tree has been completed, the code is stable and in beta. The only thing that's going to change are modules - but mod_jk and ajp14 were not included in the nightly, and all modules I'm working on are just add-ons. As previously discussed, 3.3 core can be considered frozen, we're doing the final reviews to make sure it'll be able to handle any kinds of modules. Testing 3.3 with those add-on modules is important, and that's where I'll focus. Testing 3.3 basic every few hours is no longer that important. Costin
Re: ServletContext.getResource() never null?
in testing several containers including Tomcat 3.1.1, i was unable to get a null ( where a test for null would have been, um, desirable ), nor did it appear that the presence or absence of a leading / made any difference. Sounds like a bug in 3.1.1. But it's unlikely anyone is going to bend over backwards to fix it -- Tomcat 3.2 was released nine months ago (current version is 3.2.3), and Tomcat 4.0 will be released as soon as the servlet 2.3 and JSP 1.2 specs go final (real soon now). Amy is correct - Tomcat 4.0b7 appears to return the expected results. Tomcat 3.2.3, however, appears to exhibit the same behaviour as 3.1.1, so...
Re: Nightly builds for 3.3
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Nightly builds for 3.3 are out, it seems somehow they are destabilising the system and Pier asked me to find a different machine. Since Tomcat 3.3 is opening 8500 file descriptors per process (how can that be, I don't know, but I just audited it one Nagoya with Costin's config), well, I kinda have to... Nagoya.Apache.ORG is handling several sets of builds, and the one from Costin were failing. Correct me if I'm wrong, but also Larry was doing the same builds on the same machine, and those didn't actually produce any damage (if lost inodes can be called inodes). Now, I don't want to pass as the nasty one (well, as I always do, but) but since Nagoya is handling quite some stuff, I cannot leave something like it running, as every time the server crashes, it'll take something like 4 hours to resync the drives... Pier
RE: Nightly builds for 3.3
A bit of concern here.. I'm working constantly with 3.3 cvs version and have a lot of classloader issues and class context reloading issues.. (the lot means : it happens a lot..) Some are solved by moving the jar file to the root lib dir (didn't find the time to get a nice reproductions scenario yet, to see if a fix works). The class ,eh actually context reloading, issue is in bugzilla and didn't get around to fix that either. Reproducing it is for now only possible in our very big webapp. (reloading the context after a certain number of servlets is loaded will give state not ready for one servlet, which, you probably guessed already, our main entry point in the system). In short : How long do I have to fix the problems and from who can I get some help for these class(re)loading issues? TIA Mvgr, Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 14, 2001 11:57 PM To: [EMAIL PROTECTED] Subject: Nightly builds for 3.3 Hi, Nightly builds for 3.3 are out, it seems somehow they are destabilising the system and Pier asked me to find a different machine. I'll try to do that, the sourceforge build machines seems nice ( but I'll have to do some tricks ), or I could use my home machine ( which seems to be faster anyway ). This isn't a big deal, most development in the 3.3 main tree has been completed, the code is stable and in beta. The only thing that's going to change are modules - but mod_jk and ajp14 were not included in the nightly, and all modules I'm working on are just add-ons. As previously discussed, 3.3 core can be considered frozen, we're doing the final reviews to make sure it'll be able to handle any kinds of modules. Testing 3.3 with those add-on modules is important, and that's where I'll focus. Testing 3.3 basic every few hours is no longer that important. Costin
Re: ServletContext.getResource() never null?
chris monster wrote: in testing several containers including Tomcat 3.1.1, i was unable to get a null ( where a test for null would have been, um, desirable ), nor did it appear that the presence or absence of a leading / made any difference. Sounds like a bug in 3.1.1. But it's unlikely anyone is going to bend over backwards to fix it -- Tomcat 3.2 was released nine months ago (current version is 3.2.3), and Tomcat 4.0 will be released as soon as the servlet 2.3 and JSP 1.2 specs go final (real soon now). Amy is correct - Tomcat 4.0b7 appears to return the expected results. Tomcat 3.2.3, however, appears to exhibit the same behaviour as 3.1.1, so... I guess the bug wasn't fixed in 3.2.3 either. You can file a bug report to keep track of this bug. At least 4.0 works :-). Amy
RE: Nightly builds for 3.3
On Wed, 15 Aug 2001, Martin van den Bemt wrote: A bit of concern here.. I'm working constantly with 3.3 cvs version and have a lot of classloader issues and class context reloading issues.. (the lot means : it happens a lot..) Some are solved by moving the jar file to the root lib dir (didn't find the time to get a nice reproductions scenario yet, to see if a fix works). Can you give more details ? Reloading is quite flexible, I may be able to fix this. Have you filed a bug ? If you don't change the files in the webapp, it shouldn't do a reload. And so far the class loader worked amazingly fine - no Sealing Violation or things of this sort. The only problem I know of is JSPs includes - that has been fixed in jakarta-tomcat-jasper. The class ,eh actually context reloading, issue is in bugzilla and didn't get around to fix that either. Reproducing it is for now only possible in our very big webapp. (reloading the context after a certain number of servlets is loaded will give state not ready for one servlet, which, you probably guessed already, our main entry point in the system). In short : How long do I have to fix the problems and from who can I get some help for these class(re)loading issues? For help - me or Nacho ( who wrote the class loader hierarcy ). The reloading and class loader are quite modular, a fix will probably affect only 2-3 modules. That means in the worst case ( if we can't solve this in 1-2 weeks ) we can still have the fix available as an add-on module. It's a sort of update mechanism, like you can find in mozilla or netbeans. This is supposed to allow fixes to be provided without the typical ( long ) release cycle. Of course, if we can get it in 3.3.0 - it would be great. Costin
Velocity vs. XMLC
Hey buddy. First of all, thanks for the nod on getting committer status. Nothing has happened yet, and I e-mailed Craig privately to get his thoughts on whether he favors the idea or not. I haven't heard back yet, but I know he's a busy man. I'm sure at some point that my PATCHES assult will become annoying enough to either give me access or tell me to bugger off =) Actually, the real reason I'm hitting you up is to get an expert opinion on Velocity. I'm far from a presentation-layer expert, as most of our clients want custom web database apps for line-of-business type stuff. We therefore usually just build database-aware Java middleware objects and use servlets. Servlets aren't exactly the coolest technology for the presentation layer, but we're a small shop with only a few developers, so it's not like we're handing off the page design piece to HTML-monkeys. I can just slam out serious business apps and call my middleware directly from front-end servlets. It's fast and easy for our particular environment. As far as customers wanting to tweak the look and feel of the site, we created a pretty cool little database-driven CSS generator and hooked a simple web-based front-end to it. You can add/edit/delete HTML tags, assign applicable attributes to each tag, and assign predefined values for each attribute (or allow freeform value assignment). You can even save x number of named stylesheets use any stylesheet for any given page. It got us out of the Can you make the background a little more blue business, and customers can go in and tweak the look-and-feel to their hearts content. Anyway, we now have a customer with a hellishly complex app, and they also want to control the general app execution to the extent that we can let them. Stuff like, we want to change the menu link which calls the blah-de-blah validator to be a button near the top, we want the POST of page A to call page B before it calls page C ... stuff like that. Sounds like a job for Velocity, in my opinion: they can construct their application own flow and call out to our heavy-hitting data objects and methods for the real app execution. My boss is a very bright man, and he's hated JSP pretty much as long as you have. Thankfully, I don't even have to HAVE that discussion. Since I'm heavily involved in Jakarta, I immediately thought of Velocity. He's a _real_ Tomcat supporter, but he doesn't have alot of experience with the rest of the Jakarta world, and as a result he's never heard of Velocity. I've explained it to him, and he thinks it sounds pretty cool. He had also read about a product in the latest Linux Journal, from Enhydra, called XMLC (which honestly, *I* had never heard of). I read up on it, and it sounds pretty cool too. Maybe it's because I a Jakarta zealot, or maybe it's just because I'm naturally skeptical of power users writing properly-formatted XHTML, but I still prefer Velocity. So as the inventor/lead of Velocity, what do you see as the major benefits of Velocity over XMLC in a power user environment? We're not talking about a company who has an IT department, we're talking about a company who has a resonably-savvy HTML page static designer ... kind of a glorified pixel mechanic with enough skill in straight HTML to contract a web page from scratch, but no real programming experience to speak of. I'm looking for some counterpoints that I can take to the boss, from someone alot more knowledgable in the field than I am. He's an Open Source guy through-and-through, a Linux cat from the old school days, and I'm actually damn fortunate that selling my boss on a technology is like a trip to Disneyland compared to what you have to do in the corporate world. He's primarily concerned about two things: Getting a technology in place that these guys will have the most trouble screwing up and/or whining about its complexity, and the one that they will have the most trouble screwing US with, like crashing their own server and/or calling out our processing objects when they shouldn't. We realize that both of these are inevitable, but we're looking for the path of least resistance. These guys need something as dummy-proof as is possible, because the whole idea is to reduce the amount of calls we get on semanic pixel-pushing nonsense when we're busy trying to code complex application processing and database transactions to meet their _actual_ business needs. You know how it is. Anyway, if you get a spare minute (no rush, the project is at least a week out), I just wanted to get some ammo for Velocity. I mean, this XMLC shit sounds like a decent enough solution I guess ... in a well-oiled corporate IT environment. It sounds like a headache waiting to happen in our case, though. Thanks! - Christopher
Re: Velocity vs. XMLC
Ooops ... this was meant to go to Jon privately!!! (That reply-to header gets me every time =) DAMN!!! Oh well, good thing I didn't bust on any of you guys or anything =) Anyway, I guess since I accidentally sent it (believe me, I PROMISE it was accidental and not a troll for OT comments), if anyone feels like PRIVATELY (off-list) giving me their thoughts on Velocity vs. XMLC, feel free. Otherwise, feel free to just delete this renegade mail and go on about your day :-) - Christopher Christopher Cain wrote: Hey buddy. First of all, thanks for the nod on getting committer status. Nothing has happened yet, and I e-mailed Craig privately to get his thoughts on whether he favors the idea or not. I haven't heard back yet, but I know he's a busy man. I'm sure at some point that my PATCHES assult will become annoying enough to either give me access or tell me to bugger off =) Actually, the real reason I'm hitting you up is to get an expert opinion on Velocity. I'm far from a presentation-layer expert, as most of our clients want custom web database apps for line-of-business type stuff. We therefore usually just build database-aware Java middleware objects and use servlets. Servlets aren't exactly the coolest technology for the presentation layer, but we're a small shop with only a few developers, so it's not like we're handing off the page design piece to HTML-monkeys. I can just slam out serious business apps and call my middleware directly from front-end servlets. It's fast and easy for our particular environment. As far as customers wanting to tweak the look and feel of the site, we created a pretty cool little database-driven CSS generator and hooked a simple web-based front-end to it. You can add/edit/delete HTML tags, assign applicable attributes to each tag, and assign predefined values for each attribute (or allow freeform value assignment). You can even save x number of named stylesheets use any stylesheet for any given page. It got us out of the Can you make the background a little more blue business, and customers can go in and tweak the look-and-feel to their hearts content. Anyway, we now have a customer with a hellishly complex app, and they also want to control the general app execution to the extent that we can let them. Stuff like, we want to change the menu link which calls the blah-de-blah validator to be a button near the top, we want the POST of page A to call page B before it calls page C ... stuff like that. Sounds like a job for Velocity, in my opinion: they can construct their application own flow and call out to our heavy-hitting data objects and methods for the real app execution. My boss is a very bright man, and he's hated JSP pretty much as long as you have. Thankfully, I don't even have to HAVE that discussion. Since I'm heavily involved in Jakarta, I immediately thought of Velocity. He's a _real_ Tomcat supporter, but he doesn't have alot of experience with the rest of the Jakarta world, and as a result he's never heard of Velocity. I've explained it to him, and he thinks it sounds pretty cool. He had also read about a product in the latest Linux Journal, from Enhydra, called XMLC (which honestly, *I* had never heard of). I read up on it, and it sounds pretty cool too. Maybe it's because I a Jakarta zealot, or maybe it's just because I'm naturally skeptical of power users writing properly-formatted XHTML, but I still prefer Velocity. So as the inventor/lead of Velocity, what do you see as the major benefits of Velocity over XMLC in a power user environment? We're not talking about a company who has an IT department, we're talking about a company who has a resonably-savvy HTML page static designer ... kind of a glorified pixel mechanic with enough skill in straight HTML to contract a web page from scratch, but no real programming experience to speak of. I'm looking for some counterpoints that I can take to the boss, from someone alot more knowledgable in the field than I am. He's an Open Source guy through-and-through, a Linux cat from the old school days, and I'm actually damn fortunate that selling my boss on a technology is like a trip to Disneyland compared to what you have to do in the corporate world. He's primarily concerned about two things: Getting a technology in place that these guys will have the most trouble screwing up and/or whining about its complexity, and the one that they will have the most trouble screwing US with, like crashing their own server and/or calling out our processing objects when they shouldn't. We realize that both of these are inevitable, but we're looking for the path of least resistance. These guys need something as dummy-proof as is possible, because the whole idea is to reduce the amount of calls we get on semanic pixel-pushing nonsense when we're busy trying to code complex application processing and database transactions to meet their _actual_ business
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java PageContextImpl.java
craigmcc01/08/14 16:28:55
Modified:jasper/src/share/org/apache/jasper/compiler
IncludeGenerator.java
jasper/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java PageContextImpl.java
Log:
Fix a spec-compliance bug in the implementation of PageContext.include(),
which was not flushing the output stream even though this is explicitly
required in the Javadocs.
A side effect of this is that the code generated for a JSP servlet cannot
use pageContext.include() to implement the correct behavior for:
jsp:include ... flush=false/
so modify the code generator to call a private method in the runtime
library that does the right thing.
PR: Bugzilla #3121
Submitted by: Eduardo Pelegri-Llopart [EMAIL PROTECTED]
Revision ChangesPath
1.8 +15 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/IncludeGenerator.java
Index: IncludeGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- IncludeGenerator.java 2000/12/15 12:29:24 1.7
+++ IncludeGenerator.java 2001/08/14 23:28:55 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v
1.7 2000/12/15 12:29:24 pierred Exp $
- * $Revision: 1.7 $
- * $Date: 2000/12/15 12:29:24 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/IncludeGenerator.java,v
1.8 2001/08/14 23:28:55 craigmcc Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/08/14 23:28:55 $
*
*
*
@@ -132,9 +132,11 @@
writer.println({);
writer.pushIndent();
writer.println(String _jspx_qStr = \\;);
+/*
if (flush) {
writer.println(out.flush(););
}
+*/
if (params != null params.size() 0) {
Enumeration en = params.keys();
while (en.hasMoreElements()) {
@@ -168,12 +170,22 @@
}
}
}
+/*
if (!isExpression)
writer.println(pageContext.include( +
writer.quoteString(page) + + _jspx_qStr););
else
writer.println (pageContext.include( +
JspUtil.getExpr(page, isXml) + + _jspx_qStr););
+*/
+if (!isExpression)
+writer.println(JspRuntimeLibrary.include(request, response, +
+ writer.quoteString(page) + + _jspx_qStr, +
+ out, + flush + ););
+else
+writer.println(JspRuntimeLibrary.include(request, response, +
+ JspUtil.getExpr(page, isXml) + + _jspx_qStr, +
+ out, + flush + ););
writer.popIndent();
writer.println(});
1.8 +73 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JspRuntimeLibrary.java2001/07/18 23:16:20 1.7
+++ JspRuntimeLibrary.java2001/08/14 23:28:55 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.7 2001/07/18 23:16:20 horwat Exp $
- * $Revision: 1.7 $
- * $Date: 2001/07/18 23:16:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.8 2001/08/14 23:28:55 craigmcc Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/08/14 23:28:55 $
*
*
*
@@ -81,11 +81,14 @@
import java.security.PrivilegedExceptionAction;
import java.security.PrivilegedActionException;
+import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
+import javax.servlet.jsp.JspWriter;
import org.apache.jasper.JasperException;
import org.apache.jasper.Constants;
@@ -748,8 +751,74 @@
: + ex);
}
}
-}
+//
+// General Purpose Runtime Methods
Re: cvs commit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtimeJspRuntimeLibrary.java PageContextImpl.java
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Fix a spec-compliance bug in the implementation of PageContext.include(), which was not flushing the output stream even though this is explicitly required in the Javadocs. Congrats (I know it gave you some headaches!) Pier
Re: [Fwd: J2EE 1.3 Final Approval Ballot starts in 7 days]
On another mailing list, Jon fairly asked (since pretty soon, there will be a final release of 4.0) and I like to inform also the Tomcat developers on what my thoughts are: Jon Stevens at [EMAIL PROTECTED] wrote: Does mod_warp really have the level of testing and stability in order to declare a release of Apache quality? First of all, it's called WebApp Module :) :) :) I don't think that the WebApp module will be considered final on the day of the release, only in the past few weeks I started receiving comments and bug reports on it. I know, it's my bad, but that's how things are... Letely, I've been talking a lot with some of the core Apache HTTPd/APR developers here in London, members of the ASF, and we shared some of our visions on the levels of quality in the release cycles. What came out was: - alpha means it has bugs, we know it, try it at your own risk - beta is something more along the lines it works for us, we didn't find any bug even after testing, but there might be still some glitches that we didn't catch due to a not enough extensive test (platform dependancy, mainly) - release indicates something that we trust, is proven to be working without bugs by all those who tested them, so, let's kick it out. I believe that Tomcat 4.0 right now is right there between beta and release. Sometimes a new bug is found, but that gets fixed quite easily or in a timely manner, and was something really weird (like the one that is currently being fixed by Craig), but I trust that code, deeply... (we seriously need to close most of those bugzilla items) The WebApp module (or set of modules) is not yet there. Right now it is in alpha, I know it has bugs. I'm shooting for a beta in a short time, and another one alongside with the final release of Tomcat, but that's the best thing I can do. I need extensive testing, and extensive testing can come only from multi-platform deployment and usage: It's C code, and the JVM in this helps us a lot. My idea is to keep the distribution separate: I'm way more confident of the code in Java for it than the C code, so, I could fairly assert that when 4.0 comes out, the Java part will be done. The problem remains on the C side of things, and that's why I would propose a dual-release (as we did in the last 4.0 beta releases): the WebApp module is separated from the core trunk, follows its own versioning, (the current versions, 1.0-tc40b6 and 1.0-tc40b7 are pre-alpha snapshots) and is an add-on to Tomcat... (the WARP protocol handling connector, though will be final) So, what do you think? Pier
Bugzilla items...
Doing some cleansweep on bugzilla... I found several related to the WebApp module assigned to wrong categories... Pier
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/shared/sharedunp - New directory
craigmcc01/08/14 17:18:56 jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/shared/sharedunp - New directory
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unpshared - New directory
craigmcc01/08/14 17:20:03 jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unpshared - New directory
Servlet Forward to Self? 4.0b7
I'm not sure whether it is legal, but Tomcat 4.0b7 doesn't like it very much. I'm trying to forward a request back to the same servlet with a different query string that dispatches the way the request is handled within the servlet. Tomcat4.0b7 gets an error trying to allocate the servlet again from the invoker. In my servlet service handler: String theNewURL = /servlet/ + getClass ().getName () + ?GOTO=NextScreen; theNewURL = theResponse.encodeUrl (theNewURL); ServletContext theServletContext = theDBServlet.getServletContext (); theServletContext.getRequestDispatcher (theNewURL).forward (theRequest, theResponse);
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java
craigmcc01/08/14 17:55:25
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Use more platform-sensitive paths when building class loaders. Christoper
caught two of the cases, but there were a few more.
Windows ... gotta love it. :-)
Submitted by: Christopher Cain [EMAIL PROTECTED]
Revision ChangesPath
1.23 +9 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Bootstrap.java2001/08/14 19:30:07 1.22
+++ Bootstrap.java2001/08/15 00:55:25 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.22 2001/08/14 19:30:07 craigmcc Exp $
- * $Revision: 1.22 $
- * $Date: 2001/08/14 19:30:07 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.23 2001/08/15 00:55:25 craigmcc Exp $
+ * $Revision: 1.23 $
+ * $Date: 2001/08/15 00:55:25 $
*
*
*
@@ -85,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.22 $ $Date: 2001/08/14 19:30:07 $
+ * @version $Revision: 1.23 $ $Date: 2001/08/15 00:55:25 $
*/
public final class Bootstrap {
@@ -238,12 +238,12 @@
// Add the common/classes directory if it exists
File classes = new File(System.getProperty(catalina.home),
-common/classes);
+common + File.separator + classes);
if (classes.exists() classes.canRead()
classes.isDirectory()) {
try {
URL url = new URL(file, null,
- classes.getCanonicalPath() + /);
+ classes.getCanonicalPath() + File.separator);
if (debug = 1)
log( Adding + url.toString());
list.add(url.toString());
@@ -314,12 +314,12 @@
// Add the server/classes directory if it exists
File classes = new File(System.getProperty(catalina.home),
-server/classes);
+server + File.separator + classes);
if (classes.exists() classes.canRead()
classes.isDirectory()) {
try {
URL url = new URL(file, null,
- classes.getCanonicalPath() + /);
+ classes.getCanonicalPath() + File.separator);
if (debug = 1)
log( Adding + url.toString());
list.add(url.toString());
@@ -393,7 +393,7 @@
classes.isDirectory()) {
try {
URL url = new URL(file, null,
- classes.getCanonicalPath() + /);
+ classes.getCanonicalPath() + File.separator);
if (debug = 1)
log( Adding + url.toString());
list.add(url.toString());
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unpshared UnpSharedSessionBean.java
craigmcc01/08/14 17:57:09
Modified:tester build.xml
tester/src/bin tester.xml
tester/src/tester/org/apache/tester Session01.java
Session03.java
Added: tester/src/tester/org/apache/tester/unpshared
UnpSharedSessionBean.java
Log:
Add unit tests to make sure we can load both classes and resources from
$CATALINA_HOME/lib/*.jar and $CATALINA_HOME/classes. Previously, we were
only testing the case of classes from $CATALINA_HOME/lib.
Not yet tested on Windows ... that's next.
Revision ChangesPath
1.13 +16 -0 jakarta-tomcat-4.0/tester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/build.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.xml 2001/06/23 00:28:33 1.12
+++ build.xml 2001/08/15 00:57:08 1.13
@@ -75,8 +75,16 @@
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/unshared/UnsharedSessionBean.class/
copy file=src/tester/org/apache/tester/Resources01.txt
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked01.txt/
+copy file=src/tester/org/apache/tester/Resources01.txt
+tofile=${tester.build}/classes/org/apache/tester/shared/Shared01.txt/
+copy file=src/tester/org/apache/tester/Resources01.txt
+
tofile=${tester.build}/classes/org/apache/tester/unpshared/UnpShared01.txt/
copy file=src/tester/org/apache/tester/Resources03.txt
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked03.txt/
+copy file=src/tester/org/apache/tester/Resources03.txt
+tofile=${tester.build}/classes/org/apache/tester/shared/Shared03.txt/
+copy file=src/tester/org/apache/tester/Resources03.txt
+
tofile=${tester.build}/classes/org/apache/tester/unpshared/UnpShared03.txt/
copy file=src/tester/org/apache/tester/Resources05.txt
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked05.txt/
@@ -141,6 +149,14 @@
fixcrlf srcdir=${tester.deploy}/bin includes=*.sh cr=remove/
fixcrlf srcdir=${tester.deploy}/bin includes=*.bat cr=add/
chmod perm=+x file=${tester.deploy}/bin/tester.sh/
+
+!-- Unpacked Shared Classes --
+mkdir dir=${tester.deploy}/classes/
+copy todir=${tester.deploy}/classes
+ fileset dir=${tester.build}/classes
+include name=**/unpshared/*/
+ /fileset
+/copy
!-- Shared Library --
mkdir dir=${tester.deploy}/lib/
1.64 +30 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -r1.63 -r1.64
--- tester.xml2001/07/25 04:27:11 1.63
+++ tester.xml2001/08/15 00:57:08 1.64
@@ -875,6 +875,16 @@
request=${context.path}/Resources01?mode=classamp;path=/org/apache/tester/Unpacked01.txt
outContent=Resources01 PASSED/
+tester host=${host} port=${port} protocol=${protocol}
+ debug=${debug}
+
request=${context.path}/Resources01?mode=classamp;path=/org/apache/tester/shared/Shared01.txt
+ outContent=Resources01 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ debug=${debug}
+
request=${context.path}/Resources01?mode=classamp;path=/org/apache/tester/unpshared/UnpShared01.txt
+ outContent=Resources01 PASSED/
+
!-- == Negative ServletContext.getResource() Tests === --
tester host=${host} port=${port} protocol=${protocol}
@@ -904,6 +914,16 @@
request=${context.path}/Resources02?mode=classamp;path=/org/apache/tester/Unpacked02.txt.bad
outContent=Resources02 PASSED/
+tester host=${host} port=${port} protocol=${protocol}
+ debug=${debug}
+
request=${context.path}/Resources02?mode=classamp;path=/org/apache/tester/shared/Shared01.txt.bad
+ outContent=Resources02 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ debug=${debug}
+
request=${context.path}/Resources02?mode=classamp;path=/org/apache/tester/unpshared/UnpShared01.txt.bad
+ outContent=Resources02 PASSED/
+
!-- == Positive ServletContext.getResourceAsStream() Tests === --
tester host=${host} port=${port} protocol=${protocol}
@@ -931,6 +951,16 @@
tester host=${host} port=${port} protocol=${protocol}
debug=${debug}
request=${context.path}/Resources03?mode=classamp;path=/org/apache/tester/Unpacked03.txt
+ outContent=Resources03
Re: Servlet Forward to Self? 4.0b7
On Tue, 14 Aug 2001, Jonathan Pierce wrote: String theNewURL = /servlet/ + getClass ().getName () + ?GOTO=NextScreen; theNewURL = theResponse.encodeUrl (theNewURL); ServletContext theServletContext = theDBServlet.getServletContext (); theServletContext.getRequestDispatcher (theNewURL).forward (theRequest, theResponse); why are you encoding the url? DOing that will cause ? and = to be encoded as %whatever; so the query string wont be interpreted as you intend. Having said that I'm not sure if it would work anyway (o: Why not set an attribute in the request and then forward the request as is and have the servlet look for that attribute and act accordingly? btw - isn't this a tomcat-user question? cheesr dim
[DOC] status
Working on this Win98 laptop is enough to make me want to change trades. When you combine the awesome power of a K62-300 with a slow-arse 2GB HD, the sky's the limit... grumble! I'm going to duck out of docs until I get back to Vancouver and get myself situated. I wanted to really help get them in great shape before release, which I know you guys are working hard on. As it stands, I leave Waterloo, ON Aug 25th, so I'll be all settled in a few days after and put in some serious time before school starts the following week. Anyway, I'm just writing this cuz i was making all sorts of noise w.r.t docs but haven't really done much lately =/ I haven't forgotten about it, but fighting with cygwin and things that work everywhere else except for Win98 and my last two weeks of work and gaaahhh! Answering questions on the mailing list until then will hopefully be less stressful =) - r
Re[2]: Servlet Forward to Self? 4.0b7
why are you encoding the url? DOing that will cause ? and = to be encoded as %whatever; so the query string wont be interpreted as you intend. Not true, I am encoding the URL because I sometimes include quotes. It's not the issue here though, since it behaves the same way without encoding the URL. Having said that I'm not sure if it would work anyway (o: Why not set an attribute in the request and then forward the request as is and have the servlet look for that attribute and act accordingly? The dispatching code that handles the request expects a parameter to be set. The same problem would still occur if I used an attribute anyway. I could also implement my own request wrapper but that's what forward is designed to do so why not use the servlet API? btw - isn't this a tomcat-user question? Not really, I don't think the spec is clear on this question, and it should be made visible whether Tomcat4.0b7 support it or not. In any event, Tomcat4.0b7 throws the following exception when I try to do it. Unexpected Error Encountered... Cannot allocate servlet instance for path /frn/servlet/FRNServlet.FRNServletInnerFrame javax.servlet.ServletException: Cannot allocate servlet instance for path /frn/servlet/FRNServlet.FRNServletInnerFrame at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:406 ) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:180) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1125) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java :672) at org.apache.catalina.core.ApplicationDispatcher.doForward cheesr dim
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java
craigmcc01/08/14 18:47:01
Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java
Log:
Make StandardClassLoader sensitive to File.separator also.
It helps if you commit *all* of a patch instead of half of it :-)
Submitted by: Christopher Cain [EMAIL PROTECTED]
Revision ChangesPath
1.23 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
Index: StandardClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StandardClassLoader.java 2001/07/22 20:25:10 1.22
+++ StandardClassLoader.java 2001/08/15 01:47:01 1.23
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.22 2001/07/22 20:25:10 pier Exp $
- * $Revision: 1.22 $
- * $Date: 2001/07/22 20:25:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.23 2001/08/15 01:47:01 craigmcc Exp $
+ * $Revision: 1.23 $
+ * $Date: 2001/08/15 01:47:01 $
*
*
*
@@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.22 $ $Date: 2001/07/22 20:25:10 $
+ * @version $Revision: 1.23 $ $Date: 2001/08/15 01:47:01 $
*/
public class StandardClassLoader
@@ -1192,7 +1192,7 @@
streamHandler = factory.createURLStreamHandler(protocol);
// Validate the manifest of a JAR file repository
-if (!repository.endsWith(/)) {
+if (!repository.endsWith(File.separator)) {
try {
JarFile jarFile = null;
Manifest manifest = null;
[TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Hi,
I came across the need to use mod_rewrite to rewrite some URLs I was sending
to Tomcat.
After playing with it a bit (I had it working a while ago) and finding that
Tomcat was not receiving the rewritten URLs no matter what I did, I took a
look at the source to native/apache1.3/mod_jk.c. Not being much of an
Apache hacker, the variables were descriptive enough to tell me to make this
change to the file:
--- mod_jk.c.orig Tue Aug 14 17:58:21 2001
+++ mod_jk.cTue Aug 14 18:04:58 2001
@@ -358,7 +358,7 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-unparsed_uri;
+s-req_uri = r-uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
After this change my URLs were getting rewritten as expected again.
Can we apply this change to the tree if there's nothing wrong with it for
the next release? This problem has affected a large number of users, just
take a look at the tomcat-dev/user archives.
It seems that this change was made to satisfy the errata at
http://java.sun.com/products/servlet/errata_042700.html, but is it the
correct fix if we're intentionally munging the request?
Thanks,
Dave
Re: [PATCH] TC4 classes dir not loaded on win
On Fri, 10 Aug 2001, Christopher Cain wrote:
The {TC4_HOME}/server/classes directory, if created, fails to get
added as a repository in the ClassLoader on Windows machines. The
attached is a two-parter resolves the issue. I have tested the patch
set on both Win98 and Linux, which in this case means that it will
work on any other platforms as well.
Committed the relevant changes (plus a couple of cases you missed :-), and
created unit tests to make sure we can load both classes and resources
from either $CATALINA_HOME/classes or $CATALINA_HOME/lib/*.jar. Thanks!
Enjoy!
- Christopher
Craig
RE: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Hi David,
Unfortunately there are people who were breaking because
we didn't follow the spec. The better way to fix it is
to create an inverse function for
ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c]
in mod_jk... one that would 'unparse' the munged
r-uri rewrite and use it instead of r-unparsed_uri.
Keith
| -Original Message-
| From: David Rees [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, August 14, 2001 9:13 PM
| To: [EMAIL PROTECTED]
| Subject: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
|
|
| Hi,
|
| I came across the need to use mod_rewrite to rewrite some URLs I was sending
| to Tomcat.
|
| After playing with it a bit (I had it working a while ago) and finding that
| Tomcat was not receiving the rewritten URLs no matter what I did, I took a
| look at the source to native/apache1.3/mod_jk.c. Not being much of an
| Apache hacker, the variables were descriptive enough to tell me to make this
| change to the file:
|
| --- mod_jk.c.orig Tue Aug 14 17:58:21 2001
| +++ mod_jk.cTue Aug 14 18:04:58 2001
| @@ -358,7 +358,7 @@
| s-method = (char *)r-method;
| s-content_length = get_content_length(r);
| s-query_string = r-args;
| -s-req_uri = r-unparsed_uri;
| +s-req_uri = r-uri;
| if (s-req_uri != NULL) {
| char *query_str = strchr(s-req_uri, '?');
| if (query_str != NULL) {
|
| After this change my URLs were getting rewritten as expected again.
|
| Can we apply this change to the tree if there's nothing wrong with it for
| the next release? This problem has affected a large number of users, just
| take a look at the tomcat-dev/user archives.
|
| It seems that this change was made to satisfy the errata at
| http://java.sun.com/products/servlet/errata_042700.html, but is it the
| correct fix if we're intentionally munging the request?
|
| Thanks,
| Dave
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 06:13:24PM -0700, David Rees wrote:
--- mod_jk.c.orig Tue Aug 14 17:58:21 2001
+++ mod_jk.cTue Aug 14 18:04:58 2001
@@ -358,7 +358,7 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-unparsed_uri;
+s-req_uri = r-uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
After this change my URLs were getting rewritten as expected again.
Can we apply this change to the tree if there's nothing wrong with it for
the next release? This problem has affected a large number of users, just
take a look at the tomcat-dev/user archives.
This breaks query strings.
r-uri contains only the path portion of the URL. r-unparsed_uri
contains the URL in its virgin format - as sent by the client.
You can see that mod_jk is looking for the query string (look at the
strchr two lines down) - it won't be there in the r-uri. You now
need to modify mod_jk to look at r-args.
But, if you need access to the encoded URI (which is what the comment
above that line in the j-t-c version of mod_jk seems to indicate), the
only way to do it in httpd is to do with unparsed_uri. All of the
other parameters (i.e. r-uri) have been escaped already.
I'm not sure what the solution is. But, this one kills off query
strings to servlets. That's even worse than losing internal rewrite
capabilities.
I wonder how Pier is addressing this in mod_webapp. I'll have to
look. -- justin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote: Unfortunately there are people who were breaking because we didn't follow the spec. The better way to fix it is to create an inverse function for ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c] in mod_jk... one that would 'unparse' the munged r-uri rewrite and use it instead of r-unparsed_uri. Hi, OK, are you volunteering to write it? ;-) If not, I'll have to take a look when I get some time and see if I can figure it out. As an aside, it appears that Tomcat 3.3 remains broken in this regard, as it uses r-uri instead of r-unparsed_uri. -Dave
Re: [DOC] status
Quoting Rob S. [EMAIL PROTECTED]: [snip] Answering questions on the mailing list until then will hopefully be less stressful =) LOL Less stressful ... not likely. Noble endeavor ... absolutely! ;-)
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote: Hi David, Unfortunately there are people who were breaking because we didn't follow the spec. The better way to fix it is to create an inverse function for ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c] in mod_jk... one that would 'unparse' the munged r-uri rewrite and use it instead of r-unparsed_uri. You *could* just call ap_escape_uri and try to recreate the relevant pieces. Rough pseudocode: t1 = ap_escape_uri(r-uri) t2 = ap_escape_uri(r-args) mod_jk's-uri = strcat(r-uri, ?, r-args, NULL) The root problem is that r-unparsed_uri and r-uri may not be identical in their context. If you are using mod_rewrite, you could have: r-unparsed_uri=/foo.jsp?bar=baz r-uri=/spaz.jsp r-args=bar=baz But, now you may have escaped something that wasn't originally escaped. That may be bad as well. -- justin
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_jni_worker.c
mmanders01/08/14 19:27:31
Modified:src/native/mod_jk/common jk_jni_worker.c
Log:
Fixed bridge class name and rolled 3.2.3 fixes into 3.3.
Revision ChangesPath
1.3 +32 -8 jakarta-tomcat/src/native/mod_jk/common/jk_jni_worker.c
Index: jk_jni_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_jni_worker.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_jni_worker.c 2000/11/10 18:48:50 1.2
+++ jk_jni_worker.c 2001/08/15 02:27:31 1.3
@@ -57,7 +57,7 @@
* Description: In process JNI worker *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Based on: *
- * Version: $Revision: 1.2 $ *
+ * Version: $Revision: 1.3 $ *
***/
#if !defined(WIN32) !defined(NETWARE)
@@ -89,8 +89,9 @@
jint (JNICALL *jni_get_default_java_vm_init_args)(void *) = NULL;
jint (JNICALL *jni_create_java_vm)(JavaVM **, JNIEnv **, void *) = NULL;
+jint (JNICALL *jni_get_created_java_vms)(JavaVM **, int, int *) = NULL;
-#define JAVA_BRIDGE_CLASS_NAME (org/apache/tomcat/service/JNIEndpoint)
+#define JAVA_BRIDGE_CLASS_NAME (org/apache/tomcat/modules/server/JNIEndpoint)
static jk_worker_t *the_singleton_jni_worker = NULL;
@@ -688,10 +689,16 @@
(FARPROC)jni_create_java_vm =
GetProcAddress(hInst, JNI_CreateJavaVM);
+(FARPROC)jni_get_created_java_vms =
+GetProcAddress(hInst, JNI_GetCreatedJavaVMs);
+
(FARPROC)jni_get_default_java_vm_init_args =
GetProcAddress(hInst, JNI_GetDefaultJavaVMInitArgs);
+
+jk_log(l, JK_LOG_DEBUG,
+ Loaded all JNI procs\n);
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
return JK_TRUE;
}
@@ -711,9 +718,10 @@
}
if (0 != javaNlmHandle) {
jni_create_java_vm = ImportSymbol(GetNLMHandle(), JNI_CreateJavaVM);
+jni_get_created_java_vms = ImportSymbol(GetNLMHandle(),
JNI_GetCreatedJavaVMs);
jni_get_default_java_vm_init_args = ImportSymbol(GetNLMHandle(),
JNI_GetDefaultJavaVMInitArgs);
}
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
return JK_TRUE;
}
#else
@@ -729,9 +737,10 @@
dlerror());
} else {
jni_create_java_vm = dlsym(handle, JNI_CreateJavaVM);
+jni_get_created_java_vms = dlsym(handle, JNI_GetCreatedJavaVMs);
jni_get_default_java_vm_init_args = dlsym(handle,
JNI_GetDefaultJavaVMInitArgs);
-if(jni_create_java_vm jni_get_default_java_vm_init_args) {
+if(jni_create_java_vm jni_get_default_java_vm_init_args
jni_get_created_java_vms) {
jk_log(l, JK_LOG_DEBUG,
In load_jvm_dll, symbols resolved, done\n);
return JK_TRUE;
@@ -909,7 +918,7 @@
int optn = 0, err;
char* tmp;
-*env = NULL;
+*env = penv = NULL;
jk_log(l, JK_LOG_DEBUG,
Into open_jvm2\n);
@@ -970,10 +979,25 @@
}
jk_log(l, JK_LOG_DEBUG, In open_jvm2, about to create JVM...\n);
+
+err=jni_create_java_vm((p-jvm), penv, vm_args);
+
+if (JNI_EEXIST == err)
+{
+int vmCount;
+ jk_log(l, JK_LOG_DEBUG, JVM alread instantiated. Trying to attach
instead.\n);
-if((err=jni_create_java_vm((p-jvm), penv, vm_args)) != 0) {
+jni_get_created_java_vms((p-jvm), 1, vmCount);
+if (NULL != p-jvm)
+penv = attach_to_jvm(p, l);
+
+if (NULL != penv)
+err = 0;
+}
+
+if(err != 0) {
jk_log(l, JK_LOG_EMERG, Fail- could not create JVM, code: %d \n, err);
-return JK_FALSE;
+return JK_FALSE;
}
jk_log(l, JK_LOG_DEBUG, In open_jvm2, JVM created, done\n);
Re: [DOC] status
On Tue, 14 Aug 2001, Christopher Cain wrote: Quoting Rob S. [EMAIL PROTECTED]: [snip] Answering questions on the mailing list until then will hopefully be less stressful =) LOL Less stressful ... not likely. Noble endeavor ... absolutely! ;-) +1 +1 :-) Craig
cvs commit: jakarta-tomcat/src/native/mod_jk/jni jni_connect.dsp
mmanders01/08/14 19:28:22 Modified:src/native/mod_jk/jni jni_connect.dsp Log: Fixed include path for debug build. Revision ChangesPath 1.3 +1 -1 jakarta-tomcat/src/native/mod_jk/jni/jni_connect.dsp Index: jni_connect.dsp === RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/jni/jni_connect.dsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jni_connect.dsp 2001/02/15 12:23:58 1.2 +++ jni_connect.dsp 2001/08/15 02:28:22 1.3 @@ -69,7 +69,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /GZ /c -# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\jk /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /GZ /c +# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\common /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /GZ /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d _DEBUG
cvs commit: jakarta-tomcat/src/native/mod_jk/jni jk_jnicb.c jk_jnicb.exp jk_jnicb.h
mmanders01/08/14 19:28:56
Modified:src/native/mod_jk/jni jk_jnicb.c jk_jnicb.exp jk_jnicb.h
Log:
Fixed function names to match new classes.
Revision ChangesPath
1.2 +13 -13jakarta-tomcat/src/native/mod_jk/jni/jk_jnicb.c
Index: jk_jnicb.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/jni/jk_jnicb.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_jnicb.c2000/08/26 02:03:52 1.1
+++ jk_jnicb.c2001/08/15 02:28:56 1.2
@@ -56,7 +56,7 @@
/***
* Description: JNI callbacks implementation for the JNI in process adapter*
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.1 $ *
+ * Version: $Revision: 1.2 $ *
***/
#include jk_jnicb.h
@@ -65,12 +65,12 @@
#include jk_pool.h
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:getNumberOfHeaders
* Signature: (JJ)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_getNumberOfHeaders
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_getNumberOfHeaders
(JNIEnv *env, jobject o, jlong s, jlong l)
{
/* [V] Convert indirectly from jlong - int - pointer to shut up gcc */
@@ -94,12 +94,12 @@
}
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:read
* Signature: (JJ[BII)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_read
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_read
(JNIEnv *env, jobject o, jlong s, jlong l, jbyteArray buf, jint from, jint cnt)
{
jk_ws_service_t *ps = (jk_ws_service_t *)(int)s;
@@ -141,12 +141,12 @@
}
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:readEnvironment
* Signature: (JJ[Ljava/lang/String;)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_readEnvironment
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_readEnvironment
(JNIEnv *env, jobject o, jlong s, jlong l, jobjectArray envbuf)
{
jk_ws_service_t *ps = (jk_ws_service_t *)(int)s;
@@ -288,12 +288,12 @@
}
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:readHeaders
* Signature: (JJ[Ljava/lang/String;[Ljava/lang/String;)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_readHeaders
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_readHeaders
(JNIEnv *env, jobject o, jlong s, jlong l, jobjectArray hnames, jobjectArray
hvalues)
{
jk_ws_service_t *ps = (jk_ws_service_t *)(int)s;
@@ -330,12 +330,12 @@
}
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:startReasponse
* Signature: (JJILjava/lang/String;[Ljava/lang/String;[Ljava/lang/String;I)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_startReasponse
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_startReasponse
(JNIEnv *env, jobject o, jlong s, jlong l,
jint sc, jstring msg, jobjectArray hnames, jobjectArray hvalues, jint hcnt)
{
@@ -455,12 +455,12 @@
}
/*
- * Class: org_apache_tomcat_service_connector_JNIConnectionHandler
+ * Class: org_apache_tomcat_modules_server_JNIConnectionHandler
* Method:write
* Signature: (JJ[BII)I
*/
JNIEXPORT jint JNICALL
-Java_org_apache_tomcat_service_connector_JNIConnectionHandler_write
+Java_org_apache_tomcat_modules_server_JNIConnectionHandler_write
(JNIEnv *env, jobject o, jlong s, jlong l, jbyteArray buf, jint from, jint cnt)
{
jk_ws_service_t *ps = (jk_ws_service_t *)(int)s;
1.2 +6 -6 jakarta-tomcat/src/native/mod_jk/jni/jk_jnicb.exp
Index: jk_jnicb.exp
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/jni/jk_jnicb.exp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_jnicb.exp 2000/11/11
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIConnectionHandler.java
mmanders01/08/14 19:30:29
Modified:src/share/org/apache/tomcat/modules/server
JNIConnectionHandler.java
Log:
Added check for NetWare to load appropriate library.
Revision ChangesPath
1.10 +5 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java
Index: JNIConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JNIConnectionHandler.java 2001/02/27 02:55:41 1.9
+++ JNIConnectionHandler.java 2001/08/15 02:30:29 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java,v
1.9 2001/02/27 02:55:41 costin Exp $
- * $Revision: 1.9 $
- * $Date: 2001/02/27 02:55:41 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java,v
1.10 2001/08/15 02:30:29 mmanders Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/08/15 02:30:29 $
*
*
*
@@ -127,6 +127,8 @@
String os=System.getProperty( os.name ).toLowerCase();
if( os.indexOf(windows)= 0) {
f = new File(f, jni_connect.dll);
+} else if ( os.indexOf(netware)= 0) {
+f = new File(f, jni_conn.nlm);
} else {
f = new File(f, jni_connect.so);
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIEndpoint.java
mmanders01/08/14 19:32:02
Modified:src/share/org/apache/tomcat/modules/server JNIEndpoint.java
Log:
Added necessary synchronization around notify calls and added a stacktrace on
exceptions from calls to processConnection.
Revision ChangesPath
1.2 +12 -5
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java
Index: JNIEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JNIEndpoint.java 2000/09/17 06:37:53 1.1
+++ JNIEndpoint.java 2001/08/15 02:32:02 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
1.1 2000/09/17 06:37:53 costin Exp $
- * $Revision: 1.1 $
- * $Date: 2000/09/17 06:37:53 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
1.2 2001/08/15 02:32:02 mmanders Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/08/15 02:32:02 $
*
*
*
@@ -95,13 +95,17 @@
// the handler is no longer useable
if( handler==null ) {
running=false;
- notify();
+synchronized(this) {
+notify();
+}
return;
}
System.out.println(Running ...);
running=true;
-notify();
+synchronized(this) {
+notify();
+}
}
// JNI Entry points
@@ -156,6 +160,9 @@
return 1;
} catch(Throwable t) {
// Throwables are not allowed into the native code !!!
+// print it out so that we can debug it later.
+System.out.println(Caught throwable + t);
+t.printStackTrace();
}
}
return 0;
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 07:25:32PM -0700, David Rees wrote:
On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote:
Unfortunately there are people who were breaking because
we didn't follow the spec. The better way to fix it is
to create an inverse function for
ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c]
in mod_jk... one that would 'unparse' the munged
r-uri rewrite and use it instead of r-unparsed_uri.
Hi,
OK, are you volunteering to write it? ;-) If not, I'll have to take a look
when I get some time and see if I can figure it out.
As an aside, it appears that Tomcat 3.3 remains broken in this regard, as it
uses r-uri instead of r-unparsed_uri.
My bad. It is actually easier than I just said - s-req_uri isn't
the complete unparsed URI - just the path.
I didn't look high enough in mod_jk.c. The version in j-t-c for
apache-1.3 has:
s-query_string = r-args;
/*
* The 2.2 servlet spec errata says the uri from
* HttpServletRequest.getRequestURI() should remain encoded.
* [http://java.sun.com/products/servlet/errata_042700.html]
*/
s-req_uri = r-unparsed_uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}
That strchr call is trying to remove the query string (dicking with
the unparsed_uri like that is a BAD idea - imagine logs looking at the
unparsed_uri).
You could just have:
s-query_string = r-args;
/*
* The 2.2 servlet spec errata says the uri from
* HttpServletRequest.getRequestURI() should remain encoded.
* [http://java.sun.com/products/servlet/errata_042700.html]
*/
s-req_uri = ap_encode_uri(r-pool, r-uri);
That seems like it'd satisfy everyone. -- justin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Justin Erenkrantz at [EMAIL PROTECTED] wrote: I wonder how Pier is addressing this in mod_webapp. I'll have to look. -- justin Easy as 1.2.3... WARP has a concept of URI and QUERY STRING... Very separate things... All I do is req-ruri=apr_pstrdup(req-pool,r-uri); req-args=apr_pstrdup(req-pool,r-args); The URI goes into the URI, the query string goes into the query string... Apache does it for me, why should I bother? :) Pier
cvs commit: jakarta-tomcat/src/etc jni_server.xml
mmanders01/08/14 19:39:35 Added: src/etc jni_server.xml Log: Sample jni_server.xml that matches 3.3 setup. Revision ChangesPath 1.4 +176 -59 jakarta-tomcat/src/etc/jni_server.xml
cvs commit: jakarta-tomcat/src/etc/jk jni_workers.properties
mmanders01/08/14 19:40:04 Modified:src/etc/jk jni_workers.properties Log: Updated file to match 3.3 configuration. Revision ChangesPath 1.2 +4 -8 jakarta-tomcat/src/etc/jk/jni_workers.properties Index: jni_workers.properties === RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/jni_workers.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jni_workers.properties2000/09/09 23:21:20 1.1 +++ jni_workers.properties2001/08/15 02:40:04 1.2 @@ -16,12 +16,8 @@ # # Additional class path components. # -worker.jni.class_path=d:\tomcat\classes -worker.jni.class_path=d:\tomcat\lib\xml.jar -worker.jni.class_path=d:\tomcat\lib\jasper.jar -worker.jni.class_path=d:\tomcat\lib\servlet.jar -worker.jni.class_path=d:\tomcat\lib\webserver.jar -worker.jni.class_path=d:\sdk\jdk1.2.2\lib\tools.jar +worker.jni.class_path=d:\temp\tomcat\lib\container\tomcat-startup.jar +worker.jni.class_path=d:\temp\tomcat\lib\container\tomcat_modules.jar # worker.jni.class_path=d:\SQLLIB\java\db2java.zip # @@ -45,8 +41,8 @@ # # Setting the place for the stdout and stderr of tomcat # -worker.jni.stdout=d:\tomcat\jvm.stdout -worker.jni.stderr=d:\tomcat\jvm.stderr +worker.jni.stdout=d:\tomcat\logs\jvm.stdout +worker.jni.stderr=d:\tomcat\logs\jvm.stderr # # Setting the tomcat.home Java property
cvs commit: jakarta-tomcat/src/etc/jk mod_jk.conf-jni
mmanders01/08/14 19:40:37 Added: src/etc/jk mod_jk.conf-jni Log: Sample configuration file for use with JNI configuration. Revision ChangesPath 1.1 jakarta-tomcat/src/etc/jk/mod_jk.conf-jni Index: mod_jk.conf-jni === LoadModule jk_module modules/mod_jk.dll IfModule mod_jk.c JkWorkersFile fill-path-to/jni_workers.properties JkLogFile logs/mod_jk-jni.log JkLogLevel error JkMount /*.jsp jni JkMount /servlet/* jni JkMount /examples/* jni /IfModule
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Wed, Aug 15, 2001 at 03:41:30AM +0100, Pier P. Fumagalli wrote: Justin Erenkrantz at [EMAIL PROTECTED] wrote: I wonder how Pier is addressing this in mod_webapp. I'll have to look. -- justin Easy as 1.2.3... WARP has a concept of URI and QUERY STRING... Very separate things... All I do is req-ruri=apr_pstrdup(req-pool,r-uri); req-args=apr_pstrdup(req-pool,r-args); The URI goes into the URI, the query string goes into the query string... Apache does it for me, why should I bother? :) Which, of course, is the right solution. But, do you have to (re)escape the uri (or, is that done in Java land?)? Seems like the 2.2 spec says that the getRequestURI() function must return an escaped URI. r-uri is unescaped. Or, does 2.3 say something different? -- justin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Justin Erenkrantz at [EMAIL PROTECTED] wrote: On Wed, Aug 15, 2001 at 03:41:30AM +0100, Pier P. Fumagalli wrote: Justin Erenkrantz at [EMAIL PROTECTED] wrote: I wonder how Pier is addressing this in mod_webapp. I'll have to look. -- justin Easy as 1.2.3... WARP has a concept of URI and QUERY STRING... Very separate things... All I do is req-ruri=apr_pstrdup(req-pool,r-uri); req-args=apr_pstrdup(req-pool,r-args); The URI goes into the URI, the query string goes into the query string... Apache does it for me, why should I bother? :) Which, of course, is the right solution. DOH! :) Am I lucky or what :) :) :) But, do you have to (re)escape the uri (or, is that done in Java land?)? Seems like the 2.2 spec says that the getRequestURI() function must return an escaped URI. r-uri is unescaped. Or, does 2.3 say something different? -- justin It's done in Java land (well, in theory! :) I should really check, that might be one hit of performance improvement (like 1 millisecond per request). Ok, get over it Pier, performance is after the beta :) Pier (love talking to himself -who, me?- at 4 AM :)
RE: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
| This breaks query strings. | | r-uri contains only the path portion of the URL. r-unparsed_uri | contains the URL in its virgin format - as sent by the client. No, I don't believe this is quite right. getRequestURI() in a servlet should return r-unparsed_uri minus a query string. Setting s-uri = r-uri doesn't break query strings.. but it *does* break the encoding of the uri. So tc 3.3 is currently broken as is mod_webapp (unless the string is encoded on the java side in TC4). However, Justin, I think your suggestion is the correct solution: s-req_uri = ap_encode_uri(r-pool, r-uri); David, or anyone else interested too, would you try this with some corner test cases and see if it lives up to expectation? Keith
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, 14 Aug 2001, Justin Erenkrantz wrote: Which, of course, is the right solution. Is it ? Re-escaping the URI will most likely generate something very different from the original, it's not symetrical. Getting a re-escaped request is different from the original, unescaped uri. That's the reason we use the unescaped uri... Costin
RE: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Costin's right.. seems like the problem encountered was that there was no way to recreate the encoding (or lack thereof) on the original uri. So the kludge/solution was to use the unparsed uri and chop off the query string. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, August 14, 2001 11:13 PM | To: [EMAIL PROTECTED] | Subject: Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix | | | On Tue, 14 Aug 2001, Justin Erenkrantz wrote: | | Which, of course, is the right solution. | | Is it ? Re-escaping the URI will most likely generate something very | different from the original, it's not symetrical. Getting a re-escaped | request is different from the original, unescaped uri. That's the reason | we use the unescaped uri... | | Costin |
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
You could just have: s-query_string = r-args; /* * The 2.2 servlet spec errata says the uri from * HttpServletRequest.getRequestURI() should remain encoded. * [http://java.sun.com/products/servlet/errata_042700.html] */ s-req_uri = ap_encode_uri(r-pool, r-uri); Sounds like a reasonable solution. Costin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 08:12:31PM -0700, [EMAIL PROTECTED] wrote: On Tue, 14 Aug 2001, Justin Erenkrantz wrote: Which, of course, is the right solution. Is it ? Re-escaping the URI will most likely generate something very different from the original, it's not symetrical. Getting a re-escaped request is different from the original, unescaped uri. That's the reason we use the unescaped uri... Potentially, you are correct. It may not be symmetrical. However, httpd may jump in and rewrite the uri for you. If that is a problem (which is what the original poster was complaining about), then you need to use r-uri instead and escape it. Unless you want to only pass the original string NOT what the server is serving. I'm not sure what the Servlet spec says - use the original string that the client passed in, or use the real URI. I'm out of my depth here. *shrug* -- justin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 11:13:34PM -0400, Keith Wannamaker wrote: Costin's right.. seems like the problem encountered was that there was no way to recreate the encoding (or lack thereof) on the original uri. So the kludge/solution was to use the unparsed uri and chop off the query string. mod_jk chops off the r-unparsed_uri itself without copying. Negative points for style. =-) -- justin
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, 14 Aug 2001, Justin Erenkrantz wrote: On Wed, Aug 15, 2001 at 03:41:30AM +0100, Pier P. Fumagalli wrote: Justin Erenkrantz at [EMAIL PROTECTED] wrote: I wonder how Pier is addressing this in mod_webapp. I'll have to look. -- justin Easy as 1.2.3... WARP has a concept of URI and QUERY STRING... Very separate things... All I do is req-ruri=apr_pstrdup(req-pool,r-uri); req-args=apr_pstrdup(req-pool,r-args); The URI goes into the URI, the query string goes into the query string... Apache does it for me, why should I bother? :) Which, of course, is the right solution. But, do you have to (re)escape the uri (or, is that done in Java land?)? Seems like the 2.2 spec says that the getRequestURI() function must return an escaped URI. r-uri is unescaped. Or, does 2.3 say something different? -- justin The getRequestURI() method is supposed to return the *undecoded* request URI. As Costin points out, re-escaping an escaped version is not the same thing. This didn't change in 2.3 -- however, in 2.2. it wasn't formally documented until an errata was published: http://java.sun.com/products/servlet/errata_042700.html Same thing for getQueryString() -- must remain undecoded. Craig
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 11:05:38PM -0400, Keith Wannamaker wrote: | This breaks query strings. | | r-uri contains only the path portion of the URL. r-unparsed_uri | contains the URL in its virgin format - as sent by the client. No, I don't believe this is quite right. getRequestURI() in a servlet should return r-unparsed_uri minus a query string. Setting s-uri = r-uri doesn't break query strings.. but it *does* break the encoding of the uri. So tc 3.3 is currently broken as is mod_webapp (unless the string is encoded on the java side in TC4). However, Justin, I think your suggestion is the correct solution: s-req_uri = ap_encode_uri(r-pool, r-uri); David, or anyone else interested too, would you try this with some corner test cases and see if it lives up to expectation? I gave it a shot and it compiled fine, but got this error at runtime: Cannot load /usr/local/apache/libexec/mod_jk.so into server: /usr/local/apache/libexec/mod_jk.so: undefined symbol: ap_encode_uri Any hints? I'm new at Apache module hacking. -Dave
RE: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Try ap_escape_uri Keith | | s-req_uri = ap_encode_uri(r-pool, r-uri); | | David, or anyone else interested too, would you | try this with some corner test cases and see if | it lives up to expectation? | | I gave it a shot and it compiled fine, but got this error at runtime: | | Cannot load /usr/local/apache/libexec/mod_jk.so into server: | /usr/local/apache/libexec/mod_jk.so: undefined symbol: ap_encode_uri | | Any hints? I'm new at Apache module hacking. | | -Dave
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, 14 Aug 2001, Justin Erenkrantz wrote: mod_jk chops off the r-unparsed_uri itself without copying. Negative points for style. =-) -- justin That's true. However I'm not sure what else could we do - copy it once again to another buffer where we chop it ? It's not very much going on with the unparsed uri. If you strictly follow the spec, mod_rewrite is out of question - and same for most other apache modules that alter the request. Since all of them are working on the URI, the result is just something that has no unmodified orginal. However, if you read the URI spec, 2 URIs are equivalent if the octets are identical - it doesn't matter how you encode it. Re-escaping the URI has the extra benefit of getting a canonical escaping, which is also a bit safer ( hey, we also get the first class security checks apache is doing on the parsed uris ). Another note - my understanding of the HTTP specification is that proxies _are_ allowed to escape/unescape the URI - as long as the result is equivalent. So if a proxy is used, the original URI the user typed will be lost. Same for the browsers - what the user types is very different from what is sent ( at least in Opera ). Of course, we can define unparsed URI to be whatver the servlet container receives. This may be different from the original request ( if it goes through proxies ). Now the question is - where does the container starts :=). I think there are plenty of reasons to treat the Apache as not beeing part of the container - after all it follows completely different rules on mappings ( extension mapps can have path info), and in almost everything. In fact, I'm not sure all web servers even allow access to the original unescaped URI. Some IIS or NES expert should let us know. So my take is that the container should indeed return the original URI - that the container received. What apache does ( like rewriting, or canonicalise the URI ) is separate. Otherwise - the rewriting itself would violate the servlet spec, since it would alter the URI. Again - I would bet that at least one of IIS and NES doesn't allow access to original URI anyway. Costin P.S. Quite a long mail for something as simple as 1-2-3, I spend quite a lot of time with this issue - Larry may remember how long the bug was open and with my name on it.
mod_jk + jni configuration
Hi, I'm testing the jni fixes Mike just commited, and I need some feedback on the JNI configuration. Right now we have a different set of files: jni_workers.properties, mod-jk.conf-jni, jni-server.xml. The alternate set of files was first introduced because JNI is difficult to set up, and it was felt most users will use tomcat in 'normal' mode for testing, etc, and jni mode to run with apache. However, it may be better to be consistent with the rest of the configuration, and use the normal config files. workers.properties already have the definition for the 'inprocess' worker, server.xml has the JniModule, ApacheConfig can generate config files that are usable with the jni worker. So my proposal is to remove the old config files ( and fix the documentation ), and use the normal configs. If you want to use JNI, you'll have to set things up - edit server.xml and uncomment ( and set the paths ) the Jni connector, make ApacheConfig generate the right config ( jkProtocol=jni ), add 'inprocess' to the list of workers. Same thing you would do for Ajp13 support ( except for ajp13 you just need the port ). What do you think ? Costin
Re: mod_jk + jni configuration
On Tue, 14 Aug 2001 [EMAIL PROTECTED] wrote: Hi, I'm testing the jni fixes Mike just commited, and I need some feedback on the JNI configuration. Ok, I've got it to work - it's just fine, great. However, the fine is fine only with JDK1.2.2. I wasn't able to get it working with any of the 1.3 VMs - sun, blackdown, IBM. The errors are different - with classic I got a symbol not found, with client or server I get a java dump ( the one that shows all the threads and then core dumps ), for IBM I get a -1 code. This is probably due to VM bugs, maybe my settings ( for the symbol not found, even tough the LD_LIBRARY_PATH was set ). The JNI worker works ( if libjava.so is ok). The good news - it works fine with JDK1.4beta... Surprise ( at least for me, I didn't expected that - it's just a beta ). I'll continue to try with the other vms. My proposal: given that JNI is so tricky and dependent on vm, etc, I think we should make sure the fixes are merged into jakarta-tomcat-connectors, where the development will continue ( we still have to finish ajp14 and improve the configuration ). For the official release, what we have right now is decent enough - JNI has some great benefits, but I expect it to be used only by very advanced users ( heck, I may not be that advanced myself, I remember I once got it to work with IBM1.3 ). Each VM has it's tricks ( sometimes a LD_LIBRARY_PATH, or strange bugs, etc). In time we can improve on this. From what Mike said ( and other people ), it seems the windows version works fine ( and that's where it'll be easy to provide DLLs ). That covers IIS as well. For Unix - Apache2.0 is not FCS yet, and for NES - I have a strong feeling mod_jk will work with the same VM NES is using ( they also use JNI - and probably have similar issues, we use just standard invocation ) Costin
Re: CATALINA_HOME vs. TOMCAT_HOME
On Tue, 14 Aug 2001, Pier P. Fumagalli wrote: Dennis Doubleday at [EMAIL PROTECTED] wrote: At 01:03 PM 8/14/01, you wrote: On Tue, 14 Aug 2001, Dennis Doubleday wrote: These two environment variable names seem to be used interchangeably in various installation documents and discussions. Are they in fact interchangeable (i.e. I can set one or the other and it doesn't matter which)? No, you need to use TOMCAT_HOME for Tomcat 3.x and CATALINA_HOME for Tomcat 4.x. Thanks. The release notes for 4.0b6 contain a number of TOMCAT_HOME references. Correct... And I found it also in other places: webapps, documentation and so on... Should we change them? All the references to TOMCAT_HOME in Tomcat 4 docs should be changed. Also, for the release notes, should we change only the LAST, or all of them? I would suggest *never* changing old release notes -- we want them to reflect what was actually shipped with that release. Just add an entry to the newest release notes doc to say that we updated the docs themselves. Pier Craig
Re: CATALINA_HOME vs. TOMCAT_HOME
Craig R. McClanahan at [EMAIL PROTECTED] wrote: Correct... And I found it also in other places: webapps, documentation and so on... Should we change them? All the references to TOMCAT_HOME in Tomcat 4 docs should be changed. 'k... Will take care of it today... Also, for the release notes, should we change only the LAST, or all of them? I would suggest *never* changing old release notes -- we want them to reflect what was actually shipped with that release. Just add an entry to the newest release notes doc to say that we updated the docs themselves. Agreed... So, I'm going to change it in RELEASE_NOTES_B8.txt, leave the old as is, (mention it in RELEASE notes, of course), then update all docs and whops! done :) Pier
Re: CATALINA_HOME vs. TOMCAT_HOME
Pier P. Fumagalli at [EMAIL PROTECTED] wrote: Agreed... So, I'm going to change it in RELEASE_NOTES_B8.txt, leave the old as is, (mention it in RELEASE notes, of course), then update all docs and whops! done :) Done :) Thanks Dennis Pier
wrapper: Java Virtual Machine crashed
Hi Folks: I know this is probably asking to much from your side. I am pretty much exhausted from my resources, I don't know where is the problem. I put the log level to debug and see that when I start Apache which automatically also starts the JVM, JVM crashes. the mod_jserv.log shows that error. (INFO) wrapper: Shutdown done (PID=711) (INFO) Apache Module was cleaned-up (INFO) wrapper: Java Virtual Machine started (PID=754) (INFO) wrapper: controller started (PID=711) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=681) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=741) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=821) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=53) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=705) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: Java Virtual Machine started (PID=647) (INFO) wrapper: Java Virtual Machine crashed (INFO) wrapper: VM died too many times w/in 5 second intervals (6); no more tries (INFO) wrapper: too many restart attempts w/in a short timeframe; no more retries. Attached are all the config/properties files. Again, all your help is highly appreciated. Regards. Rakesh Singh, IBM Global Services Phone: 717-705-9884
