Re: New repository org
Mark Thomas wrote: Using externals wasn't something I had thought of but if offers a nice way to provide all the source for one version in a single chekcout. We now have tomcat/current/5.5.x that uses externals to link in all the various modules. That's actually what I was thinking about, looks great. Now, the big question - where can I add a sandbox/experimental directory? Costin Mark Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separate repos. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Could we just move all in tomcat5.5 ( and HEAD ) into one repository ( say, tomcat ) ? Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separate repos. Costin Remy Maucherat wrote: Bill Barker wrote: It occurs to me that I may have misunderstood, and you were just talking about setting up the svn:externals for tomcat/current. If that's the case, then +0 (I don't really care, but I'm glad that somebody does :). svn:externals sounds like a cool feature, I guess I'll have to look it up to know what it does. Mark Thomas wrote: If by this you mean do a checkout of http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x to a directory called build in the build scripts then +1. If it involves any form of svn move -1 since I don't understand what you are planning to move to where and I have concerns about complications that might be created for checkouts, future branches and future tags. No, I don't want to do any change to the repository. The problem is that svn isn't like CVS, so someone (like me, I tried it) which would checkout http://svn.apache.org/repos/asf/tomcat would be in trouble. It would be better to organize the developer environment. Right now, it organizes things using jakarta-tomcat-5, and all the other jakarta folders. CVS was simpler ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
costin 2005/09/28 23:07:24
Modified:.build.xml
Log:
Add a target to build the standalone jar - in case anyone wants to play with
it.
Revision ChangesPath
1.239 +87 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.238
retrieving revision 1.239
diff -u -r1.238 -r1.239
--- build.xml 22 Sep 2005 10:39:37 - 1.238
+++ build.xml 29 Sep 2005 06:07:24 - 1.239
@@ -192,6 +192,7 @@
property name=tomcat-util.build value=${tomcat.build} /
property name=tomcat-util.lib value=${tomcat.build}/server/lib /
/ant
+
/target
target name=build-tomcatjk unless=tomcatjk.build.notrequired
@@ -658,7 +659,7 @@
!-- antcall target=build-commons-modeler / --
!-- antcall target=build-commons-daemon / --
- antcall target=downloadgz
+antcall target=downloadgz
param name=sourcefile value=${commons-collections-src.loc}/
param name=destfile value=${tomcat-dbcp.jar} /
/antcall
@@ -1167,6 +1168,90 @@
/ant
/target
+ !-- === Single-jar tomcat === --
+ target name=prepare-runtime-once
+ description=Do once before single jar tomcat
+mkdir dir=runtime/deps /
+mkdir dir=runtime/classes /
+unjar dest=runtime/deps
src=${base.path}/servlet-api-2.4/lib/servlet-api.jar /
+!-- unjar dest=runtime/deps
src=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
+unjar dest=runtime/deps
src=${base.path}/commons-modeler-1.1/commons-modeler.jar/
+unjar dest=runtime/deps
src=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
+ /target
+
+
+ target name=compile-runtime
+ description=Build single jar tomcat
+
+ javac destdir=runtime/classes deprecation=false debug=false
+!-- classpath
path=${base.path}/commons-beanutils-1.6.1/commons-beanutils.jar/ --
+!-- classpath
path=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
+classpath
path=${base.path}/commons-modeler-1.1/commons-modeler.jar/
+classpath path=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
+classpath
path=${base.path}/servlet-api-2.4/lib/servlet-api.jar/
+classpath path=${base.path}/jmxri-1.2.1.jar/
+
+src
+pathelement path=${jtc.home}/util/java/
+pathelement path=${jtc.home}/mini/java /
+!-- pathelement path=${jtc.home}/naming/src/ --
+pathelement path=${jtc.home}/coyote/src/java/
+pathelement path=${jtc.home}/http11/src/java/
+pathelement path=${catalina.home}/catalina/src/share/
+/src
+exclude name=org/apache/naming/*.java/
+exclude name=org/apache/naming/ant/**/
+exclude name=org/apache/tomcat/util/net/puretls/**/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15SocketFactory.java/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15Factory.java/
+exclude name=org/apache/tomcat/util/net/AprEndpoint.java/
+exclude name=org/apache/coyote/tomcat3/**/
+exclude name=org/apache/coyote/tomcat4/**/
+exclude name=org/apache/coyote/memory/**/
+exclude name=org/apache/coyote/standalone/**/
+exclude
name=org/apache/coyote/http11/Http11AprProcessor.java/
+exclude name=org/apache/coyote/http11/Http11AprProtocol.java/
+exclude
name=org/apache/coyote/http11/InternalAprInputBuffer.java/
+exclude
name=org/apache/coyote/http11/InternalAprOutputBuffer.java/
+exclude name=**/CatalinaLaunchFilter.java/
+exclude name=**/MailSessionFactory.java/
+exclude name=**/SendMailFactory.java/
+exclude name=**/SemaphoreValve.java/
+exclude name=org/apache/catalina/ant/**/
+exclude name=org/apache/catalina/ssi/**/
+exclude
name=org/apache/catalina/loader/CatalinaModuleListener.java/
+/javac
+
+copy todir=runtime/classes
+fileset dir=${jtc.home}/util/java includes=**/*.properties
**/*.xml/
+fileset dir=${jtc.home}/naming/src includes=**/*.properties
**/*.xml/
+fileset dir=${jtc.home}/coyote/src/java
includes=**/*.properties **/*.xml
+ exclude name=org/apache/coyote/tomcat4/**/
+/fileset
+fileset dir=${jtc.home}/http11/src/java
includes=**/*.properties **/*.xml/
+fileset dir=${catalina.home}/catalina/src/share
includes=**/*.properties **/*.xml/
+/copy
+
+jar jarfile=runtime/tomcat-runtime.jar
manifest
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Remy Maucherat wrote: Jan Luehe wrote: As a reminder, CVS shound't be used anymore. I commited a bunch of small changes, don't know how easy it'll be to get them in after the switch to svn. Let me know if there's a problem, I can roll them back. BTW - I had some of the changes in IntrospectionUtils in my workspace as well, so I don't have to commit that :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.xml
BTW - there are still few files missing, but the end result is a 1.2M
jar containing all deps, that can be run with java -jar and only
requires a webapps/ dir in the current dir.
Costin
[EMAIL PROTECTED] wrote:
costin 2005/09/28 23:07:24
Modified:.build.xml
Log:
Add a target to build the standalone jar - in case anyone wants to play with
it.
Revision ChangesPath
1.239 +87 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.238
retrieving revision 1.239
diff -u -r1.238 -r1.239
--- build.xml 22 Sep 2005 10:39:37 - 1.238
+++ build.xml 29 Sep 2005 06:07:24 - 1.239
@@ -192,6 +192,7 @@
property name=tomcat-util.build value=${tomcat.build} /
property name=tomcat-util.lib value=${tomcat.build}/server/lib /
/ant
+
/target
target name=build-tomcatjk unless=tomcatjk.build.notrequired
@@ -658,7 +659,7 @@
!-- antcall target=build-commons-modeler / --
!-- antcall target=build-commons-daemon / --
- antcall target=downloadgz
+antcall target=downloadgz
param name=sourcefile value=${commons-collections-src.loc}/
param name=destfile value=${tomcat-dbcp.jar} /
/antcall
@@ -1167,6 +1168,90 @@
/ant
/target
+ !-- === Single-jar tomcat === --
+ target name=prepare-runtime-once
+ description=Do once before single jar tomcat
+mkdir dir=runtime/deps /
+mkdir dir=runtime/classes /
+unjar dest=runtime/deps
src=${base.path}/servlet-api-2.4/lib/servlet-api.jar /
+!-- unjar dest=runtime/deps
src=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
+unjar dest=runtime/deps
src=${base.path}/commons-modeler-1.1/commons-modeler.jar/
+unjar dest=runtime/deps
src=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
+ /target
+
+
+ target name=compile-runtime
+ description=Build single jar tomcat
+
+ javac destdir=runtime/classes deprecation=false debug=false
+!-- classpath
path=${base.path}/commons-beanutils-1.6.1/commons-beanutils.jar/ --
+!-- classpath
path=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
+classpath
path=${base.path}/commons-modeler-1.1/commons-modeler.jar/
+classpath path=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
+classpath
path=${base.path}/servlet-api-2.4/lib/servlet-api.jar/
+classpath path=${base.path}/jmxri-1.2.1.jar/
+
+src
+pathelement path=${jtc.home}/util/java/
+pathelement path=${jtc.home}/mini/java /
+!-- pathelement path=${jtc.home}/naming/src/ --
+pathelement path=${jtc.home}/coyote/src/java/
+pathelement path=${jtc.home}/http11/src/java/
+pathelement path=${catalina.home}/catalina/src/share/
+/src
+exclude name=org/apache/naming/*.java/
+exclude name=org/apache/naming/ant/**/
+exclude name=org/apache/tomcat/util/net/puretls/**/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15SocketFactory.java/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15Factory.java/
+exclude name=org/apache/tomcat/util/net/AprEndpoint.java/
+exclude name=org/apache/coyote/tomcat3/**/
+exclude name=org/apache/coyote/tomcat4/**/
+exclude name=org/apache/coyote/memory/**/
+exclude name=org/apache/coyote/standalone/**/
+exclude
name=org/apache/coyote/http11/Http11AprProcessor.java/
+exclude name=org/apache/coyote/http11/Http11AprProtocol.java/
+exclude
name=org/apache/coyote/http11/InternalAprInputBuffer.java/
+exclude
name=org/apache/coyote/http11/InternalAprOutputBuffer.java/
+exclude name=**/CatalinaLaunchFilter.java/
+exclude name=**/MailSessionFactory.java/
+exclude name=**/SendMailFactory.java/
+exclude name=**/SemaphoreValve.java/
+exclude name=org/apache/catalina/ant/**/
+exclude name=org/apache/catalina/ssi/**/
+exclude
name=org/apache/catalina/loader/CatalinaModuleListener.java/
+/javac
+
+copy todir=runtime/classes
+fileset dir=${jtc.home}/util/java includes=**/*.properties
**/*.xml/
+fileset dir=${jtc.home}/naming/src includes=**/*.properties
**/*.xml/
+fileset dir=${jtc.home}/coyote/src/java includes=**/*.properties
**/*.xml
+ exclude name=org/apache/coyote/tomcat4/**/
+/fileset
+fileset dir=${jtc.home}/http11/src
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionHook.java ActionCode.java Adapter.java InputBuffer.java OutputBuffer.java Processor.java ProtocolHandler.java Request.java
costin 2005/09/28 23:27:50
Modified:coyote/src/java/org/apache/coyote ActionHook.java
ActionCode.java Adapter.java InputBuffer.java
OutputBuffer.java Processor.java
ProtocolHandler.java Request.java
Log:
Just a bunch of comments.
Revision ChangesPath
1.3 +11 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionHook.java
Index: ActionHook.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionHook.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ActionHook.java 24 Feb 2004 08:54:29 - 1.2
+++ ActionHook.java 29 Sep 2005 06:27:50 - 1.3
@@ -18,7 +18,17 @@
/**
- * Action hook.
+ * Action hook. Actions represent the callback mechanism used by
+ * coyote servlet containers to request operations on the coyote connectors.
+ * Some standard actions are defined in ActionCode, however custom
+ * actions are permitted.
+ *
+ * The param object can be used to pass and return informations related with
the
+ * action.
+ *
+ *
+ * This interface is typically implemented by ProtocolHandlers, and the param
+ * is usually a Request or Response object.
*
* @author Remy Maucherat
*/
1.18 +8 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
Index: ActionCode.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ActionCode.java 16 May 2005 04:58:00 - 1.17
+++ ActionCode.java 29 Sep 2005 06:27:50 - 1.18
@@ -19,7 +19,13 @@
/**
* Enumerated class containing the adapter event codes.
+ * Actions represent callbacks from the servlet container to the coyote
+ * connector.
*
+ * Actions are implemented by ProtocolHandler, using the ActionHook
interface.
+ *
+ * @see ProtocolHandler
+ * @see ActionHook
* @author Remy Maucherat
*/
public final class ActionCode {
@@ -40,6 +46,8 @@
/**
* A flush() operation originated by the client ( i.e. a flush() on
* the servlet output stream or writer, called by a servlet ).
+ *
+ * Argument is the Response.
*/
public static final ActionCode ACTION_CLIENT_FLUSH = new ActionCode(4);
1.3 +3 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Adapter.java
Index: Adapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Adapter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Adapter.java 24 Feb 2004 08:54:29 - 1.2
+++ Adapter.java 29 Sep 2005 06:27:50 - 1.3
@@ -18,9 +18,11 @@
/**
- * Adapter.
+ * Adapter. This represents the entry point in a coyote-based servlet
container.
+ *
*
* @author Remy Maucherat
+ * @see ProtocolHandler
*/
public interface Adapter {
1.8 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java
Index: InputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/InputBuffer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- InputBuffer.java 24 Feb 2004 08:54:29 - 1.7
+++ InputBuffer.java 29 Sep 2005 06:27:50 - 1.8
@@ -23,6 +23,10 @@
/**
* Input buffer.
+ *
+ * This class is used only in the protocol implementation. All reading from
tomcat ( or adapter ) should be done
+ * using Request.doRead().
+ *
*
* @author Remy Maucherat
*/
1.8 +11 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- OutputBuffer.java 24 Feb 2004 08:54:29 - 1.7
+++ OutputBuffer.java 29 Sep 2005 06:27:50 - 1.8
@@ -23,13 +23,23 @@
/**
* Output buffer.
+ *
+ * This class is used internally by the protocol implementation. All writes
from higher level code should happen
+ * via Resonse.doWrite().
*
* @author Remy Maucherat
*/
public interface OutputBuffer {
-public int doWrite(ByteChunk chunk
cvs commit: jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader Loader.java Module.java ModuleClassLoader.java ModuleListener.java Repository.java package.html LoaderProperties.java
costin 2005/09/28 23:35:48
Modified:util/loader/org/apache/tomcat/util/loader Loader.java
Module.java ModuleClassLoader.java
ModuleListener.java Repository.java package.html
Removed: util/loader/org/apache/tomcat/util/loader
LoaderProperties.java
Log:
AFAIK this is not currently used, it's just an experimental refactoring of
the loading I started long time ago. Besides beeing
useable standalone and more generic, it supports few extra features, like
reloading of .jar files and using a 'flat' loader, similar with jboss and jmx.
- refactoring to clean up the interfaces ( code is based on catalina loader )
- add support for delegating to a parent classloader, needed for the case
this is embeded in another app
- fix various things.
Revision ChangesPath
1.3 +396 -36
jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Loader.java
Index: Loader.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Loader.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Loader.java 6 Oct 2004 15:41:44 - 1.2
+++ Loader.java 29 Sep 2005 06:35:47 - 1.3
@@ -19,18 +19,24 @@
import java.io.File;
+import java.io.FileInputStream;
+import java.io.InputStream;
+import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.Hashtable;
+import java.util.Properties;
import java.util.StringTokenizer;
import java.util.Vector;
/**
- * Boostrap loader for Catalina. This application constructs a class loader
+ * Boostrap loader for Catalina or other java apps.
+ *
+ * This application constructs a class loader
* for use in loading the Catalina internal classes (by accumulating all of
the
* JAR files found in the server directory under catalina.home), and
* starts the regular execution of the container. The purpose of this
@@ -38,20 +44,44 @@
* other classes they depend on, such as an XML parser) out of the system
* class path and therefore not visible to application level classes.
*
+ *
+ * Merged with CatalinaProperties:
+ * Load a properties file describing the modules and startup sequence.
+ * This is responsible for configuration of the loader.
+ * TODO: support jmx-style configuration, including persistence.
+ * TODO: better separate legacy config and the new style
+ *
+ * The properties file will be named loader.properties or
+ * catalina.properties ( for backwad compatibility ) and
+ * will be searched in:
+ * - TODO
+ *
+ * Properties used:
+ * - TODO
+ *
+ * loader.* and *.loader properties are used internally by the loader (
+ * *.loader is for backward compat with catalina ).
+ * All other properties in the config file are set as System properties.
+ *
+ * Based on o.a.catalina.bootstrap.CatalinaProperties - utility class to
read
+ * the bootstrap Catalina configuration.
+
+ *
* @author Craig R. McClanahan
* @author Remy Maucherat
* @author Costin Manolache
*/
public final class Loader {
-private static final boolean DEBUG=true;
//LoaderProperties.getProperty(loader.Loader.debug) != null;
+private static final boolean DEBUG=true;
//LoaderProperties.getProperty(loader.debug.Loader) != null;
+// If flat, only one loader is created. If false - one loader per jar/dir
private static final boolean
FLAT=false;//LoaderProperties.getProperty(loader.Loader.flat) != null;
// --
Constants
-protected static final String CATALINA_HOME_TOKEN = ${catalina.home};
-protected static final String CATALINA_BASE_TOKEN = ${catalina.base};
+private static final String CATALINA_HOME_TOKEN = ${catalina.home};
+private static final String CATALINA_BASE_TOKEN = ${catalina.base};
// --- Static
Variables
@@ -75,24 +105,53 @@
protected ClassLoader catalinaLoader = null;
private String[] args;
private Hashtable repositories=new Hashtable();
+private ClassLoader parentClassLoader;
+private static Properties properties = null;
+
+private static String propFile;
// Private
Methods
+
+/** Set the parent class loader - can be used instead of setParent,
+ * in case this is the top loader and needs to delagate to embedding app.
+ * The common loader will delegate
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaProperties.java
costin 2005/09/29 07:36:25
Modified:catalina/src/share/org/apache/catalina/startup
CatalinaProperties.java
Log:
Busted by the tab police, fixed the settings.
Revision ChangesPath
1.10 +4 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
Index: CatalinaProperties.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CatalinaProperties.java 29 Sep 2005 05:52:47 - 1.9
+++ CatalinaProperties.java 29 Sep 2005 14:36:25 - 1.10
@@ -126,12 +126,12 @@
if ((is == null) || (error != null)) {
// Do something
log.warn(Failed to load catalina.properties, error);
- // That's fine - we have reasonable defaults.
- properties=new Properties();
+// That's fine - we have reasonable defaults.
+properties=new Properties();
}
// Register the properties as system properties
- Enumeration enumeration = properties.propertyNames();
+Enumeration enumeration = properties.propertyNames();
while (enumeration.hasMoreElements()) {
String name = (String) enumeration.nextElement();
String value = properties.getProperty(name);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
costin 2005/09/29 08:28:20
Modified:.build.xml
Log:
Added the target to build coyote standalone. ( there are missing files - the
j-t-c/mini directory in particular - don't try to build until
after svn transition, or whenever the rest of the files land )
This is 200K, coyote-http11 only, compared with tomcat runtime which is 1.2M
Revision ChangesPath
1.240 +45 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.239
retrieving revision 1.240
diff -u -r1.239 -r1.240
--- build.xml 29 Sep 2005 06:07:24 - 1.239
+++ build.xml 29 Sep 2005 15:28:20 - 1.240
@@ -1252,6 +1252,51 @@
target name=runtime depends=prepare-runtime-once,compile-runtime/
+!-- === Coyote standalone === --
+!--
+This is only the http connector, for testing/experimental purposes.
+ --
+
+target name=tomcat-http11
+mkdir dir=runtime/http11/
+javac destdir=runtime/http11 debug=false
+src
+pathelement path=${jtc.home}/util/java/
+pathelement path=${jtc.home}/util/loader/
+pathelement path=${jtc.home}/mini/java/
+pathelement path=${jtc.home}/coyote/src/java/
+pathelement path=${jtc.home}/http11/src/java/
+/src
+exclude name=org/apache/coyote/http11/Http11Protocol.java/
+exclude
name=org/apache/coyote/http11/Http11AprProcessor.java/
+exclude name=org/apache/coyote/http11/Http11AprProtocol.java/
+exclude
name=org/apache/coyote/http11/InternalAprInputBuffer.java/
+exclude
name=org/apache/coyote/http11/InternalAprOutputBuffer.java/
+exclude name=org/apache/tomcat/util/net/puretls/**/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15SocketFactory.java/
+exclude
name=org/apache/tomcat/util/net/jsse/JSSE15Factory.java/
+exclude name=org/apache/tomcat/util/net/AprEndpoint.java/
+exclude name=org/apache/tomcat/util/digester/**/
+exclude name=org/apache/tomcat/util/compat/**/
+exclude name=org/apache/tomcat/util/jmx/**/
+exclude name=org/apache/tomcat/util/log/**/
+exclude name=org/apache/tomcat/util/IntrospectionUtils.java/
+exclude name=org/apache/coyote/tomcat3/**/
+exclude name=org/apache/coyote/tomcat4/**/
+exclude name=org/apache/coyote/memory/**/
+/javac
+copy todir=runtime/http11
+fileset dir=${jtc.home}/http11/src/java
includes=**/*.properties **/*.xml/
+fileset dir=${jtc.home}/util/java includes=**/*.properties
**/*.xml/
+/copy
+
+jar jarfile=runtime/tomcat-http11.jar
manifest=resources/coyote-http11.MF
+ basedir=runtime/http11
+ includes=** /
+
+/target
+
+
!-- === TESTER: Run Catalina Tester Tests===
--
target name=dist-tester
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaProperties.java ContextConfig.java Embedded.java
costin 2005/09/28 22:52:49
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
CatalinaProperties.java ContextConfig.java
Embedded.java
Log:
Another small commit dealing with the 'single-jar'/minimal case, where we
don't have all the dir structure or fancy startup script.
It defaults catalina.home to user.dir, reads default server.xml and web.xml
out of resources, set the properties to avoid NPE.
Let me know if there is a problem with this - easy to roll back, but
shouldn't hurt any of the existing functionality.
Revision ChangesPath
1.39 +16 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- Catalina.java 31 Aug 2005 14:06:40 - 1.38
+++ Catalina.java 29 Sep 2005 05:52:47 - 1.39
@@ -463,6 +463,21 @@
}
}
+// This should be included in catalina.jar
+// Alternative: don't bother with xml, just create it manually.
+if( inputStream==null ) {
+try {
+inputStream = getClass().getClassLoader()
+.getResourceAsStream(server-embed.xml);
+inputSource = new InputSource
+(getClass().getClassLoader()
+.getResource(server-embed.xml).toString());
+} catch (Exception e) {
+;
+}
+}
+
+
if ((inputStream == null) (file != null)) {
log.warn(Can't load server.xml from + file.getAbsolutePath());
return;
1.9 +5 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
Index: CatalinaProperties.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CatalinaProperties.java 16 Sep 2004 23:19:54 - 1.8
+++ CatalinaProperties.java 29 Sep 2005 05:52:47 - 1.9
@@ -57,7 +57,7 @@
* Return specified property value.
*/
public static String getProperty(String name) {
-
+
return properties.getProperty(name);
}
@@ -126,10 +126,12 @@
if ((is == null) || (error != null)) {
// Do something
log.warn(Failed to load catalina.properties, error);
+ // That's fine - we have reasonable defaults.
+ properties=new Properties();
}
// Register the properties as system properties
-Enumeration enumeration = properties.propertyNames();
+ Enumeration enumeration = properties.propertyNames();
while (enumeration.hasMoreElements()) {
String name = (String) enumeration.nextElement();
String value = properties.getProperty(name);
1.66 +14 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- ContextConfig.java21 Jul 2005 21:40:56 - 1.65
+++ ContextConfig.java29 Sep 2005 05:52:47 - 1.66
@@ -589,7 +589,19 @@
source = new InputSource
(getClass().getClassLoader()
.getResource(defaultWebXml).toString());
-} else {
+}
+if( stream== null ) {
+// maybe embedded
+stream = getClass().getClassLoader()
+.getResourceAsStream(web-embed.xml);
+if( stream != null ) {
+source = new InputSource
+(getClass().getClassLoader()
+.getResource(web-embed.xml).toString());
+}
+}
+
+if( stream== null ) {
log.info(No default web.xml);
}
} else {
1.29 +6 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java
Index
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util StringManager.java
costin 2005/09/28 22:55:15
Modified:catalina/src/share/org/apache/catalina/core
AprLifecycleListener.java
catalina/src/share/org/apache/catalina/startup
Bootstrap.java WebRuleSet.java
catalina/src/share/org/apache/catalina/util
StringManager.java
Log:
Remove annoying warnings when compiling with JDK1.5 ( without source=1.3 ),
just casts to the normal params to avoid
conflict with the vararg variants.
Revision ChangesPath
1.4 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
Index: AprLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AprLifecycleListener.java 1 Aug 2005 12:13:59 - 1.3
+++ AprLifecycleListener.java 29 Sep 2005 05:55:14 - 1.4
@@ -101,8 +101,8 @@
try {
String methodName = terminate;
Method method =
Class.forName(org.apache.tomcat.jni.Library)
-.getMethod(methodName, null);
-method.invoke(null, null);
+.getMethod(methodName, (Class [])null);
+method.invoke(null, (Object []) null);
} catch (Throwable t) {
if (!log.isDebugEnabled()) {
log.info(sm.getString(aprListener.aprDestroy));
1.24 +7 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Bootstrap.java15 Sep 2005 06:04:01 - 1.23
+++ Bootstrap.java29 Sep 2005 05:55:14 - 1.24
@@ -271,8 +271,8 @@
throws Exception {
if( catalinaDaemon==null ) init();
-Method method = catalinaDaemon.getClass().getMethod(start, null);
-method.invoke(catalinaDaemon, null);
+Method method = catalinaDaemon.getClass().getMethod(start, (Class
[] )null);
+method.invoke(catalinaDaemon, (Object [])null);
}
@@ -283,8 +283,8 @@
public void stop()
throws Exception {
-Method method = catalinaDaemon.getClass().getMethod(stop, null);
-method.invoke(catalinaDaemon, null);
+Method method = catalinaDaemon.getClass().getMethod(stop, (Class
[] ) null);
+method.invoke(catalinaDaemon, (Object [] ) null);
}
@@ -296,8 +296,8 @@
throws Exception {
Method method =
-catalinaDaemon.getClass().getMethod(stopServer, null);
-method.invoke(catalinaDaemon, null);
+catalinaDaemon.getClass().getMethod(stopServer, (Class [])
null);
+method.invoke(catalinaDaemon, (Object []) null);
}
1.15 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java
Index: WebRuleSet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- WebRuleSet.java 26 Jul 2004 16:04:01 - 1.14
+++ WebRuleSet.java 29 Sep 2005 05:55:14 - 1.15
@@ -576,7 +576,7 @@
return;
}
-m.invoke(top, paramValues);
+m.invoke(top, (Object [])paramValues);
if (digester.getLogger().isDebugEnabled())
digester.getLogger().debug( + top.getClass().getName() + .
+ method + ( + paramValues[0] +
));
1.8 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java
Index: StringManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StringManager.java16 Sep 2004 23:19:54 - 1.7
+++ StringManager.java29 Sep 2005 05:55:15 - 1.8
@@ -101,7 +101,7 @@
* @param key The resource name
*/
public String getString(String key) {
-return MessageFormat.format(getStringInternal(key), null);
+return MessageFormat.format(getStringInternal(key
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java
I have few weeks, I'm trying to sync up some of the few changes I made
in the last year before the code is moved to svn and try a bit more
the 'embedded' scenario ( both single-jar tomcat - that actually works
well, and also coyote-only ).
I uploaded 2 jars at http://people.apache.org/~costin/mini - one has
full jasper, the other only the jsp runtime. There are still few
requirements on the dir structure - you need to have the conf/web.xml,
work/, webapps/, but besides that it's just 'java -jar
tomcat+jasper.jar', no extra jars required.
tomcat-http11.jar is just coyote, with a javascript adapter as example (
let me know if you want to play with it, I'll send additional info ).
Costin
Henri Gomez wrote:
Happy to see Costin is back :)
15 Sep 2005 06:04:01 -, [EMAIL PROTECTED] [EMAIL PROTECTED]:
costin 2005/09/14 23:04:01
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Support for corner case, when all tomcat is in a single jar and no fancy
classloaders are used.
Revision ChangesPath
1.23 +9 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/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.java3 May 2005 14:12:52 - 1.22
+++ Bootstrap.java15 Sep 2005 06:04:01 - 1.23
@@ -95,6 +95,10 @@
private void initClassLoaders() {
try {
commonLoader = createClassLoader(common, null);
+if( commonLoader == null ) {
+// no config file, default to this loader - we might be in a
'single' env.
+commonLoader=this.getClass().getClassLoader();
+}
catalinaLoader = createClassLoader(server, commonLoader);
sharedLoader = createClassLoader(shared, commonLoader);
} catch (Throwable t) {
@@ -122,10 +126,10 @@
// Local repository
boolean packed = false;
if (repository.startsWith(CATALINA_HOME_TOKEN)) {
-repository = getCatalinaHome()
+repository = getCatalinaHome()
+ repository.substring(CATALINA_HOME_TOKEN.length());
} else if (repository.startsWith(CATALINA_BASE_TOKEN)) {
-repository = getCatalinaBase()
+repository = getCatalinaBase()
+ repository.substring(CATALINA_BASE_TOKEN.length());
}
@@ -159,14 +163,14 @@
// Retrieving MBean server
MBeanServer mBeanServer = null;
if (MBeanServerFactory.findMBeanServer(null).size() 0) {
-mBeanServer =
+mBeanServer =
(MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
} else {
mBeanServer = MBeanServerFactory.createMBeanServer();
}
// Register the server classloader
-ObjectName objectName =
+ObjectName objectName =
new ObjectName(Catalina:type=ServerClassLoader,name= + name);
mBeanServer.registerMBean(classLoader, objectName);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
William A. Rowe, Jr. wrote: Costin Manolache wrote: Remy Maucherat wrote: I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Well, my first point was that, as a TLP, the lists should become @tomcat.apache.org; whatever they become. But AFA different lists are concerned, is it worth a vote? I'm going to abstain, as I'm not on the PMC (IIRC). But here it is, go ahead and cast an opinion... Bugs [ ] forward to [EMAIL PROTECTED] [X] forward to [EMAIL PROTECTED] Commits [ ] forward to [EMAIL PROTECTED] [X] forward to [EMAIL PROTECTED] Vote away :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java
costin 2005/09/14 23:04:01
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Support for corner case, when all tomcat is in a single jar and no fancy
classloaders are used.
Revision ChangesPath
1.23 +9 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/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.java3 May 2005 14:12:52 - 1.22
+++ Bootstrap.java15 Sep 2005 06:04:01 - 1.23
@@ -95,6 +95,10 @@
private void initClassLoaders() {
try {
commonLoader = createClassLoader(common, null);
+if( commonLoader == null ) {
+// no config file, default to this loader - we might be in a
'single' env.
+commonLoader=this.getClass().getClassLoader();
+}
catalinaLoader = createClassLoader(server, commonLoader);
sharedLoader = createClassLoader(shared, commonLoader);
} catch (Throwable t) {
@@ -122,10 +126,10 @@
// Local repository
boolean packed = false;
if (repository.startsWith(CATALINA_HOME_TOKEN)) {
-repository = getCatalinaHome()
+repository = getCatalinaHome()
+ repository.substring(CATALINA_HOME_TOKEN.length());
} else if (repository.startsWith(CATALINA_BASE_TOKEN)) {
-repository = getCatalinaBase()
+repository = getCatalinaBase()
+ repository.substring(CATALINA_BASE_TOKEN.length());
}
@@ -159,14 +163,14 @@
// Retrieving MBean server
MBeanServer mBeanServer = null;
if (MBeanServerFactory.findMBeanServer(null).size() 0) {
-mBeanServer =
+mBeanServer =
(MBeanServer)
MBeanServerFactory.findMBeanServer(null).get(0);
} else {
mBeanServer = MBeanServerFactory.createMBeanServer();
}
// Register the server classloader
-ObjectName objectName =
+ObjectName objectName =
new ObjectName(Catalina:type=ServerClassLoader,name= + name);
mBeanServer.registerMBean(classLoader, objectName);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mark Thomas wrote: Mladen Turk wrote: Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strongly Tomcat 5.5.x will be committed to JDK 1.4.x in future..
The current servlet spec doesn't requires J2SE 5.0 - only the next one ( another stupid forced, unjustified transition IMO ). I would assume JDK1.4 will be supported for a while, as long as the current version of the servlet spec is in use. Tomcat3.3, which supports JDK1.1, has been maintained for quite a while after switching to JDK1.3 and then JDK1.4. I don't see how anyone who has been around for past upgrades could expect a mass migration to the new servlet spec and JDK1.5. Costin Yoav Shapira wrote: Hi, Tomcat 5.5 will always allow JDK 1.4. Tomcat 6.0, as required by the J2EE 5 specifications, will require J2SE 5.0. I repeat, for emphasis, that this is required by the J2EE 5 Specification itself, which Tomcat 6.0 will support: it is not our decision to drop support for JDK 1.4. Yoav --- Girish Vasvani [EMAIL PROTECTED] wrote: Hi, We'r puzzled between tomcat 5.0.x and 5.5.x. Due to our product restrictions we can't use JDK 1.5. Looked at jakarta web site, it seems that using tomcat 5.5.x seriese compated to 5.0.x is a good idea and recommended. Before committing our product to tomcat 5.5.9, I want to know how much tomcat dev team will be committed to supporting JDK 1.4.x going forward ? thanks in advance for your help, Girish - Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11BaseProtocol.java Http11Protocol.java
costin 2005/09/11 09:25:20
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Added: http11/src/java/org/apache/coyote/http11
Http11BaseProtocol.java
Log:
Small refactoring removing the compile time dependency between http connector
and jmx.jar.
It also removes the need to have jmx apis in classpath when running the
connector, in servers not using jmx.
Http11BaseProtocol is a copy of the old Http11Protocol, with jmx-related code
removed.
Http11Protocol has the remaining jmx code.
AprHttp11Protocol can't currently use the base class because all it's classes
( AprEndpoint, Handler, etc )
are incompatible.
Revision ChangesPath
1.65 +12 -656
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- Http11Protocol.java 22 May 2005 17:12:11 - 1.64
+++ Http11Protocol.java 11 Sep 2005 16:25:20 - 1.65
@@ -56,98 +56,12 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
}
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.setattribute, name,
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.getattribute, key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString(http11protocol.socketfactory.initerror),
- ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.initerror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.init, getName()));
-
-}
ObjectName tpOname;
ObjectName rgOname;
@@ -178,460 +92,18 @@
( cHandler.global, rgOname, null );
}
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.starterror),
ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.start, getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString
Re: Small refactoring in Http11Processor
Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Thursday, September 08, 2005 10:56 PM Subject: Small refactoring in Http11Processor Hi, I have a small patch, spliting the JMX-dependent code in Http11Processor, i.e. the few lines of code dealing with the registration of the thread pool and per thread data - and moving all non-jmx code in a separate base class. I know Tomcat5 is heavily dependent on JMX, but the connector can be used in other containers, or it can be used standalone. This small change won't affect any functionality on tomcat - all methods are used only for intialization anyway, not in the critical path. Please review and let me know if it's ok to commit the change. It seems that the only thing this patch does is to allow you to exclude jmx.jar, so it's usefulness seems very minimal :). TC 3.3 4.1 already run very happily with the current code without JMX enabled. True, it allows a smaller package. TC3.3 and 4.1 don't register the connector, so no JMX-related code is called, but it still requires jmx.jar to be around. Something better would be a refactor that would remove the duplicated code between Http11Processor and Http11AprProcessor (which one doesn't do :). Yes, I've been thinking about this too :-), and also InternalAprBuffer and maybe add conditional compilation for the apr. But I didn't want to make the diff too big and risky. Of course, none of this is enough for me to veto your scratching an itch :). Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) I agree with Mladen that this would work better if you could wait a couple of weeks until we are up on SVN. Ok, sounds good, I need to clean up the code anyway ( well, there are 2-3 classes only and some build.xml ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
Remy Maucherat wrote: So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Of course, but also fewer people will care about bug reports. I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Small refactoring in Http11Processor
Hi,
I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e. the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.
I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.
Please review and let me know if it's ok to commit the change.
Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)
Costin
? src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Index: src/java/org/apache/coyote/http11/Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
diff -b -u -w -r1.64 Http11Protocol.java
--- src/java/org/apache/coyote/http11/Http11Protocol.java 22 May 2005
17:12:11 - 1.64
+++ src/java/org/apache/coyote/http11/Http11Protocol.java 9 Sep 2005
05:31:50 -
@@ -56,98 +56,12 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
}
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.setattribute, name,
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.getattribute, key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString(http11protocol.socketfactory.initerror),
- ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.initerror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.init, getName()));
-
-}
ObjectName tpOname;
ObjectName rgOname;
@@ -178,460 +92,18 @@
( cHandler.global, rgOname, null );
}
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.starterror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.start, getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.pauseerror), ex);
-throw ex
Re: commons-logging infinite loop w/5.5.9
Nathan Bubna wrote: On 8/23/05, Remy Maucherat [EMAIL PROTECTED] wrote: Nathan Bubna wrote: hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example applications to use an adapter between commons-logging and Velocity's LogSystem. this way, those of our tools which require logging are able to send messages to commons-logging and they get passed of to the LogSystem that the rest of Velocity is using (without having to pass that LogSystem around). We also, by default, configure our VelocityViewServlet (the core class of VelocityTools) to automatically send LogSystem messages to the servlet log. so, messages sent to c-l are sent the the Velocity LogSystem which sends the messages to the servlet log. this works just dandy for everyone in Tomcat 5.0.x, but when we deploy our very minimal example applications in Tomcat 5.5.9, we promptly receive stack overflows and out of memory errors that appear to be a nasty little commons-logging loop. can somebody help me figure out what change between 5.0 and 5.5 is causing this? and further, what can be done about it? i'm still not even sure whether to consider this a bug in our design or in Tomcat. any help would be much appreciated! In Tomcat 5.5, everything is logged to commons-logging, so the loop you get is to be expected. so, i guess that means web applications/frameworks that wish to work with Tomcat 5.5 must either not redirect commons-logging messages to their own logging solution or else they must not use servletContext.log(...) as a target for their logging solution, correct? Seems so - since servletContext.log() call commons-logging, not a good idea to use an impl. of commons-logging that eventually calls servletContext.log(). Maybe a better solution would be to have the Velocity LogSystem send messages to commons-logging, then everything will go to c-l and the chosen impl. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inprocess Tomcat/apache via mod_jk
With worker - it may work. However you may find mod_jk inprocess to be slower than ajp and mod_proxy ( or comparable in speed ), this is due to the way parameters are passed as strings ( i.e. lots of unoptimized char-byte conversion ). Porting to 5.5.x shouldn't be hard - the interface between tomcat and modjk is very simple: you need to startup, i.e. make sure classpath is set and the class that executes launches tomcat correctly, and then it's a simple class that does the request/response passing. If you do this for performance reasons - you may want to look at the code in jk2, and try to backport it. A benefit would be that the interface is even simpler - the req/response are passed in the same kind of buffer as ajp requests. AFAIK that's the only major difference. Since Remy, Mladen, etc have greatly optimized the regular tcp connectors - probably the difference on performance ( with this optimization backported ) will be small. But if you use the old style of interface - I'm sure jni will be slower (it was slower 2 years ago). Costin Christine Ho wrote: Hi, Thanks a lot. I am really appreciated for your reply. How about the worker MPM? My team is running the httpd.worker on RHEL4. The current setting is: StartServers 1 ServerLimit 1 MaxClients 64 MinSpareThreads 32 MaxSpareThreads 64 ThreadsPerChild 64 Does the inprocess Tomcat 5.5.9 work for the worker MPM? thanks, Christine --- Bill Barker [EMAIL PROTECTED] wrote: Well, inprocess doesn't really work for any MPM on *nix systems (e.g. with the prefork MPM, you end up with MaxChild copies of Tomcat running :). As a result, there just hasn't been that much interest in implementing (or even back-porting) a feature that only works on Windows and NetWare. - Original Message - From: Christine Ho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 3:30 PM Subject: inprocess Tomcat/apache via mod_jk Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: svn commit: r232601 - /tomcat/watchdog/branches/tc4.1.x/WARNING.txt
Did tomcat move to svn already ? Costin [EMAIL PROTECTED] wrote: Author: markt Date: Sun Aug 14 04:48:32 2005 New Revision: 232601 URL: http://svn.apache.org/viewcvs?rev=232601view=rev Log: Remove CVS closure warning from SVN Removed: tomcat/watchdog/branches/tc4.1.x/WARNING.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP using APR
Bill Barker wrote: Costin Manolache [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: If I understand you correctly, you want MsgAjp to use ByteBuffer instead of byte []. At the cost of never supporting JDK 1.3 ever again, this would probably actually improve the performance of ChannelSocket (after changing it to use a blocking SocketChannel). The biggest difference will be if it's a 'direct' buffer, i.e. zero copy. Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should be ok, if anyone needs jdk1.3, they can use the old code. Yes, the idea was that it would be a direct buffer. But where is the code ? It's on my hard-drive. Unlike Remy's APR stuff, o.a.jk is supposed to be a pretty stable package(s) at this point. I can't just check in stuff like this without a lot of testing to make sure that it doesn't break anything more than JDK 1.3 compatibility ;-). That's why C has conditional compilation - and java has some options-controlled ugly 'if' code :-) It doesn't break anything if the option/def is not selected ( just makes the code a bit uglier ). This way even JDK1.3 will be happy. The biggest problem in JNI ( and probably - in Java playing nice with other languages and the rest of the platform ) is the objects and buffers moving around almost randomly. Yes, it may improve a bit the garbage collection speed - so people can create millions of garbage objects without thinking about it, unlike most other languages that require you to think when allocating objects - but it is the kind of optimization that has disastrous consequences on the rest of the systems. Luckily gcj and kaffe and mono don't do this crazy thing. Direct buffers is one band-aid that should be used whenever possible. Costin Costin Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP using APR
Bill Barker wrote: If I understand you correctly, you want MsgAjp to use ByteBuffer instead of byte []. At the cost of never supporting JDK 1.3 ever again, this would probably actually improve the performance of ChannelSocket (after changing it to use a blocking SocketChannel). The biggest difference will be if it's a 'direct' buffer, i.e. zero copy. Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should be ok, if anyone needs jdk1.3, they can use the old code. But where is the code ? Costin Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Scott Marlow wrote: Hi, I wonder if anyone has any feedback on a performance change that I am working on making. Can you compare the performance of you code with the standard implementation when the concurrency is lower then maxThreads value? I see no point to make patches that will deal with cases presuming that the concurrency is always higher then the actual number of worker threads available. IMHO this is a bad design approach for the http applications, and NIO performance is a proof of that. It might help in cases where you have a very very slow clients. In any other case the thread context switching will kill the performance thought. Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads. Why ? 100 keep alive connections doesn't mean 100 active requests, in real servers there are many 'keep alive' connections that are just waiting for the next request. In all servers I know, concurrency was higher than the configured number of workers - at peak time, at least, where performance matters. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Remy Maucherat wrote: I looked at this yesterday, and while it is a cool hack, it is not that useful anymore (and we're also not going to use the concurrent utilities in Tomcat, so it's not really an option before we require Java 5). The main issue is that due to the fact keepalive is done in blocking mode, actual concurrency in the servlet container is unpredictable (the amount of processing threads - maxThreads - will usually be a lot higher than the actual expected concurrency - let's say 100 per CPU). If that issue is solved (we're trying to see if APR is a good solution for it), then the problem goes away. I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. That's how it allways worked - but it's not necesarily the best solution. The only thing that is required is to have a thread per active request - the sleepy keep alives don't need thread ( that could be implemented using select in the apr, or nio in java ) Your patch is basically a much nicer implementation of maxThreads (assuming it doesn't reduce performance) which would be useful for the regular HTTP connector, so it's cool, but not worth it. Overall, I think the way maxThreads is done in the APR connector is the easiest (if the amount of workers is too high, wait a bit without accepting anything). That's a tricky issue :-) In some cases ( like load balancing ) not accepting is the right solution, but in other cases droping connections is not what people want ( in particular if most of the threads are just waiting on keep alives ). ( sorry if I missed some details in the new implementation :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Costin Manolache wrote: I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. No it doesn't. If the connection is keep-alive, and there is no activity for 100ms, the socket is put in the poller, and that thread is freed. When the next data on that socket arrives, the socket is signaled and passed to the thread pool. Mladen. Sorry, I missed that. So we can have as many 'keep alive' idle as we want - only those active are taking threads ? Which file implements this ( the 100ms timeout and poller ) ? I assume this is only done in the APR connector, or is it implemented in java as well ( nio ) ? . Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
Remy Maucherat wrote: Keith Wannamaker wrote: If no one else is concerned that Tomcat 5.5 doesn't work by default Any other nonsensical statement to make ? The only thing that does not work is opening third party documents from the website, due to IE's broken handling of this. How about a) going whining at M$ instead ? b) using appropriate configuration. Your veto is completely invalid anyway. IE is still (unfortunately) the browser used by a lot of people, and if there is a way to work around IE brokeness - I think it's a good idea to do it. Complaining to M$ doesn't work - people will just end up buying IIS instead :-) Seriously, not sure why is the veto invalid - if the choice is between having it working for 90% of the people and doing it 'right' - it is worth probably more discussion and a pragmatic decision :-) I would vote for fixing it for the 90% of people - at least until IE gets down to some 49%. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Remy Maucherat wrote: Need to identify just how much of the jakarta-* CVS will go with Tomcat. Watchdog + ServletAPI modules? That's undecided. Would the old projects would remain at Jakarta, or would they be covered by the new project ? Why would they remain in jakarta ? They have the same committer list as tomcat, and are closely related. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Tim Funk wrote: Looks good. Just an idea, it may be nice to have the 3 new lists tomcat-bug - bug updates from bugzilla. When I subscribe to other groups tomcat-cvs - Same as tomcat-bug but just for cvs commits. tomcat-gump - For deaths by gump. If your not a committer - these are This has been debated many times :-), maybe this time it'll succeed. The typical argument for keeping it all in one place is that it may force people to read them instead of filtering the out with the mail app. It would be nice to split it - it'll be much easier to read tomcat-dev ( including in blogs.gmane.org ). Regarding CVS move - are we going to just change the name of the roots ( s/jakarta/apache/ ) or should we do a bit more reorg, to make it easier when we move to svn ? The current layout is based on a lot of 'historic' reasons that no longer apply. For 3.x and 4.x - of course it makes sense to just keep the trees as they are. Costin -Tim Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? Congratulations to Remy. Also thank you Yoav for moving the formalities along. Congratulation Remy ! I think a lot of people agree that anyone who is an active committer should be in the PMC ( that's what jakarta has been doing for a long time ). It's 'should' - not 'must' - that means you are not required to do this if you really don't want to. I think Remy has already sent additional lists of people who are active but have not voted. I assume those who really don't want will have to send email to Remy to be taken out of the list before it goes to the board. Regarding 'emeritus status' - I think usually people who have not participated in the last 6 months ( or 1 year ) can be moved to 'emeritus' - unless they ask to remain in the list of active committers. ( for example because they plan to return to active soon, etc :-). We could send a mail to everyone in the avail list, and if we don't get an answer or we get an 'I don't care' - we should do the switch. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Remy Maucherat wrote: Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. +1 To get things started, since I'm probably close to the 6 month inactivity limit ( in either direction :), I would like to ask to stay in the active list :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Mladen Turk wrote: Henri Gomez wrote: I could provide Linux binaries for Suse 8.0 PPC and Suse SLES 9 but it's up to distributions mainteners to provide such binaries (via rpm/deb). Take a look at jpackage for many Linux RPM binaries Yes, that is my opinion too. We should focus on providing a solid: 'configure make make install', rather then providing a binaries for ourself. I think that we are good and mature project that any serious linux distribution (at least targeted for enterprise environment) should take into account, and provide a binaries on their own. We can provide binaries for platforms that does not come with integrated build system like WIN32, and we are doing so. Although, personally I would be pleased to see the isapi_redirector.dll as part of the next XP service pack, it's hard too expect something like that :) I kind of disagree... If I want Firefox for linux - I get it from Mozilla.org. It may be a .tar.gz or .rpm - but it is a binary provided by the software maintainers, not by a 3rd party ( like a linux distributor ). And it is the 'real' thing, not a randomly modified version ( different flags and features, etc ). Linux is such a mess in large part because people who write software treat it as second-class - 'let someone else deal with compiling binaries for linux, I'll only do it for windows and mac'. As a result linux distributions have the freedom to mess up and 'personalize' each package to their own taste ( we all know how painful it is to switch from one distro to another or use/support 2 distros - each file is in a different place - this is called lock in ). On windows - you can get nice binaries, with installer and everything else you would expect - distributed by the package authors. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] PMC Chair
Jim Jagielski wrote: I would recommend that before anyone responds, we decide who should rec' and tally the votes. Also, votes should only be counted from those who will be on the new PMC. So before the vote: 1. Finalize list of PMC members (all current committers) 2. Determine who to collect and tally votes (I propose Henri Yandell) Let's not make this too long or complicated. Some votes are already out of the box, and I think we agree that any committer who wants to be in the PMC can get there by simply asking for it. So if Henri can send back a count ( or just the winner ) of all private votes he receives, as well as the list of people who voted - we can check against avail and update the PMC member list as well. ( a vote by a committer is an indication that he wants to vote so he wants to be in the pmc :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] PMC Chair
Yoav Shapira wrote: The initial Tomcat PMC chair should be: [ +1 ] Remy Maucherat [ ] Yoav Shapira Next year I'll switch, Yoav is great - I just think Remy deserves to be the first chair... Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Remy Maucherat wrote: Costin Manolache wrote: Yoav Shapira wrote: If Remy is interested, I think it would be fair to have a vote. If whoever is first later decide he had too much politics/admin pains - we'll have a backup ready :-) At this point, I think I cannot avoid being a candidate. Yoav may be the best chair, however, so there's an opportunity for a real election. Good. Let's get this over then. I never liked one candidate elections or elections with 99% results ( remind me of an evil system :-) Yoav would be an excelent chair - however Remy has my vote this time. I'm at the moment in favor of allowing non consecutive one year terms. Of course :-) Costin Unfortunately, it means two people can share the job, which would defeat the purpose, but without this, we could run out of worthy/willing candidates pretty fast. I don't know what are the rules wrt board meetings ( if only the pmc is allowed, etc ), but while there is only one pmc chair, we can have as many volunteers as we want to help with the admin stuff - reports, etc( if I remember, Henri was doing this long before he became chair of jakarta pmc, same for Geir ). Right. So it's great to have as many people as possible volunteer for the unpleasand admin work - it will only make the admin job easier, and it'll make the rotation transition easier too. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Remy Maucherat remm at apache.org writes: Peter Lin wrote: my non scientific tests with jdk1.5 using JMeter tells me it's a bit faster than jdk1.4, but I doubt it is faster than SWT. If I had more free time, I would definitely be interested in a SWT admin application. oh well, that's life :) As you may have noticed, I do like some of the Eclipse stuff (and I use Eclipse-the-IDE itself). Regardless of its performance (which is actually bad on non Windows systems, from what I understand), I would however have to veto usage of SWT, given the better overall performance one gets with Swing. Obviously, you can try to demonstrate that this is not the case, and SWT is superior on all platforms, but somehow I doubt it. The only remaining benefit I see is portability to non Sun JVMs, as the free implementation of Swing isn't complete yet (this seems to be progressing very quickly at the moment, however). I think you are wrong on this one. At least on Linux ( and low-end hardware ) SWT seems to be faster, even with the crapy GTK bindings ( that could be optimized a lot ). I guess what's more important in SWT is the design based on using the platform UI instead of drawing pixels and attempting to make it look like the real platform widgets. There is also the issue of complexity - SWT is a very clean and simple API. I spent a lot of time with SWT - if I would write an UI app, it'll be my choice. However, I think it would be more interesting to do the the admin app in XUL. Seriously ! It'll mean it requires mozilla/firefox/etc - but I think it would be easier to maintain and develop it, and much more interesting. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Henri Yandell flamefew at gmail.com writes: However, SVN has sufficient advantages on the server-side for the people administrating the Apache boxes to long for it, and the choice of techs is a balance between various people's requirements. I've nudged Infra to see if they're planning to propose the CVS-tuning-off proposal to the community soon, as the earlier the better. Propose or impose ? Typically 'propose' means the community would have some way to say 'yes' or 'no'. I agree SVN is better - and for a new project it would certainly be the top choice. But I can't believe maintaining cvs for existing projects ( or the few projects that chose to keep using it ) is such a huge burden. If this is an issue of resources - will this be solved if someone would volunteer to maintain it ? Or maybe if some company would donate the money for a hosting service ( like openoffice.org or java.net seem to work ) ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Jim Jagielski wrote: The PMC Chair has ultimate authority, since the position is board appointed and results in the Chair being a VP of the ASF. There's no precedent for sharing the role or having a co-Chair. The PMC Chair is the point man for the PMC. Yes, we know - that's one of the reasons some people want this to be a 'rotating' position. Sharing the role ( i.e. the tasks ) has a lot of precedents. I have no problem with someone having this kind of authority - in projects like Linux or Python, where the guy in charge created the project in the first place. I am not confortable at all with having the 'ultimate' authority appointed - even when (in most cases) it is at the recomandation of the community. IMO it is the worse of both worlds. The PMC Chair is nominated by the PMC, and the recommendation is sent in with the PMC resolution. The board then debates the issue and will usually approve the resolution and appoint the nominated person as chair. Since the PMC Chair is the main guy for the PMC, it is even more an issue for that person to be very much an ASF weenie and understand and embrace the Apache Way... It can be a political and managerial kind of position and any candidate should realize that sad fact :/ Well, Remy and Yoav are members of ASF - so they clearly passed the 'Apache Way' test. If this is a requirement - than the pool of candidates is going to be quite small ( Remy, Yoav, you, Bill - and Craig or Justina if they choose to get back ) For 'managerial' and 'political' - I think both did both ( maybe without enjoying it, but still...) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX] be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further +1 I would like to propose Remy == XX ( he can obviously refuse, but I hope he will not do that ). Obvious reasons on why he is the best choice, so I don't think consensus will be a problem - only his acceptance ( it'll not involve too much coding :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Jim Jagielski wrote: Yoav Shapira wrote: Hi, I could... But there's the question of whether we want all committers on the PMC or just the active ones. The avail file has, in addition to the people I already listed: duncan,jon,rubys,akv,jhunter,preston,shemnon,shachor,bergsten,gonzo,mode,har ishp,arun,craigmcc,jluc,nacho,aried\ el,horwat,ed,alex,gaburici,jiricka,pierred,glenn,larryi,arieh,marcsaeg,danmi l,shai,keith,kief,melaquias,m\ braden,clucas,bip,seguin,mmanders,andya,ccain,bojan,patrickl,jazmin,ekr,manv een,cks,denisb,dsandbe\ rg,bobh,idarwin,johnturner,ecarmich,fuankg,clar,jim,wrowe John Turner, Jim J., Bill Rowe are obviously active, I'll add them right now. But many of the above are not active, emeritus committers... Personally, I would agree if people did not think I deserved PMC member status. I would be honored to accept, but would 100% understand if there were, well... thoughts that it was unwarranted :) I hope that Tomcat PMC will be one where each active committer who is willing will be a member, I don't want it to be an arbitrary and random process like it was in jakarta ( or asf membership ). If you are working on tomcat, I can't see why not be in PMC ( unless you really don't want to ) I don't know if I deserve it tough - since I haven't been very active last year - but since my project is now over, I hope to get back on tomcat and become active :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Hi, I would like to propose Remy == XX ( he can obviously refuse, but I hope he will not do that ). Obvious reasons on why he is the best choice, so I don't think consensus will be a problem - only his acceptance ( it'll not involve too much coding :-). I was thinking Remy might refuse, so he doesn't have to deal with all the administrative stuff that comes with the role. That and my own interest in the role prevent consensus at this point ;) It Remy will refuse - you have my vote :-) It's just that he done so much coding in this project - that I think it would be good if he is the first chair. I think the idea of rotating ( let's say yearly ? ) would be an excelent one - it'll avoid having people serve for too much ( and sometimes avoid bad habbits - like forgeting to ask the community before making important decisions :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Howdy, I think the idea of rotating ( let's say yearly ? ) would be an excelent one - it'll avoid having people serve for too much ( and sometimes avoid bad habbits - like forgeting to ask the community before making important decisions :-) That's a decent plan. What do the other projects do about that ? Logging Services, which formed just recently, has a yearly PMC chair term, but the incumbent can repeat the role if the PMC so votes. Sounds ok - I would preffer a real rotation. What about 'can repeat the role if he wants and there is no other candidate' ? ( if he doesn't want - of course, someone else needs to be 'volunteered' ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Hola, What do you guys (parties in the subject) have to say about that? Lat's put all the cards on the table, do what ever is needed and move forward. I'm getting tired of all that politic bullshit, but I'm also aware it must be done. So ... Remy, Yoav? I'm waiting to hear from Remy on what he wants to do. He has to want to be the PMC chair ;) If he does want it and all the admin stuff that goes with it, it's fine with me. The role of a VP is something we can define, but doesn't really exist within other ASF projects, which just have the PMC chair and the rest of the PMC, so I don't think we need one. If Remy is interested, I think it would be fair to have a vote. If whoever is first later decide he had too much politics/admin pains - we'll have a backup ready :-) I don't know what are the rules wrt board meetings ( if only the pmc is allowed, etc ), but while there is only one pmc chair, we can have as many volunteers as we want to help with the admin stuff - reports, etc( if I remember, Henri was doing this long before he became chair of jakarta pmc, same for Geir ). So it's great to have as many people as possible volunteer for the unpleasand admin work - it will only make the admin job easier, and it'll make the rotation transition easier too. Costin I'm also fine with the annual rotation as suggested by Costin. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the Tomcat5 WIN32 service runner
Mladen Turk wrote: @if %1 == install goto cmdInstall @if %1 == uninstall goto cmdUninstall @if %1 == start goto cmdStart @if %1 == stop goto cmdStop @if %1 == restart goto cmdRestart echo Usage goto cmdEnd I assume the '.bat' is the only option - i.e. could you use arbitrary 'executables' or other 'scripting languages' ? I.e. if you have cygwin or equivalent installed - could it execute a .sh ? Or if you have different scripting engine - could it run the .js or .py instead of .bat? And the most interesting - could you specify an executable .jar as the command ? It's just that .bat is one of the ugliest scripting languages... Having the unix-style service mechanism, i.e. a script with start/stop/etc is IMO a step forward and makes it much easier to deal with services. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
Both +1, of course. I guess you meant 'commiters for jakarta tomcat project' :-) Costin Mladen Turk wrote: I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and William A. Rowe ([EMAIL PROTECTED]) as commiters for the JTC connectors. Both of them are long time ASF members. Jim is even a director of Apache Software Foundation. They both are core apache httpd designers and developers for years now, and IMHO we should be proud tho have them on board :). I'm sure they will help us with the better apache httpd integration. So... [x] Yes, Jim is really a cool guy. [ ] No way. and.. [x] Sure, wellcome Bill. [ ] I think I know httpd better then him. The both have my ++1. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the Tomcat5 WIN32 service runner
William A. Rowe, Jr. wrote: At 06:31 AM 2/21/2005, Mladen Turk wrote: Unlike any other java or java/jni implementations it does not tries to make a java as a service, but rather makes a batch (.bat) file as a service. IIUC, that means; 1. service signals (shutdown etc) aren't recognized by cmd (sh for you linux observers) in any useful manner. 2. it invokes cmd, which invokes the apps. You are stuck with an instance of cmd for the lifetime of the process. Seems like a big leap backwards, IMHO. If anything, a psuedo-sh script interpreter which picked up the envvar assignments (the only thing you want to move to .cmd for, anyways) makes more sense than this. Would it be possible to have the signals intercepted and cause the execution of the .bat file with different params ( like 'stop' or 'reload' or 'start' ), similar with unix init.d files ? I like the idea of running a .bat ( or arbitrary .exe ) as a service based on the analogy with the init.d files - but it needs the stop/restart as well. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Well, numbers are statistics do speak for themself - but may tell different things. Apache may have most projects in SVN, but the world has most projects in cvs. And most tools (finally) have some good, first class built-in support for CVS, most people are (finally) familiar enough with using cvs. There are some plugins for svn ( and other version control tools ) - but not at the same level. I like SVN a lot - and for a new project probably I would choose it if there is a choice - sf.net or other places are cvs only. But I don't think all the pain for switching tomcat is justified, and switching few repositories but not others is even worse. Unless we're going to do major reorganization of the code ( move directories around ) or we start some complex branches, or we have any other need where SVN is much better than CVS - I would say it's better for everyone to stick with the stable environment. Costin Henri Yandell wrote: I've not heard anything about it being mandatory yet, but the numbers speak for themselves. The www.apache.org site has 24 coding projects. There are 22 projects listed on the svn.apache.org/viewcvs.cgi page. 2 of those are dead, so 20 out of 24 ASF projects have an svn presence of some kind. The people still left with readable CVS modules are: mod_perl ant 2/3rds of jakarta possibly gump (though they have an svn module too) apache conference most of xml logging half of web services So I assume at some point there'll be pressure to turn off the CVS server. On the command line, svn is pretty much the same as cvs. Some bits are faster, some slower. There are various improved features (http://subversion.tigris.org/ lists them) that people have been asking for for ages with CVS. Habit-wise, the only differences I've hit are: 1) you checkout from a url, not from a cvs-root and a path. 2) tagging/branching is done by copying a directory revision (really creating a symlink-style thing in the database) and isn't applied to every file individually. Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for standard development (checkout, update, diff, commit). I'm unsure whether you can create tags/branches using it as I always do that on the command line, be it cvs or svn. IntelliJ has a plugin and the next version will have it built in. TortoiseSvn is spoken well of, and I can vouch for svn on linux/OS X, I've had no problems in the last year of use. Docs are docs :) Yep, they'll need updating. Build scripts. Do you have scripts that check modules out of cvs? If so I imagine the ant support for svn might be a big deal. Unsure what it's like. Hen On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
I assume this is going to be a compile/configure time option ? What about using a different approach - generate multiple .so files, one with common/base/non-optional functionality, and one for each optional library. Compile time options makes it hard to distribute compiled binaries and add more requirements. Costin [EMAIL PROTECTED] wrote: mturk 2005/02/02 23:47:49 Added: jni/native/src ssl.c Log: Add OpenSSL support. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jni/native/src/ssl.c Index: ssl.c === /* Copyright 2000-2004 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #include apr.h #include apr_pools.h #include apr_file_io.h #include tcn.h #ifdef HAVE_OPENSSL /* OpenSSL headers */ #include openssl/ssl.h #include openssl/err.h #include openssl/x509.h #include openssl/pem.h #include openssl/crypto.h #include openssl/evp.h #include openssl/rand.h #include openssl/x509v3.h /* Avoid tripping over an engine build installed globally and detected * when the user points at an explicit non-engine flavor of OpenSSL */ #if defined(HAVE_OPENSSL_ENGINE_H) defined(HAVE_ENGINE_INIT) #include openssl/engine.h #endif #else #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The FIX - Shutdown not working under SLES8 and FC2
What about: - add this information to the bug report - send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not very used, but probably google will find this if anyone has a similar problem ). Or post it in your weblog/site/etc for google to find. It should be obvious changing the default configuration only to deal with this case won't happen. If a computer can't locate itself by name - you'll have a lot of other problems. Costin ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump
Re: The FIX - Shutdown not working under SLES8 and FC2
Al Sutton wrote: Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh
Re: SVN migration?
Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
[EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Well, if you can debug this and find the real cause and a fix - I'm sure someone will look at it. But please understand that Remy and the other tomcat developers deal with a lot of bugs, and usually it's frustrating to deal with bugs that happen only on certain situations. If Java code behaves correctly on most platforms - but it doesn't work on few distributions - you may as well report this as a bug to either Sun or the distribution. BTW, we are engineers, not PR people - so 'crappy' comments may happen :-) So if you have a patch or workaround - please reopen the bug and add the fix. It would be a better way to spend the time instead of arguing about closing/not closing it or hurt feelings :-) Costin Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the crappy comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e
Re: Postcard
Remy Maucherat wrote: Allistair Crossley wrote: *rotfl* that's not Remy at all! ;) Those viruses are annoying, since I cannot prevent them from reaching the list :( As long as they use a valid subscriber's address, I cannot do anything. I suppose it would be caught by a spam filter though. Rmy Maybe a solution would be to subscribe from an address that uses SPF - apache checks for SPF, so it'll reject it. I don't like SPF for many resons, but it does have its benfits :-) Gmail.com does spf btw. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk jni worker - apache + number of processes
The only way to do in-process with apache on unix is to use a multithreaded MPM and a small number of processes ( and lots of threads). JNI is not much more efficient than IPC - or at least not in the simplistic use. Even the applets in mozilla/konqueror/etc run out of process on unix ( but in-process on win and macosx ). Writting apache modules in java has been attempted before - unfortunately it never quite worked, and the multiprocess issue is just one of the problems. Costin Fox,Tim wrote: Hi Mladen - Thanks for your reply. I suspected as much. My real motivation here is to basically provide a java implementation of an apache module or filter. I didn't want to communicate via sockets or whatever to a shared java process due to performance considerations. Especially for doing stuff like setting the apache uri or filename via the request_rec, I thought that this would incur too much overhead. I'm guessing this is something that has been considered before. Any ideas? Maybe it's already been discounted for these reasons? Anyway, I guess this is turning into an Apache httpd question rather than a tomcat one! :) -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: 18 January 2005 12:43 To: Tomcat Developers List Subject: Re: mod_jk jni worker - apache + number of processes Fox,Tim wrote: Hi All- Apologies for cross-posting from the user group - but in retrospect I believe this might be a better forum for this question: I am interesting in using the in processes jni_worker with apache 2.0 on linux. My question concerns the number of instances of a jvm, and hence tomcat that will be created. My understanding is that, on linux the default mpm configuration will have multiple child server processes created. Does that mean there will be multiple jvms and hence multiple tomcat instances instantiated? Or is the jvm somehow shared across processes? You listed all the problems JNI connector faces on Linux, and also the facts why JNI is unusable. Is it a requirement of using the jni worker that the number of child server processes is limited to 1 in the apache config? I would suggest that you forgot all about inprocess JNI on any unix variant with Apache, or better all together. Even the stupid .NET has a separate process out of IIS. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
To be honest, I don't like where this is going. I think access to native functionality for tomcat is great - and starting with functionality provided by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't be easy to add. So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an official binding - we can switch), and keep it open for the other non-apr stuff that may be interesting. Costin William A. Rowe, Jr. wrote: At 01:56 PM 1/13/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? He he :) I didn't said it should be private to J-T-C nor Jakarta. But the fact is that we don't have OO languages infrastructure for APR glue code. Seems to me that we'll need to go through incubation to create self standing apr-java project, or something like apr-oo/java. Self standing? If apr is borked (and the oo-dev'ers prove it) do you want another layer in the middle? This probably should be closely paired to apr to ensure communications and direction. Having them both under the same pmc ensures that the apr project doesn't go off on some weird tangent that interferes with oo implementations (not that I expect this would happen.) If you think we can make something like that in a reasonable amount of time, count me in. Happy to encourage it and I'll present it (with myself as a list moderator) to the apr project, and invite our modperl friends along with John Sterling and others who have created C++ wrappers. In other case I can rename the package to whatever name desired if it breaks some policy or something like. This sort of surprises me coming from an ASF java developer. I seriously doubt this team would find it amusing to discover org.apache.catalina namespaces populating an xml project's code. -1 on appropriating another ASF project's namespace (the same -1 I should have offered to forking proxy.) +/-0 if you want to build on org.apache.jk.apr namespace. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecation and JK2
A lot of the code is actually specific to the now-dead Jk2 - if the native jk2 is gone, probably you should clean up this side as well. - org.apache.jk.apr - the not-quite apr jni layer that connects to the native objects, as well as 'in-process' launcher ( I doubt it can be used by jk1.x ), also common.JniHandler - ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2. Maybe it would be a good idea to rename the remaining files ( but please not org.apache.ajp - it would be confusing since this is the name of the very old connector package ). What is the story with in-process ? Is it still supported with jk1.x ? Costin Remy Maucherat wrote: Henri Gomez wrote: +0 JK / JK2 are also very specific to our current AJP implemtation. Maybe they should be called AJP instead ? I thouhgt I had done enough damage with my package renaming and class moving ;) The renaming here is nearly all located in strings which are supposed to be displayed to the user when there's an error, and also in comments - low impact stuff. PS: Happy New Year to all TC-DEV members :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecation and JK2
Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Wednesday, January 12, 2005 4:14 AM Subject: Re: Deprecation and JK2 A lot of the code is actually specific to the now-dead Jk2 - if the native jk2 is gone, probably you should clean up this side as well. - org.apache.jk.apr - the not-quite apr jni layer that connects to the native objects, as well as 'in-process' launcher ( I doubt it can be used by jk1.x ), also common.JniHandler - ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2. I think that proxy_ajp is hoping to be able to use ChannelUn someday. It's no more Jk2 specific than ChannelSocket is. It is using the jk2 'object' - it can be easily rewritten to use the new apr library directly, but in the current form I don't see how it could be used without jk2 native (and if you want to add it - it's easier to start from channelSocket ). Maybe it would be a good idea to rename the remaining files ( but please not org.apache.ajp - it would be confusing since this is the name of the very old connector package ). What is the story with in-process ? Is it still supported with jk1.x ? Only the (very) old 3.3 JniHandler at the moment. Maybe the new apr library will help improve this too. BTW, starting in-process java in jdk1.5 ( on linux at least ) it's amazing, no longer requires LD_LIBRARY_PATHs and seem to 'just work'. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Mladen Turk wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Looks good. It seems it still does a lot of String operations in native - unlike SWT for example, where it's almost always byte[]. Also the typical memcpy, etc should be included somewhere to allow data to move from/to the pool and java heap. Why not checking it in j-t-c ? Just to make sure - you expect it to also have non-apr native methods ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java
Remy Maucherat wrote: Costin Manolache wrote: Maybe: * @author Jason Hunter, as part of the book Java Servlet Programming * (O'Reilly). See a href=http://www.servlets.com/book; * http://www.servlets.com/book/a for more information. ? I think it is fair to respect the author wish for attribution. Given that the board recomends against @author tags and they may be someday removed, it doesn't matter that much... I am all in favor of giving proper attribution (author tags), but -1 on anything which restricts the ASF's copyright on the code (like advertising clauses in this case). As a result, I have to agree with all that pointed out that the code should be rewritten (in this case, the encoding list must be reconstructed from scratch). Rémy There is no advertising clause in this. He made it clear that the code is donated to ASF, under ASF license. Mentioning that the author developed the code while working on a book or while being paid by a company can't be that bad. I don't understand why ASF is so advertising-fobic when it comes to authors or companies that donate code or employee time to ASF, but until recently strictly required advertisment for the code owner ( ASF ) not only in the code, but also on the web site. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
Jason Hunter wrote: nor see why we need an exception for such a such a small amount of code. You need an exception because (a) the code was included from a third party codebase and (b) a lot of research and testing went into compiling the map used by the mapper. I can easily add an @author tag for you in the relevant files, but the comment currently creates a legal doubt. As I wrote in my email and for the archived record, I want the classes to have the recognition that is expected when Apache includes code from a third party library that's under a license that requires attribution (just like Apache's). The files says copyright ASF - but it seems that's not completely accurate ( I assume someone mistakenly removed your Copyright Jason Hunder ? ). As an author, you should be able to keep any notice that you consider apropriate. If you didn't explicitely assign the coypright to ASF ( or to Sun ), than I don't think it would be right for anyone to remove your name or attribution. If you did assign the rights to ASF - then as you know anything can be removed or changed by the new owner, including @author tags or any mention of previous author ( just make sure your name does gets into whatever obscure file lists all people who contributed something ) :-) Note: Many companies and individuals donated more than these 10 lines of code, Yes, and I too donated plenty of code to the Tomcat codebase. But these classes I donated (to Sun at the time) with attribution because they were from a separate, pre-existing codebase with a life of its own. If you write a book and include a paragraph from someone else's book with permission, you mention it and you point at the source of the original work. You don't just say, Written by author X you say, Written by author X as part of book Y, published by Z. That's why the attribution I put on those classes includes the who, what, and where. I see it as the ethical thing to do. I fully agree. Doesn't matter how small a contribution is ( or looks at some later time ), keeping the reference to the author and whatever else the author wants to include is the right thing to do ( if the code is accepted and used ). Too bad what's ethical doesn't matter that much, only copyrights and IP ownership :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java
Maybe:
* @author Jason Hunter, as part of the book Java Servlet Programming
* (O'Reilly). See a href=http://www.servlets.com/book;
* http://www.servlets.com/book/a for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be
someday removed, it doesn't matter that much...
Costin
[EMAIL PROTECTED] wrote:
remm2005/01/04 14:14:42
Modified:util/java/org/apache/tomcat/util/http
LocaleToCharsetMap.java
catalina/src/share/org/apache/catalina/util
CharsetMapper.java
Log:
- Remove legally questionable comment. The code was properly donated to the ASF.
Revision ChangesPath
1.3 +2 -14 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java
Index: LocaleToCharsetMap.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LocaleToCharsetMap.java 24 Feb 2004 08:50:04 - 1.2
+++ LocaleToCharsetMap.java 4 Jan 2005 22:14:42 - 1.3
@@ -14,15 +14,6 @@
* limitations under the License.
*/
-/*
- *
- * This class was originally written by Jason Hunter [EMAIL PROTECTED]
- * as part of the book Java Servlet Programming (O'Reilly).
- * See http://www.servlets.com/book for more information.
- * Used by Sun Microsystems with permission.
- *
- */
-
package org.apache.tomcat.util.http;
import java.util.*;
@@ -30,11 +21,8 @@
/**
* A mapping to determine the (somewhat arbitrarily) preferred charset for
* a given locale. Supports all locales recognized in JDK 1.1.
- * This class was originally written by Jason Hunter [EMAIL PROTECTED]
- * as part of the book Java Servlet Programming (O'Reilly).
- * See a href=http://www.servlets.com/book;
- * http://www.servlets.com/book/a for more information.
- * Used by Sun Microsystems with permission.
+ *
+ * @author Jason Hunter
*/
public class LocaleToCharsetMap {
1.5 +2 -8 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
Index: CharsetMapper.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CharsetMapper.java 29 Aug 2004 16:46:13 - 1.4
+++ CharsetMapper.java 4 Jan 2005 22:14:42 - 1.5
@@ -14,13 +14,6 @@
* limitations under the License.
*/
-/*
- * This class is based on a class originally written by Jason Hunter
- * [EMAIL PROTECTED] as part of the book Java Servlet Programming
- * (O'Reilly). See http://www.servlets.com/book for more information.
- * Used by Sun Microsystems with permission.
- */
-
package org.apache.catalina.util;
@@ -38,6 +31,7 @@
* it loads, or by subclassing it (to change the algorithm) and then using
* your own version for a particular web application.
*
+ * @author Jason Hunter
* @author Craig R. McClanahan
* @version $Date$ $Version$
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Why don't you check in some of this to j-t-c or some 'proposal' area ? AFAIK apr has a lot of functionality, but not everything is included. It would be nice if it is not limited to apr. Usually with JNI the hardest part is to build, distribute and then set it up and debug ld_library_path issues. If you do it for one library, it's easy to add more. Costin Mladen Turk wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Or: 1. Wait for Mladen to check in the code 2. figure out how to build it and how to install it easily in tomcat ( and other java applications ). 3. probably add one native method. I don't think wrapping it as apr component makes sense ( apr is not a component system like xpcom ). 4. write the java mbean - using the native method and making all conversions between the native signature and java style ( if SWT-style of jni is used - i.e. using byte[], int pointers, etc - and doing java adaptation in java ). I'm as curious as you are to see the code and figure out how it can be used, I love jni :-) Costin Peter Lin wrote: So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this? 1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED] wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Mladen Turk wrote: Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. Things like true shared memory, process mutexes, advanced networking, pipes, etc. that are missing from the core Java will be supported. Usages are many, like writing high-performance networking connector for Tomcat, making Tomcat a Apache mpm-like server with multiple JVMs, etc... I hope I'll have a working start point this month, so we could discuss is it worth the effort at all, would it fit inside JTC, commons, or to go trough apache incubation as a separate project. Mladen. Anything that allows Java to do things only native apps can do instead of beeing as dumb as the dumbest platform is worth the effort :-) JTC already has some apr and jni code ( it is true, using the dead jk2 model ), why not start there and if it grows big enough move to commons? BTW - it would be really great if it would use the SWT model, i.e. JNI methods matching exactly the APR signatures and param types, with minimal ammount of C wrapper code. It works really well, and it's the easiest to maintain and fastest of all JNI flavors I've seen. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. I would also update JMeter in the process to display the system load average. peter lin Wouldn't be better to have a way to display an arbitrary mbean attribute, plus an mbean tracking system load ( and maybe memory/disk statistics ) ? Dealing with jni is allways tricky ( including build issues, etc ) - it is better to have it in separate modules. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
As implementation - I assume you weren't going to add a native method and a .so library to the standalone tomcat distribution :-) Adding capability to StatusServlet to report arbitrary mbean attributes would make this feature easy to add ( there is some code in JmxProxyServlet - but it it would be much better if integrated and made consistent with the status servlet ). For the JNI + mbean implementation - it may be better to use a separate component ( I don't see why it would be specific in any way to tomcat - any jmx-based app could use this ). There are several other OS-specific informations of interest ( including in Windows ), JMX is designed exactly for this - to expose management info for different systems. Costin Peter Lin wrote: that's why I decided it was a good idea to ask for other's thoughts. From a stress testing perspective, I find system load stats very valuable. breaking tomcat isn't something I find desirable either, but there has to be a better way to measure system load other than ssh into the server and use top. manually doing top or sysinfo is fine for load testing, but for performance monitoring, something automated is desirable. My thought was to make it optional and have it detect whether or not a native lib for that platform exists. If it doesn't it would affect the status servlet and would look exactly the same as it does now. on the otherhand, if the user enables it and a native lib exists, it could display the system load. the only other option is to lobby Sun to add system load stats to the VM, so that it is portable across platforms. peter On Fri, 31 Dec 2004 17:27:03 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I would personally have some reservations about doing this... It's a little better if it's a module you can activate and deactivate, but still... First, if it's not something you can do cross-platform, I'm not sure I'd like it. AFAIK Tomcat is nicely cross-platform now, anything that breaks that wouldn't be good I think. I understand this would be an optional component (right?), so it wouldn't actually be *breaking* anything, but the expectation I think is that anything in Tomcat works on all platforms, so would it be a good thing to introduce something that doesn't fit that mold? Second, and more importantly, it doesn't feel right to me to expose this type of information through an app server. Your talking about statistics that aren't truly related to the app server, although is certainly affected by the app server, so it's debatable whether they should be there or not. I agree this is useful information to have access to, but I'm not sure it'd be the right place for it. Have you considered maybe making this part of some Commons package? Make it something that any app could make use of, that might be a very nice thing. Heck, it might be somewhere in there already for all I know. Just my thoughts on it anyway. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Peter Lin wrote: it could be a separate module. It definitely should use MBean. In terms of getting the CPU load stats, I was thinking of calling the standard sysinfo loads[]. Is there some other way of getting the system load stats? or CPU stats? that doesn't require calling native code? peter On Fri, 31 Dec 2004 13:13:54 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. I would also update JMeter in the process to display the system load average. peter lin Wouldn't be better to have a way to display an arbitrary mbean attribute, plus an mbean tracking system load ( and maybe memory/disk statistics ) ? Dealing with jni is allways tricky ( including build issues, etc ) - it is better to have it in separate modules. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13_worker.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Costin Manolache wrote: Are you joking :-) ? If we can not alloc couple of bytes from the system, then the entire system is unstable. Or that the process that makes the malloc() has reached a configurable limit of the amount of memory it is allowed to use. Sure, but the system is still unusable. This checking is done inside worker_factory, called from init_jk, so IMHO the apache will fail long before. But if everyone thinks it's a good to check for failed memory allocation on small objects, I'll revert the patch. Well, I see your point - probably it doesn't matter much, I'm sure other places in code will not check and it would crash anyway. Most OSes use swap, so the system will trash and become unuseable before running out of memory. But there are other cases where the swap is not used - and then malloc failure is a common condition under load. If the system is very loaded, it is possible you'll run low on memory and you don't know which malloc will fail - maybe the small one. The correct behavior would be to give up and return a 500 on the request ( that may go through since apache probably already have the memory allocated in the memory pools ). On single process/multithread systesm, an apache server crashing under load is not a good thing :-) IMO all mallocs should be checked - but probably I spend too much time with systems with very little memory where a crash is not such a good thing :-) Costin Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13_worker.c
Mladen Turk wrote: David Rees wrote: Are you sure it's a good idea to wait until it crashes rather than fail in a controlled method? How much overhead is there to check aw-name for NULL? Can't be much... Yes I am. Look, if the system can not alloc 1000 bytes of memory what's the purpose to continue? Mt. Are you joking :-) ? At least do an printf and exit(), coredump is never good (some systems don't collect the core - so the user will have no idea what just happened ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties
Remy Maucherat wrote: Jan Luehe wrote: Bill Barker wrote: In the case I was referring to, some project was storing a servlet request (facade) in a ThreadLocal and, due to a bug in their code, was hanging on to it beyond the request's lifetime. This was happening only under rare circumstances. Great use case. And the talented programmer who coded that thing couldn't figure out what the problem was quickly enough without a proper error message, I assume ;) So in this case, the Request behind the facade was indeed null. So now he'll get an error message saying null request. Actually, it sounds like one of these useless M$ error messages. Lol and +1 for Bill's suggestion to change text to if you're reading this, you're a moron :D As long as the exception doesn't get into the web browser of some user :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib directory
Garrison, Meg wrote: Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. It would be a good idea, but I don't think it is possible at the moment. Commit access requires a unix account on a machine, at least for cvs. Even if this could be solved - there are non-technical problems, ASF requires a CLA, and a certain review and oversight process. Ant has an ant-contrib project on sourceforge ( including few ant committers ). Maybe we should have a tomcat-contrib as well. This would be a good idea even for committers - there is experimental stuff and code that is not necesarily servlet container but is tomcat related ( like non-http servers, etc ). Costin Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib directory
Shapira, Yoav wrote: Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... It seems there is some mass - if the same idea is mentioned at the same time by more people :-) I think it would be good to have few tomcat committers as project admins - at least 3 (the magic number). I volunteer, it seems Yoav is also interested - anyone else ? Costin Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to boot us out.. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now.. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have
Re: [VOTE] 5.5.3 Stability Rating
Remy Maucherat wrote: - Allowing pluggability for commons-modeler Can you elaborate a bit more on this ? The basic functionality of modeler is to take an object and a descriptor and return an mbean. This can be made pluggable - a simple interface with a single method is probably enough to hide most of modeler's logic. But all the descriptors need to be converted. But what do you want to use instead and how ? Move the mbean descriptors to conf/ so it can be replaced with another format ( since this is specific to modeler ) ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: True, in ASF land as in other community, it's the users and developpers base which make a solution/product successfull or forgotten. BTW, jk 1.2.x is allready very stable and should stay like this for now : - JK 1.2.x is now on bug-fix only mode. - AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in) Should we start a new AJP/JK/whatever connector is another story which has been debated this summer when we speak about mod_ajp. We should first be very prudent since users may be puzzled by : jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine. Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev and will be present only in Apache 2.1.x, may be there is a need for a new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we should list the requested features missing in jk 1.2.x For IIS/Domino - I think having it maintained and developed by apache is a waste. In both mod_jk and mod_jk2 we pay a significant price for trying to be multi-server, and it seems clear this is a feature that only few people want. If an external project wants to create an IIS connector based on mod_ajp or jk - that's great. But they should do it taking full advantage of whatever IIS provides, including consistent config, etc. I suggest take a look about what was detailed in mod_ajp thread (July 2004) and see if a new consensus could appears. On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker [EMAIL PROTECTED] wrote: - Original Message - From: Dave Oxley [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 11, 2004 3:35 PM Subject: Re: JK Todo List So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? JK2 is dead because (like mod_webapp before it :), it failed to attract a community interested in maintaining it. You might as well ask 'why doesn't mod_webapp just replace JK?' There are also technical reasons I think. Like the attempt to object oriented C but without using one of the existing solutions. And not droping featurea from mod_jk. But you're right - lack of community interest was the main problem. Costin Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? Why use APR in mod_jk ? Support for Apache1.3 is IMO more important than support for IIS. And so far, mod_jk seems to work without any apr - and it is in maintainance mode, so no major changes should be made. Costin On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller [EMAIL PROTECTED] wrote: From: Mladen Turk [EMAIL PROTECTED] Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? I have to agree - for Apache ( even 2 ) the complexity of multiprocess is too big and it's not worth it in almost all cases. But having a jni library to access OS-specific features is not a bad idea. For example registry, change UID ( I know c-daemon could do the same), unix sockets, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good That's not hard to add. You actually need the first free port in the range for rmiregistry - or you can use existing rmiregistry if one is found. You need different rmi names - that's easier. Adding user/pass/ssl is not hard - if someone has the itch it shouldn't be a problem. javax.man.remote has all that's needed AFAIK. IF you look at jmxremote webapp that I checked in - there is no mx4j or sun code, just plain javax. Costin -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Todo list
Remy Maucherat wrote: Remy Maucherat wrote: - Decent default java.util.logging configuration I don't see any sensible configuration given what the standard handlers are (limited rotation options, little possibility of avoiding hardcoding logfiles paths, etc). Also, the reload operation is not exposed to JMX (other operations are exposed, however). So I'll add a default configuration file from the JRE, where we'll add some example catagory names to help users, but that's unfortunately all that can be done by default. Rémy And some people are using log4j :-) I just can't live with the 2-line per log and the formated date, and I found no way to change this ( except writting my own formatter ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin, can you elabborate the purpose of the patch? Perhaps I've missed few discussions. There are few goals: - allow tomcat components ( connector, valves, etc ) to be added/removed/upgraded dynamically, at runtime - without requiring a full restart. - cleanup the startup code - the split startup package, lots of introspection and dependencies ( commons-logging, jmx needed in CLASSPATH ) - maybe improve the class loading - for example WebappClassLoader use of the jar index, the code is a bit complex, etc - make it easier to integrate tomcat in apps like jboss or eclipse - which both use similar class loaders and module mechanisms ( jbossmx and osgi ). One extra benefit may be on allowing more flexibility in the common/shared/webapp hierarchy - if WebappClassLoader extends the loader, it will be easier to have webapps using different versions of shared libraries ( right now you need to place shared libs in shared or common, and you can't have more than a version ). I've been trying to do this for a very long time - there is some code in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but using an m-let-like classloader is a better solution than what was there. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote - New directory
costin 2004/10/06 08:14:04 jakarta-tomcat-catalina/webapps/jmxremote - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF - New directory
costin 2004/10/06 08:14:09 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src - New directory
costin 2004/10/06 08:14:16 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org - New directory
costin 2004/10/06 08:14:29 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache - New directory
costin 2004/10/06 08:14:35 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat - New directory
costin 2004/10/06 08:14:39 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets - New directory
costin 2004/10/06 08:14:45 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets/jmxremote - New directory
costin 2004/10/06 08:14:51 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets/jmxremote - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets/jmxremote JmxRemoteServlet.java
costin 2004/10/06 08:17:24
Added: webapps/jmxremote/WEB-INF web.xml
webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets/jmxremote
JmxRemoteServlet.java
Log:
Add the jmx remote class.
mx4j.jar and mx4j-remote ( or JDK1.5 ) are needed to compile.
Revision ChangesPath
1.1 jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/web.xml
Index: web.xml
===
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
display-nameJMX Remote Connector Loader/display-name
description
Will start Jmx RMI connector if JMX is available.
/description
servlet
servlet-nameJmxRemote/servlet-name
servlet-classorg.apache.tomcat.servlets.jmxremote.JmxRemoteServlet/servlet-class
init-param
param-namedebug/param-name
param-value0/param-value
/init-param
!--
--
load-on-startup1/load-on-startup
/servlet
/web-app
1.1
jakarta-tomcat-catalina/webapps/jmxremote/WEB-INF/src/org/apache/tomcat/servlets/jmxremote/JmxRemoteServlet.java
Index: JmxRemoteServlet.java
===
/*
* Created on Jul 14, 2004
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package org.apache.tomcat.servlets.jmxremote;
import java.io.IOException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import javax.management.MBeanServer;
import javax.management.MBeanServerFactory;
import javax.management.remote.JMXConnectorServer;
import javax.management.remote.JMXConnectorServerFactory;
import javax.management.remote.JMXServiceURL;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
// Using o.a.tomcat.servlets because o.a.catalina won't be loaded unless trusted app
/**
* Experimental servlet allowing connectors to be deployed and managed using the
* webapp infrastructure.
*
* Connectors can be packaged in a WAR file, deployed and managed using the
* normal tools. Configuration is done using web.xml init-params - while this is
* not as simple as connector tags in server.xml, it may be easier to support
* in tools and explain to webapp developers.
*
* Since webapp class loader is used - start/stop as well as reloading can be
* controlled from the /manager.
*
* Issues:
* - may polute the webapps namespace - solution would be to reserve a prefix
* or use some invalid/special name.
*
* @author Costin Manolache
*/
public class JmxRemoteServlet extends HttpServlet {
JMXConnectorServer cntorServer = null;
public void init(ServletConfig conf) throws ServletException {
// otherwise log doesn't work
super.init(conf);
MBeanServer mBeanServer = null;
Registry reg=null;
// TODO: use config to get the registry port, url, pass, user
try {
if( reg==null )
reg=LocateRegistry.createRegistry(1099);
} catch( Throwable t ) {
log(Can't start registry - it may be already started: + t);
}
try {
mBeanServer = null;
if (MBeanServerFactory.findMBeanServer(null).size() 0) {
mBeanServer =
(MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
} else {
mBeanServer = MBeanServerFactory.createMBeanServer();
}
} catch( Throwable t ) {
log(Can't get the mbean server + t);
return;
}
try {
JMXServiceURL address = new
JMXServiceURL(service:jmx:rmi://rmiHost/jndi/rmi://localhost:1099/jndiPath;);
cntorServer =
JMXConnectorServerFactory.newJMXConnectorServer(address, null,
mBeanServer);
cntorServer.start();
} catch (Throwable e) {
log(Can't register jmx connector , e);
}
}
/** Stop the connector
*
*/
public void destroy() {
try {
if( cntorServer != null ) cntorServer.stop();
} catch (Exception e) {
e.printStackTrace();
}
}
public void service(HttpServletRequest req
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote build.xml
costin 2004/10/06 08:24:57
Added: webapps/jmxremote build.xml
Log:
build file
Revision ChangesPath
1.1 jakarta-tomcat-catalina/webapps/jmxremote/build.xml
Index: build.xml
===
project name=manager default=build-main basedir=.
!-- = Initialize Property Values === --
!-- See build.properties.sample in the top level directory for all --
!-- property values you must customize for successful building!!!--
property file=${user.home}/build.properties/
property file=build.properties/
property file=../build.properties/
property file=../../build.properties/
property file=../../../jakarta-tomcat-5/build.properties/
property file=../../../jakarta-tomcat-5/build.properties.default/
property name=build.compiler value=modern/
property name=webapps.build value=../build/
property name=webapps.distvalue=../dist/
property name=webapp.name value=jmxremote/
!-- Dependent JARs and files --
property name=servlet-api.jar
value=${api.home}/jsr154/dist/lib/servlet-api.jar/
property name=jsp-api.jar value=${api.home}/jsr152/dist/lib/jsp-api.jar/
path id=build.classpath
pathelement location=${catalina.deploy}/classes/
pathelement location=${commons-fileupload.jar}/
pathelement location=${commons-modeler.jar}/
pathelement location=${jmx.jar}/
pathelement location=${jmx-remote.jar}/
pathelement location=${servlet-api.jar}/
pathelement location=${jsp-api.jar}/
/path
!-- === BUILD: Create Directories == --
target name=build-prepare
mkdir dir=${webapps.build}/
mkdir dir=${webapps.build}/${webapp.name}/
mkdir dir=${webapps.build}/${webapp.name}/images/
mkdir dir=${webapps.build}/${webapp.name}/WEB-INF/
mkdir dir=${webapps.build}/${webapp.name}/WEB-INF/classes/
/target
!-- BUILD: Copy Static Files == --
target name=build-static depends=build-prepare
copy todir=${webapps.build}/${webapp.name}
fileset dir=.
exclude name=build.*/
/fileset
/copy
/target
!-- = BUILD: Compile Server Components = --
target name=build-main depends=build-static
javac srcdir=WEB-INF/src
destdir=${webapps.build}/${webapp.name}/WEB-INF/classes
debug=${compile.debug} deprecation=${compile.deprecation}
optimize=${compile.optimize}
excludes=**/CVS/**
classpath refid=build.classpath /
/javac
/target
!-- BUILD: Rebuild Everything = --
target name=all depends=build-clean,build-main
description=Clean and build manager webapp/
!-- === BUILD: Clean Directory = --
target name=build-clean
delete dir=${webapps.build}/${webapp.name}/
/target
!-- === DIST: Create Directories === --
target name=dist-prepare
mkdir dir=${webapps.dist}/
/target
!-- === DIST: Create Distribution Files --
target name=dist depends=build-main,dist-prepare
description=Create manager webapp binary distribution
jar jarfile=${webapps.dist}/${webapp.name}.war
basedir=${webapps.build}/${webapp.name} includes=**/
/target
!-- === DIST: Clean Directory == --
target name=dist-clean
deltree dir=${dist.dir}/${webapp.name}/
/target
!-- == Convenient Synonyms = --
target name=clean depends=build-clean,dist-clean
description=Clean build and dist directories/
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/jmxremote README
costin 2004/10/06 08:30:16 Added: webapps/jmxremote README Log: Add the readme Revision ChangesPath 1.1 jakarta-tomcat-catalina/webapps/jmxremote/README Index: README === Simple webapp that loads the Jmx remote connector. You need to add mx4j-remote.jar to your common loader or use JDK1.5. Any other JMX implementation that supports javax.remote should work as well. The directory structure is a bit different from manager and the other webapps in catalina. I'm using eclipse, set up to use separate output dirs and autocompile. The output dir is set to WEB-INF/classes, and I have a symlink to the jmxremote dir in the sources - so basically there is no need to run ant/manually compile, just save the file and reload the app. MISSING: user/password, SSL, custom RMI server address - can be easily added using servlet params ( and should be added if this ever gets included in the distro ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: Costin, can you elabborate the purpose of the patch? Perhaps I've missed few discussions. There are few goals: - allow tomcat components ( connector, valves, etc ) to be added/removed/upgraded dynamically, at runtime - without requiring a full restart. - cleanup the startup code - the split startup package, lots of introspection and dependencies ( commons-logging, jmx needed in CLASSPATH ) - maybe improve the class loading - for example WebappClassLoader use of the jar index, the code is a bit complex, etc - make it easier to integrate tomcat in apps like jboss or eclipse - which both use similar class loaders and module mechanisms ( jbossmx and osgi ). One extra benefit may be on allowing more flexibility in the common/shared/webapp hierarchy - if WebappClassLoader extends the loader, it will be easier to have webapps using different versions of shared libraries ( right now you need to place shared libs in shared or common, and you can't have more than a version ). I've been trying to do this for a very long time - there is some code in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but using an m-let-like classloader is a better solution than what was there. What about commons-deamon? What about it :-) ? Daemon is a different level - it's about launching a resident process (or service in windows ). No connection with how the process is loading its classes. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader Loader.java Module.java
costin 2004/10/06 08:41:44
Modified:util build.xml
util/loader/org/apache/tomcat/util/loader Loader.java
Module.java
Log:
A bit of cleanup. The lib dir and the checked in binaries are long gone.
Avoid creation of loader dir if loader is not used/compiled.
Revision ChangesPath
1.30 +3 -3 jakarta-tomcat-connectors/util/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/util/build.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- build.xml 6 Oct 2004 05:16:06 - 1.29
+++ build.xml 6 Oct 2004 15:41:44 - 1.30
@@ -18,8 +18,8 @@
property name=puretls.lib location=${puretls.home}/
property name=puretls.jar location=${puretls.lib}/puretls.jar/
-property name=commons-logging.jar location=../lib/commons-logging.jar /
-property name=jmx.jar location=../lib/mx4j.jar /
+property name=commons-logging.jar
location=${base.path}/commons-logging-1.0.4/commons-logging.jar /
+property name=jmx.jar location=${base.path}/mx4j-2.0.1/lib/mx4j.jar /
property name=tomcat-util.lib value=${tomcat-util.build}/lib /
property name=tomcat-util.jar value=${tomcat-util.lib}/tomcat-util.jar /
property name=tomcat-loader.jar value=${tomcat-util.lib}/tomcat-loader.jar
/
@@ -48,7 +48,6 @@
target name=build-prepare depends=detect
mkdir dir=${tomcat-util.build}/
mkdir dir=${tomcat-util.build}/classes/
-mkdir dir=${tomcat-util.build}/loader/
mkdir dir=${tomcat-util.lib}/
/target
@@ -105,6 +104,7 @@
/target
target name=tomcat-loader.jar depends=build-prepare
+mkdir dir=${tomcat-util.build}/loader/
javac srcdir=loader
destdir=${tomcat-util.build}/loader
deprecation=${compile.deprecation}
1.2 +7 -0
jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Loader.java
Index: Loader.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Loader.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Loader.java 6 Oct 2004 05:00:04 - 1.1
+++ Loader.java 6 Oct 2004 15:41:44 - 1.2
@@ -489,6 +489,13 @@
return result;
}
+void notifyModuleStart(Module module) {
+if(listener!=null) listener.moduleStart(module);
+}
+
+void notifyModuleStop(Module module) {
+listener.moduleStop(module);
+}
/** Add a module listener.
*
1.2 +2 -2
jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Module.java
Index: Module.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/loader/org/apache/tomcat/util/loader/Module.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Module.java 6 Oct 2004 05:00:04 - 1.1
+++ Module.java 6 Oct 2004 15:41:44 - 1.2
@@ -182,7 +182,7 @@
classLoader.start();
-getRepository().getLoader().listener.moduleStart(this);
+getRepository().getLoader().notifyModuleStart(this);
} catch (Throwable t) {
log( LifecycleException , t );
@@ -204,7 +204,7 @@
//if (DEBUG)
log(stop(), null);
-getRepository().getLoader().listener.moduleStop(this);
+getRepository().getLoader().notifyModuleStop(this);
started = false;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: What about commons-deamon? What about it :-) ? Daemon is a different level - it's about launching a resident process (or service in windows ). No connection with how the process is loading its classes. Sure, but the wheel was invented long time ago :). How about making things usable? Which things to make usable ? Daemon ? It's not my itch to start services on windows:-) Yes, the wheel was invented long ago - and we are still using the simplistic hierarchical class loader + delegation. Do we really need all those different loaders? That can be said about anything :-) I'm making the compile optional - so if you don't explicitely ask for it it'll not get compiled. When it's completely ready - I hope it will replace Bootstrap/StandardClassLoader - so we'll still have 1 loader for standalone. If embeded - as I said, the intent is to not use the loader but the embedor's loader - however ability to split tomcat in smaller components and manage each separately should remain ( supported by the embedding app loader ). That's why the loader is mirroring the fundamental behavior of mlet/jboss/eclipse/osgi - i.e. repository of classloaders delegating to each other. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Remy Maucherat wrote: I didn't have time to look at the code yet, though. Wait a week or 2 - the loader part is fine, but the catalina side is still a bit messy and I need to find a good way to integrate with the build ( to make it completely optional/isolated - I don't want to affect the 5.5 schedule by breaking something :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: Dominik Drzewiecki wrote: Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. Because they don't work with JDK1.4, and any people (including me) can't switch to Java5 since it breaks too much :-) The option you mention are in fact the same thing with the webapp I'm suggesting - they have the effect of loading the standard javax.management.remote connector. The difference is that jx.m.r is using the standard API and will work with any JMX implementation, while com.sun is specific to sun's implementation of jmx. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM 1.5) Your post motivated me for trying jconsole, and I have to say it's really good. Yes, jconsole is the reason I wrote the app too. Plus the fact that mx4j2.0 no longer works with jkmx ( they dumped the connector beans from distribution since they now support the standard jx.m.r ) As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5. Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed. No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/loader - New directory
costin 2004/10/05 21:56:33 jakarta-tomcat-connectors/util/loader - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/loader/org - New directory
costin 2004/10/05 21:56:39 jakarta-tomcat-connectors/util/loader/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
