Re: [VOTE] 4.1.30 release vote
Remy Maucherat wrote: Amidst all this junk email ... ballot Release 4.1.30 as Stable: [ ] Yes [ ] No /ballot Could you wait until I have release common/daemon? 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]
Hi
-- Virus Warning Message (on the network) Found virus WORM_MIMAIL.R in file message.scr The file message.scr is moved to /var/log/virus/virIUHODGM.O. This is a machine-generated message, please do not reply via email. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. - The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. -- Virus Warning Message (on the network) message.scr is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26509] - DataSourceRealm for local contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509 DataSourceRealm for local contexts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 08:23 --- Indeed. So why do you create a new bug ? This is a duplicate. *** This bug has been marked as a duplicate of 25805 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25805] - DataSourceRealm cannot find the JNDI DataSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805 DataSourceRealm cannot find the JNDI DataSource [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||com --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 08:23 --- *** Bug 26509 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.30 release vote
jean-frederic clere wrote: Remy Maucherat wrote: Amidst all this junk email ... ballot Release 4.1.30 as Stable: [ ] Yes [ ] No /ballot Could you wait until I have release common/daemon? Why ? 4.1.30 doesn't include commons-daemon. (4.1.x uses JavaService, and doesn't ship jsvc) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26135] - Tomcat 5.0.16 leaks memory when a webapp is reloaded or stopped/started
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26135. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26135 Tomcat 5.0.16 leaks memory when a webapp is reloaded or stopped/started [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Component|Webapps:Manager |Catalina Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 08:35 --- I looked into that already. While the classloader is not being garbage collected (this is the only object not being GCed) due to an unknown reason, no references are kept to it (as seen in a profiler), so from the Tomcat programming perspective, there's nothing to fix. Many simple webapps reload without leaking memory, but Struts webapps seem to pose a problem. Of course, there are also ways for a shared library to cause GC trouble when reloading, and this cannot be fixed, so you cannot assume a webapp reload will never leak memory. There's nothing in the release notes, because there's no conclusive information available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26507] - Jasper Generator java Error (useBean ObjectArray)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26507. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26507 Jasper Generator java Error (useBean ObjectArray) [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 08:44 --- Even if that does work for you, useBean is used to manipulate JavaBeans. Look into the Java spec for what a JavaBean is, but it's certainly not an array. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add ability for Realm authentication to tell the user the reason for auth failure
[Carlos H.] wrote: On Friday 23 January 2004 20:59, Remy Maucherat wrote: - 26236 about the JAAS realm: it would be a very useful fix, and shouldn't be too complex Well... I've tried to reproduce the bug... I've created my own LoginModule, and two classes wich implements de java.security.Principal interface (one for the user principal and other to the roles principals) just like the bug description said, and it worked fine! I also couldn't figure out how the method hasRole() in the RealmBase class can be related to this problem because the method createPrincipal() (which is called by the authenticate() method in the JAASRealm class) creates a GenericPrincipal, as expected by the hasRole() method. I think the problem can be related to the LoginModule of the user application, maybe it's not returning any RolePrincipal or something like that. As a new guy to the tomcat source-code, I can be just missunderstanding something... any ideas? Thanks in advance! Yes, I don't fully understand the bug report. You should add your comments to the bug: it is useful information. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java mbeans-descriptors.xml
remm2004/01/29 02:47:39
Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java mbeans-descriptors.xml
Log:
- Add localDataSource flag, based on code submitted by Neil Katin.
- Bug 25805.
Revision ChangesPath
1.5 +38 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java
Index: DataSourceRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DataSourceRealm.java 26 Jan 2004 19:47:16 - 1.4
+++ DataSourceRealm.java 29 Jan 2004 10:47:39 - 1.5
@@ -74,6 +74,7 @@
import javax.naming.Context;
import javax.sql.DataSource;
+import org.apache.naming.ContextBindings;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.ServerFactory;
import org.apache.catalina.core.StandardServer;
@@ -125,6 +126,12 @@
/**
+ * Context local datasource.
+ */
+protected boolean localDataSource = false;
+
+
+/**
* Descriptive information about this Realm implementation.
*/
protected static final String name = DataSourceRealm;
@@ -188,6 +195,23 @@
}
/**
+ * Return if the datasource will be looked up in the webapp JNDI Context.
+ */
+public boolean getLocalDataSource() {
+return localDataSource;
+}
+
+/**
+ * Set to true to cause the datasource to be looked up in the webapp JNDI
+ * Context.
+ *
+ * @param localDataSource the new flag value
+ */
+public void setLocalDataSource(boolean localDataSource) {
+ this.localDataSource = localDataSource;
+}
+
+/**
* Return the column in the user role table that names a role.
*
*/
@@ -446,10 +470,17 @@
private Connection open() {
try {
-StandardServer server = (StandardServer) ServerFactory.getServer();
-Context context = server.getGlobalNamingContext();
+Context context = null;
+if (localDataSource) {
+context = ContextBindings.getClassLoader();
+context = (Context) context.lookup(comp/env);
+} else {
+StandardServer server =
+(StandardServer) ServerFactory.getServer();
+context = server.getGlobalNamingContext();
+}
DataSource dataSource = (DataSource)context.lookup(dataSourceName);
-return dataSource.getConnection();
+ return dataSource.getConnection();
} catch (Exception e) {
// Log the problem for posterity
log(sm.getString(dataSourceRealm.exception), e);
1.3 +4 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/mbeans-descriptors.xml
Index: mbeans-descriptors.xml
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/mbeans-descriptors.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mbeans-descriptors.xml10 Nov 2003 20:00:50 - 1.2
+++ mbeans-descriptors.xml29 Jan 2004 10:47:39 - 1.3
@@ -21,6 +21,10 @@
non-plaintext format
type=java.lang.String/
+attribute name=localDataSource
+ description=Configures if the DataSource is local to the webapp
+ type=boolean/
+
attribute name=roleNameCol
description=The column in the user role table that names a role
type=java.lang.String/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26513] New: - Tomcat NT service creates StdOutputFile/StdErrorFile empty files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513 Tomcat NT service creates StdOutputFile/StdErrorFile empty files Summary: Tomcat NT service creates StdOutputFile/StdErrorFile empty files Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When starting Tomcat as an NT Service and specifying where to redirect the standard output and standard error streams through the --StdOutputFile and --StdErrorFile options, the desired files are created but left empty. I noticed the same behaviour in Tomcat 5.0.16, too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26516] New: - Lost Session when SessionCookie is blocked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26516. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26516 Lost Session when SessionCookie is blocked Summary: Lost Session when SessionCookie is blocked Product: Tomcat 5 Version: 5.0.18 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The admin applocation lost the session, when the button commit changes in the banner frame is pressed. The 2 forms behind are not encoded. Also happend something like this, if you insert a new (for example) logger in a context and save the changes in the frame. Then the answer from the action is ok but (I think) parts from the script script language=JavaScript !-- parent.tree.location='treeControlTest.do'; -- /script works without urlencode and the frame tree lost the session. regards Dietmar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] make mod_jk2 default port configurable
Hi all,
I've the problem that 8009 is already used on NetWare, so it would be nice if I could
default to another port for that platform; I looked at the sources, and it looks if
someone had already such an idea, but didnt finish
found some defines in ./native2/common/jk_worker_ajp13.c which I moved to jk_global.h,
then I replaced every 8009 with AJP13_DEF_PORT, and while on that I also replaced
127.0.0.1 with AJP13_DEF_HOST ...
complete patch can be found here (the list still removes my attachments):
http://www.gknw.com/test/native2_default_port.diff
Guenter.
=
--- ./native2/include/jk_global.h.orig Thu Nov 20 06:15:00 2003
+++ ./native2/include/jk_global.h Thu Jan 29 02:45:42 2004
@@ -128,6 +128,16 @@
#define JK_VERSION JK_MAKEVERSION(JK_VERMAJOR, JK_VERMINOR, JK_VERFIX, JK_VERBETA)
+#define AJP_DEF_RETRY_ATTEMPTS(2)
+#define AJP13_PROTO 13
+
+#define AJP13_DEF_HOST 127.0.0.1
+#ifdef NETWARE
+#define AJP13_DEF_PORT 9009/* default to 9009 since 8009 is used by OS */
+#else
+#define AJP13_DEF_PORT 8009
+#endif
+
#ifdef WIN32
#include windows.h
#include winsock.h
=
--- ./native2/common/jk_channel_apr_socket.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_channel_apr_socket.cThu Jan 29 11:56:28 2004
@@ -70,8 +70,6 @@
#include jk_global.h
#include jk_registry.h
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_apr_private {
@@ -179,7 +177,7 @@
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -196,10 +194,10 @@
}
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_apr_resolve( env, socketInfo-host, socketInfo-port, socketInfo );
if( rc!= JK_OK ) {
=
--- ./native2/common/jk_channel_socket.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_channel_socket.cThu Jan 29 02:43:48 2004
@@ -94,8 +94,6 @@
#include apr_general.h
#endif
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_socket_private {
@@ -199,12 +197,12 @@
char *localName=ch-mbean-localName;
if( *localName=='\0' ) {
/* Empty local part */
-socketInfo-port=8009;
-if( socketInfo-host==NULL) socketInfo-host=DEFAULT_HOST;
+socketInfo-port=AJP13_DEF_PORT;
+if( socketInfo-host==NULL) socketInfo-host=AJP13_DEF_HOST;
} else {
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -224,11 +222,11 @@
/* error if port= 40009 ( for example */
/*
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
*/
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_socket_resolve( env, socketInfo-host, socketInfo-port,
socketInfo-addr );
if( rc!= JK_OK ) {
=
--- ./native2/common/jk_worker_ajp13.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_worker_ajp13.c Thu Jan 29 02:35:56 2004
@@ -75,12 +75,6 @@
#include jk_requtil.h
#include jk_registry.h
-#define AJP_DEF_RETRY_ATTEMPTS(2)
-#define AJP13_PROTO 13
-
-#define AJP13_DEF_HOST (localhost)
-#define AJP13_DEF_PORT (8009)
-
/* Impl */
static char *jk2_worker_ajp13_getAttributeInfo[]={ lb_factor, lb_value, debug,
channel, level,
route, routeRedirect,
errorState, graceful, groups, disabled,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
compile mod_jk/mod_jk2 with APR 1.0 - Take 3
Hi,
With APR 1.0 apr_sockaddr_port_get() was removed without replacement.
I believe that the patch below is the correct replacement to archive _same_ behaviour
as with apr_sockaddr_port_get() before, and I tested that it also works with APR 0.9.x
(Apache 2.0.48 tested);
and here's also a reference to the httpd-2.0 sources:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/proxy/proxy_ftp.c?r1=1.134r2=1.135
===
# patch for APR 1.0 compatiblity
#
--- jk_service_apache2.c.orig Tue Sep 30 18:16:14 2003
+++ jk_service_apache2.cWed Jan 21 17:43:14 2004
@@ -343,7 +343,6 @@
static int JK_METHOD jk2_init_ws_service(jk_env_t *env, jk_ws_service_t *s,
jk_worker_t *worker, void *serverObj)
{
-apr_port_t port;
char *ssl_temp = NULL;
jk_workerEnv_t *workerEnv;
request_rec *r=serverObj;
@@ -377,8 +376,7 @@
r-server-server_hostname);
/* get the real port (otherwise redirect failed) */
-apr_sockaddr_port_get(port,r-connection-local_addr);
-s-server_port = port;
+s-server_port = r-connection-local_addr-port;
s-server_software = (char *)ap_get_server_version();
===
--- mod_jk.c.orig Wed Nov 05 12:15:18 2003
+++ mod_jk.cTue Jan 27 22:46:30 2004
@@ -482,8 +482,6 @@
{
request_rec *r = private_data-r;
-apr_port_t port;
-
char *ssl_temp = NULL;
s-jvm_route= NULL;/* Used for sticky session routing */
@@ -518,8 +516,7 @@
s-server_name = (char *)ap_get_server_name(r);
/* get the real port (otherwise redirect failed) */
-apr_sockaddr_port_get(port,r-connection-local_addr);
-s-server_port = port;
+s-server_port = r-connection-local_addr-port;
/* XXX : à la jk2 ???*/
/* s-server_port = ap_get_server_port(r); */
===
patches available here (my attachments are replaced by the nice list trailer):
http://www.gknw.com/test/jk_service_apache2.c.diff
http://www.gknw.com/test/mod_jk.c.diff
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26519] New: - Broken filename endings at long filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26519. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26519 Broken filename endings at long filenames Summary: Broken filename endings at long filenames Product: Tomcat 5 Version: 5.0.18 Platform: HP OS/Version: HP-UX Status: NEW Severity: Minor Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Filenames seems to have been cutoff in jakarta-tomcat-5.0.18.tar.gz, e.g.: jakarta-tomcat-5.0.18/webapps/jsp-exmaples/WEB- INF/classes/compressionFilters/CompressionFilter.clas instead of CompressionFilter.class or CompressionFilterTestS instead of CompressionFilterTestServlet.class and a lot of files more. jakarta-tomcat-5.0.18.zip is OK! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26519] - Broken filename endings at long filenames
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26519. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26519 Broken filename endings at long filenames [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 12:41 --- You can't use HP-Unix tar executable. You need the GNU tar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26516] - Lost Session when SessionCookie is blocked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26516. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26516 Lost Session when SessionCookie is blocked [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 13:15 --- *** This bug has been marked as a duplicate of 25092 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebdavServlet.java - connection timeout
I have an issue to whereas after about 60 minutes Tomcat closes my connection on applications. The server.xml file states connectionTimeout=6, but doesn't appear to be affecting the time out. Therein, how do you prolong the timeout on Tomcat past the default time to say about 520 min. WebdavServlet.java file has a field /** * Default lock timeout value. */ private static final int DEFAULT_TIMEOUT = 3600; i think this value cannot be changed from outside (from conf files ... ) Am i right ? Any idea ? Regards Altug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
POST request containing application/x-www-form-urlencoded
Hi, I'm facing a problem with Tomcat 5 (I believe this also happens with older versions) that is described below. I have developed a servlet for receiving a POST request and processing the data on it and it works fine. Meanwhile, a client application is sending the following request: -[obtained from tcpdump: some private information was replaced]- POST /Notify?id=xpto HTTP/1.1. Host: 192.168.1.1. Pragma: no-cache. accept:text/css,application/vnd.wap.wmlscriptc,application/vnd.wap.wbxml, accept-charset:ISO-8859-1,UTF-8;Q=0.8,ISO-10646-UCS-2;Q=0.6,US-ASCII;Q=0.7,*;q=0.001. user-agent: Nokia3200/1.0 () Profile/MIDP-1.0 Configuration/CLDC-1.0. x-wap.tod-coded: Thu, 01 Jan 1970 00:00:00 GMT. opt: http://www.w3.org/1999/06/24-CCPPexchange; ; ns=13. 13-profile: http://nds1.nds.nokia.com/uaprof/N3200r100.xml;. accept-encoding:*;q=0.001. Accept: text/vnd.wap.wml. Accept: text/vnd.wap.wmlscript. Content-Length: 11. Content-Type: application/x-www-form-urlencoded. . 900 Success -- This servlet is working properly with several client application, however for this specific one, it doesn't work as I would like. What I notice: 1. It works when the content-type of request is something like */* 2. It *doesn't work* when the content-type of request is application/x-www-form-urlencoded (see example above). The servlet is getting the inputstream from the HttpServletRequest and reading data from it. When it works, I'm able to read the 900 Success message. With the example descrived above, there is no data (0 bytes) available from the inputstream. Therefore, I'm unable to read the message. Is this POST request a non-HTTP standard and therefore Tomcat is not giving such data information to the upper layer (servlet) ? How can I solve this ? Thanks in advance. Best regards, Nuno Carvalho - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.30 release vote
Remy Maucherat wrote: jean-frederic clere wrote: Remy Maucherat wrote: Amidst all this junk email ... ballot Release 4.1.30 as Stable: [ ] Yes [ ] No /ballot Could you wait until I have release common/daemon? Why ? 4.1.30 doesn't include commons-daemon. (4.1.x uses JavaService, and doesn't ship jsvc) Oops, only my packaging needs commons-daemon. 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]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
jfclere 2004/01/29 06:17:41
Modified:jk/native2/common jk_channel_apr_socket.c
jk_channel_socket.c jk_worker_ajp13.c
jk/native2/include jk_global.h
Log:
Arrange default values, add AJP13_DEF_PORT and AJP13_DEF_HOST.
Use 9009 on NETWARE because 8009 is already used on those systems.
Submitted by Guenter Knauf, eflash at gmx.net.
Revision ChangesPath
1.35 +3 -5
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
Index: jk_channel_apr_socket.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- jk_channel_apr_socket.c 30 Oct 2003 20:08:36 - 1.34
+++ jk_channel_apr_socket.c 29 Jan 2004 14:17:41 - 1.35
@@ -70,8 +70,6 @@
#include jk_global.h
#include jk_registry.h
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_apr_private {
@@ -179,7 +177,7 @@
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -196,10 +194,10 @@
}
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_apr_resolve( env, socketInfo-host, socketInfo-port, socketInfo
);
if( rc!= JK_OK ) {
1.61 +5 -7 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
Index: jk_channel_socket.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- jk_channel_socket.c 30 Oct 2003 20:25:38 - 1.60
+++ jk_channel_socket.c 29 Jan 2004 14:17:41 - 1.61
@@ -94,8 +94,6 @@
#include apr_general.h
#endif
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_socket_private {
@@ -199,12 +197,12 @@
char *localName=ch-mbean-localName;
if( *localName=='\0' ) {
/* Empty local part */
-socketInfo-port=8009;
-if( socketInfo-host==NULL) socketInfo-host=DEFAULT_HOST;
+socketInfo-port=AJP13_DEF_PORT;
+if( socketInfo-host==NULL) socketInfo-host=AJP13_DEF_HOST;
} else {
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -224,11 +222,11 @@
/* error if port= 40009 ( for example */
/*
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
*/
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_socket_resolve( env, socketInfo-host, socketInfo-port,
socketInfo-addr );
if( rc!= JK_OK ) {
1.53 +0 -6 jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c
Index: jk_worker_ajp13.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- jk_worker_ajp13.c 30 Oct 2003 20:08:36 - 1.52
+++ jk_worker_ajp13.c 29 Jan 2004 14:17:41 - 1.53
@@ -75,12 +75,6 @@
#include jk_requtil.h
#include jk_registry.h
-#define AJP_DEF_RETRY_ATTEMPTS(2)
-#define AJP13_PROTO 13
-
-#define AJP13_DEF_HOST (localhost)
-#define AJP13_DEF_PORT (8009)
-
/* Impl */
static char *jk2_worker_ajp13_getAttributeInfo[]={ lb_factor, lb_value,
debug, channel, level,
route, routeRedirect,
errorState, graceful, groups, disabled,
1.21 +11 -1 jakarta-tomcat-connectors/jk/native2/include/jk_global.h
Index: jk_global.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v
retrieving revision 1.20
retrieving revision 1.21
diff -u
DO NOT REPLY [Bug 25805] - DataSourceRealm cannot find the JNDI DataSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805 DataSourceRealm cannot find the JNDI DataSource [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 14:01 --- Neil Katin provided a clean patch for this, so this has been implemented using a simple flag on the realm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] make mod_jk2 default port configurable
Günter Knauf wrote:
Hi all,
I've the problem that 8009 is already used on NetWare, so it would be nice if I could
default to another port for that platform; I looked at the sources, and it looks if
someone had already such an idea, but didnt finish
found some defines in ./native2/common/jk_worker_ajp13.c which I moved to jk_global.h, then I
replaced every 8009 with AJP13_DEF_PORT, and while on that I also replaced 127.0.0.1
with AJP13_DEF_HOST ...
complete patch can be found here (the list still removes my attachments):
http://www.gknw.com/test/native2_default_port.diff
Committed thanks.
Guenter.
=
--- ./native2/include/jk_global.h.orig Thu Nov 20 06:15:00 2003
+++ ./native2/include/jk_global.h Thu Jan 29 02:45:42 2004
@@ -128,6 +128,16 @@
#define JK_VERSION JK_MAKEVERSION(JK_VERMAJOR, JK_VERMINOR, JK_VERFIX, JK_VERBETA)
+#define AJP_DEF_RETRY_ATTEMPTS(2)
+#define AJP13_PROTO 13
+
+#define AJP13_DEF_HOST 127.0.0.1
+#ifdef NETWARE
+#define AJP13_DEF_PORT 9009/* default to 9009 since 8009 is used by OS */
+#else
+#define AJP13_DEF_PORT 8009
+#endif
+
#ifdef WIN32
#include windows.h
#include winsock.h
=
--- ./native2/common/jk_channel_apr_socket.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_channel_apr_socket.c Thu Jan 29 11:56:28 2004
@@ -70,8 +70,6 @@
#include jk_global.h
#include jk_registry.h
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_apr_private {
@@ -179,7 +177,7 @@
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -196,10 +194,10 @@
}
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_apr_resolve( env, socketInfo-host, socketInfo-port, socketInfo );
if( rc!= JK_OK ) {
=
--- ./native2/common/jk_channel_socket.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_channel_socket.c Thu Jan 29 02:43:48 2004
@@ -94,8 +94,6 @@
#include apr_general.h
#endif
-#define DEFAULT_HOST 127.0.0.1
-
/** Information specific for the socket channel
*/
struct jk_channel_socket_private {
@@ -199,12 +197,12 @@
char *localName=ch-mbean-localName;
if( *localName=='\0' ) {
/* Empty local part */
-socketInfo-port=8009;
-if( socketInfo-host==NULL) socketInfo-host=DEFAULT_HOST;
+socketInfo-port=AJP13_DEF_PORT;
+if( socketInfo-host==NULL) socketInfo-host=AJP13_DEF_HOST;
} else {
char *portIdx=strchr( localName, ':' );
if( portIdx==NULL || portIdx[1]=='\0' ) {
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
} else {
portIdx++;
socketInfo-port=atoi( portIdx );
@@ -224,11 +222,11 @@
/* error if port= 40009 ( for example */
/*
if( socketInfo-port=0 )
-socketInfo-port=8009;
+socketInfo-port=AJP13_DEF_PORT;
*/
if( socketInfo-host==NULL )
-socketInfo-host=DEFAULT_HOST;
+socketInfo-host=AJP13_DEF_HOST;
rc=jk2_channel_socket_resolve( env, socketInfo-host, socketInfo-port, socketInfo-addr );
if( rc!= JK_OK ) {
=
--- ./native2/common/jk_worker_ajp13.c.orig Fri Oct 31 00:15:04 2003
+++ ./native2/common/jk_worker_ajp13.c Thu Jan 29 02:35:56 2004
@@ -75,12 +75,6 @@
#include jk_requtil.h
#include jk_registry.h
-#define AJP_DEF_RETRY_ATTEMPTS(2)
-#define AJP13_PROTO 13
-
-#define AJP13_DEF_HOST (localhost)
-#define AJP13_DEF_PORT (8009)
-
/* Impl */
static char *jk2_worker_ajp13_getAttributeInfo[]={ lb_factor, lb_value, debug, channel, level,
route, routeRedirect, errorState, graceful, groups, disabled,
-
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]
DO NOT REPLY [Bug 26509] - DataSourceRealm for local contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509 DataSourceRealm for local contexts --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 15:00 --- It isn't a bug -- its an enhancement, with a specific suggestion for how to accomodate both needs. Doesn't that at least deserve some consideration? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25805] - DataSourceRealm cannot find the JNDI DataSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25805 DataSourceRealm cannot find the JNDI DataSource [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 14:00 --- . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25092] - Bug with cookies=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092 Bug with cookies=false [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 13:15 --- *** Bug 26516 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26513] - Tomcat NT service creates StdOutputFile/StdErrorFile empty files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513 Tomcat NT service creates StdOutputFile/StdErrorFile empty files [EMAIL PROTECTED] changed: What|Removed |Added Component|Unknown |Daemon Product|Tomcat 5|Commons Version|5.0.18 |Nightly Builds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26509] - DataSourceRealm for local contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26509 DataSourceRealm for local contexts --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 15:05 --- Sorry for the last comment; I hadn't read all my mail to see that the patch was accepted... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26236] - JAASRealm and GenericPrincipal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26236 JAASRealm and GenericPrincipal [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 15:15 --- Well... I've tried to reproduce the bug... I've created my own LoginModule, and two classes wich implements de java.security.Principal interface (one for the user principal and other to the roles principals) just like the bug description said, and it worked fine! I also couldn't figure out how the method hasRole() in the RealmBase class can be related to this problem because the method createPrincipal() (which is called by the authenticate() method in the JAASRealm class) creates a GenericPrincipal, as expected by the hasRole() method. I think the problem can be related to the LoginModule of your application, maybe it's not returning any RolePrincipal or something like that. I'll change the bug status to INVALID, if you got any new information, you can reopen it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26492] - Strange Session id behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26492 Strange Session id behavior --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 14:18 --- Thanks Remy for your reply's to this bug if is a bug in TomCat. As I understand from your reply's there are some fix to this problem. Is the fix in the nightly build ore ca I get it by other ways? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26523] New: - StandardEngine make two init() calls at sub Mbeans
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26523.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26523
StandardEngine make two init() calls at sub Mbeans
Summary: StandardEngine make two init() calls at sub Mbeans
Product: Tomcat 5
Version: 5.0.18
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I look deep at source to start a StandardEngine with a conf/tomcat5-mbeans.xml.
This feature to integrate easy some service JMX Mbeans is cool.
After some time I see that init() is call twice.
first call is at: StandardEngine L595 readEngineMbeans()
Registry.getRegistry(null, null).registerComponent
(mbeansMB, domain + :type=MbeansFile, null);
mbeansMB.load();
L595:mbeansMB.init();
mbeansMB.setRegistry(Registry.getRegistry(null, null));
-- please change to
Registry.getRegistry(null, null).registerComponent
(mbeansMB, domain + :type=MbeansFile, null);
mbeansMB.load();
mbeansMB.setRegistry(Registry.getRegistry(null, null));
second call is at 424 init()
if( mbeans != null ) {
try {
Registry.getRegistry(null, null).invoke(mbeans, init, false);
} catch (Exception e) {
log.error(Error in init() for + mbeansFile, e);
}
}
Also see my commons-modeler feature enhancement (MbeansSource):
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26493
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/dsapi config.h jk_dsapi_plugin.c
andya 2004/01/29 07:43:24
Modified:jk/native2/server/dsapi config.h jk_dsapi_plugin.c
Log:
Fixed a bug in path decoding which caused problems with parameters that contained
encoded forward slashes.
Made error reporting slightly more diagnostic.
Revision ChangesPath
1.3 +2 -5 jakarta-tomcat-connectors/jk/native2/server/dsapi/config.h
Index: config.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/dsapi/config.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- config.h 14 Nov 2003 13:08:05 - 1.2
+++ config.h 29 Jan 2004 15:43:24 - 1.3
@@ -64,9 +64,6 @@
#ifndef __config_h
#define __config_h
-#define MAKEVERSION(a, b, c, d) \
- (((a) 24) + ((b) 16) + ((c) 8) + (d))
-
#define NONBLANK(s) \
(NULL != (s) '\0' != *(s))
@@ -118,7 +115,7 @@
#define TOMCAT_START_TAG tomcatStart
#define TOMCAT_STOP_TAG tomcatStop
#define TOMCAT_TIMEOUT_TAG tomcatTimeout
-#define VERSION 2.0.0
+#define VERSION 2.0.1
#define VERSION_STRING Jakarta/DSAPI/ VERSION
#define FILTERDESC Apache Tomcat Interceptor ( VERSION_STRING
)
#define SERVERDFLT Lotus Domino
1.3 +25 -10
jakarta-tomcat-connectors/jk/native2/server/dsapi/jk_dsapi_plugin.c
Index: jk_dsapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/dsapi/jk_dsapi_plugin.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_dsapi_plugin.c 14 Nov 2003 13:08:05 - 1.2
+++ jk_dsapi_plugin.c 29 Jan 2004 15:43:24 - 1.3
@@ -682,10 +682,24 @@
/* Called to generate a generic error response.
*/
-static unsigned int rejectWithError(FilterContext *context) {
- static char *msg = htmlbodyh1Error in Filter/h1/body/html;
+static unsigned int rejectWithError(FilterContext *context, const char *diagnostic)
{
+ static char *msg = htmlbodyh1Error in
Filter/h1p%s/p/body/html;
+ char *mbuf;
+ int errID;
+ size_t bufSz;
- simpleResponse(context, 500, Error in Filter, msg);
+ if (!NONBLANK(diagnostic)) {
+ diagnostic = Unspecified error;
+ }
+
+ // This assumes that we're just going to expand the diagnostic into
+ // the page body.
+ bufSz = strlen(msg) + strlen(diagnostic) + 1;
+
+ mbuf = context-AllocMem(context, bufSz, 0, errID);
+ sprintf(mbuf, msg, diagnostic);
+
+ simpleResponse(context, 500, Error in Filter, mbuf);
return kFilterHandledRequest;
}
@@ -901,13 +915,13 @@
/* env-l-jkLog(env, env-l, JK_LOG_DEBUG, parsedRequest() - %s\n,
uri); */
if (!context-GetServerVariable(context, SERVER_PORT, buf,
sizeof(buf), errID)) {
- return rejectWithError(context);
+ return rejectWithError(context, Failed to retrieve
SERVER_PORT);
}
serverPort = atoi(buf);
if (!context-GetServerVariable(context, SERVER_NAME, buf,
sizeof(buf), errID)) {
- return rejectWithError(context);
+ return rejectWithError(context, Failed to retrieve
SERVER_NAME);
}
serverName = buf; /* note serverName just aliases buf
@@ -927,16 +941,17 @@
turi = context-AllocMem(context, uriSz, 0, errID);
}
memcpy(turi, uri, uriSz);
+
+if (qp = strchr(turi, '?'), qp != NULL) {
+ *qp++ = '\0';
+ }
rc = jk_requtil_unescapeUrl(turi);
if (rc 0) {
- return rejectWithError(context);
+ return rejectWithError(context, Failed to unescape URI);
}
jk_requtil_getParents(turi);
-if (qp = strchr(turi, '?'), qp != NULL) {
- *qp++ = '\0';
- }
if (badURI(turi)) {
return rejectBadURI(context);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26524] New: - ZipException/UnknownHostException using absolute directory path in war attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26524.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26524
ZipException/UnknownHostException using absolute directory path in war attribute
Summary: ZipException/UnknownHostException using absolute
directory path in war attribute
Product: Tomcat 5
Version: 5.0.18
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Formally the InstallTask allowed absolute paths to a war like directory
structure. InstallTask is deprecated with DeployTask, but using a absolute file
construct like file://drive:\path\to\dir throws a UnknownHostException.
Using a construct like file:drive:\path\to\dir throws a ZipException.
The deploytask works with a war file.
Config:
Ant v1.6
Tomcat v5.18
Build.xml:
property name=manager.url
value=http://localhost:8080/manager/
property name=manager.username value=/
property name=manager.password value=/
taskdef name=deploy classname=org.apache.catalina.ant.DeployTask/
target name=deploy depends=compile
description=Deploy the application to servlet container
deploy url=${manager.url}
username=${manager.username}
password=${manager.password}
path=${app.path}
war=file://${build.home}/
/target
deploy:
[deploy] BUILD FAILED: file:D:/softdev/eclipse-SDK-2.1.2-
win32/eclipse/workspace/Vikie-V0.2/edi/build.xml:212:
java.net.UnknownHostException: D
Total time: 9 seconds
When I use InstallTask everything works fine.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26524] - ZipException/UnknownHostException using absolute directory path in war attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26524. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26524 ZipException/UnknownHostException using absolute directory path in war attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 16:10 --- Please look at the documentation (or examples). There's also tomcat-user when in doubt. The war attribute points to a war file, and the localWar may point to a server local war or expanded directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Collections 3.0?
Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/dsapi config.h jk_dsapi_plugin.c
andya 2004/01/29 08:23:50
Modified:jk/native2/server/dsapi config.h jk_dsapi_plugin.c
Log:
Changed error handling in the event that a URI can not be unescaped. Now returns an
access denied message if a URI that can not be decoded is found.
Revision ChangesPath
1.4 +2 -2 jakarta-tomcat-connectors/jk/native2/server/dsapi/config.h
Index: config.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/dsapi/config.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- config.h 29 Jan 2004 15:43:24 - 1.3
+++ config.h 29 Jan 2004 16:23:49 - 1.4
@@ -115,7 +115,7 @@
#define TOMCAT_START_TAG tomcatStart
#define TOMCAT_STOP_TAG tomcatStop
#define TOMCAT_TIMEOUT_TAG tomcatTimeout
-#define VERSION 2.0.1
+#define VERSION 2.0.2
#define VERSION_STRING Jakarta/DSAPI/ VERSION
#define FILTERDESC Apache Tomcat Interceptor ( VERSION_STRING
)
#define SERVERDFLT Lotus Domino
1.4 +2 -2
jakarta-tomcat-connectors/jk/native2/server/dsapi/jk_dsapi_plugin.c
Index: jk_dsapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/dsapi/jk_dsapi_plugin.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_dsapi_plugin.c 29 Jan 2004 15:43:24 - 1.3
+++ jk_dsapi_plugin.c 29 Jan 2004 16:23:50 - 1.4
@@ -948,7 +948,7 @@
rc = jk_requtil_unescapeUrl(turi);
if (rc 0) {
- return rejectWithError(context, Failed to unescape URI);
+ return rejectBadURI(context);
}
jk_requtil_getParents(turi);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26513] - Tomcat NT service creates StdOutputFile/StdErrorFile empty files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26513 Tomcat NT service creates StdOutputFile/StdErrorFile empty files [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 16:28 --- I must state clearly that I downloaded and installed the .zip distribution, trying to adapt the previously installed version's configuration. Further investigations led me to a working configuration: 1. You have to unistall previously installed versions of the Tomcat service; failure to do this, keeps unwanted references to the old version in the system registry; 2. the file bin/service.bat from the .zip distribution fails to add the --Argument parameter that apparently the .exe distribution correctly adds to the system registry with the value of 'java'; 3. you have to be sure that the --Java parameter has the value 'java': I unconsciously left a Tomcat 4.1.x-suitable value for this parameter. My apologies for this. Again, an installation from the .exe file seems to be the best practice in order to obtain a working configuration. Nevertheless, my feeling is that the logging mechanism is a bit weak. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Collections 3.0?
Jess Holle wrote: Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? It would have been better if either: - 3.0 was backwards compatible with 2.0 :) - it was using different package names Note that you should be able to override and use collections 2.1 inside a webapp even if collections 3.0 is in common/lib, and hopefully it'll work. If it doesn't, there will be a huge mess, and lots of hate mail ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Collections 3.0?
Remy Maucherat wrote: Jess Holle wrote: Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? It would have been better if either: - 3.0 was backwards compatible with 2.0 :) - it was using different package names Note that you should be able to override and use collections 2.1 inside a webapp even if collections 3.0 is in common/lib, and hopefully it'll work. If it doesn't, there will be a huge mess, and lots of hate mail ;) Or vice versa presumably? If this *should* work, then I can give it a wing, though I've not really sanity checked 3.0 myself -- as we use 2.1 very little and my immediate concern was Tomcat compatibility. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Collections 3.0?
Howdy, You know, tomcat only uses one class (LRUMap), whose implementation wasn't really changed in the 3.0 release, only the package name. So this is a trivial patch... Yoav Shapira Millennium ChemInformatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 11:35 AM To: Tomcat Developers List Subject: Re: Jakarta Collections 3.0? Remy Maucherat wrote: Jess Holle wrote: Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? It would have been better if either: - 3.0 was backwards compatible with 2.0 :) - it was using different package names Note that you should be able to override and use collections 2.1 inside a webapp even if collections 3.0 is in common/lib, and hopefully it'll work. If it doesn't, there will be a huge mess, and lots of hate mail ;) Or vice versa presumably? If this *should* work, then I can give it a wing, though I've not really sanity checked 3.0 myself -- as we use 2.1 very little and my immediate concern was Tomcat compatibility. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: Jakarta Collections 3.0?
Shapira, Yoav wrote: Howdy, You know, tomcat only uses one class (LRUMap), whose implementation wasn't really changed in the 3.0 release, only the package name. So this is a trivial patch... Well, digester and beanutils use more of collections, so it's more complex that that :/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Collections 3.0?
Howdy, We'd probably move with the next point release if it's not a major headache. I don't expect it to be a major headache, just class name changes, and I don't mind moving the relevant tomcat code myself. As to when, the answer is as always the release will be ready when it's ready ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 11:19 AM To: Tomcat Developers List Subject: Jakarta Collections 3.0? Can anyone shed any light on the plans for Tomcat using Jakarta Collections 3.0? I ask as we currently bundle Jakarta Collections for use in and out of the servlet engine. We wish to use a consistent version throughout. Given that Tomcat bundles Jakarta Collections within its common/lib area, we effectively use whatever Tomcat uses while in the servlet engine in any case. We're therefore at Collections 2.1 as Tomcat is. Are there plans to move Tomcat to Jakarta Collections 3.0? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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]
DO NOT REPLY [Bug 26527] New: - Tag Pooling broken?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26527 Tag Pooling broken? Summary: Tag Pooling broken? Product: Tomcat 4 Version: 4.1.27 Platform: All URL: http://otn.oracle.com/products/jdev/htdocs/readme_9031.h tml#juan OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] According to Oracle the tag pooling is broken in Tomcat. I'm not sure tag pooling broken or are the BC4J tags from oracle broken. Url to oracle statement: http://otn.oracle.com/products/jdev/htdocs/readme_9031.html#juan Oracle states that the tag pool should call the release method either before the tag is put into the pool or after it is taken out of the pool and before it is used in the jsp page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Collections 3.0?
Howdy, Well, digester and beanutils use more of collections, so it's more complex that that :/ I'll take a deeper look to see what's involved ;) Yoav Shapira 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]
cvs commit: jakarta-tomcat-catalina/webapps/docs realm-howto.xml
remm2004/01/29 09:27:09 Modified:webapps/docs realm-howto.xml Log: - Document the new useLocalDataSource flag. Revision ChangesPath 1.12 +7 -0 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- realm-howto.xml 8 Jan 2004 13:22:51 - 1.11 +++ realm-howto.xml 29 Jan 2004 17:27:09 - 1.12 @@ -429,6 +429,13 @@ information. If not specified, passwords are stored in clear text./p /attribute + attribute name=localDataSource required=false +pWhen the realm is nested inside a Context element, this allows the +realm to use a DataSource defined for the Context rather than a global +DataSource. If not specified, the default is codefalse/code: use a +global DataSource./p + /attribute + attribute name=roleNameCol required=true pThe name of the column, in the emuser roles/em table, that contains the name of a role assigned to this user./p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.30 release vote
Remy Maucherat wrote: Amidst all this junk email ... ballot Release 4.1.30 as Stable: [X] Yes [ ] No /ballot We need this release ;) I promise I won't annoy anyone with 4.1.x after this one :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22087] - ISAPI Redirector does not function under IIS V6.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22087. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22087 ISAPI Redirector does not function under IIS V6.0 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26529] New: - ISAPI redirector with SSL and tomcat 4.29
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26529. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26529 ISAPI redirector with SSL and tomcat 4.29 Summary: ISAPI redirector with SSL and tomcat 4.29 Product: Tomcat 4 Version: 4.1.29 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm running Windows 2000 Advance Server with Tomcat 4.29 and IIS 5 I have the ISAPI redirector installed and working with IIS Tomcat on HTTP http://localhost/MySite/HomePage.jsp I installed a server certificate and enables SSL on port 443 in IIS I'm able to view 'static' objects (like html pages images) via SSL https://localhost/MySite/index.html While any non SSL URL (still static objects) will not be served by IIS and the user will see the 'standard' IIS error: HTTP 403.4 - Forbidden: SSL required http://localhost/MySite/index.html The problem is when I try to view any JSP/Servlet the browser wants to 'save' the page to the local drive. http://localhost/MySite/HomePage.jsp In other words the JSP is not served as HTML to the browser and the browser does not know what to do with the file except save it. I set the ISAPI error reporting to DEBUG and it looks like it the redirector just 'stops' and does not forward the request correctly. * So the questions is: How to I get the ISAPI redirector to work with SSL? Connecting IIS (on port 80) to Tomcat with SSL enabled on every URL and so http urls will be redirected to https * There are no erros in my tomcat logs. Here is my ISAPI log file of trying to serve a JSP page: [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1018)]: Using registry. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1020)]: Using log file C:\\Program Files\\Apache Group\\Tomcat 4.1\\iis\\iis_redirect.txt. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1021)]: Using log level 0. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1022)]: Using extension uri /jakarta/isapi_redirector.dll. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1023)]: Using worker file C:\\Program Files\\Apache Group\\Tomcat 4.1\\conf\\workers.properties. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1024)]: Using worker mount file C:\\Program Files\\Apache Group\\Tomcat 4.1\\conf\\uriworkermap.properties. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1025)]: Using uri select 0. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1041)]: Ignoring worker mount file entry default.worker=ajp13. [Thu Jan 29 13:18:16 2004] [jk_isapi_plugin.c (1041)]: Ignoring worker mount file entry j_security_check=ajp13. [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (172)]: Into jk_uri_worker_map_t::uri_worker_map_alloc [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (375)]: Into jk_uri_worker_map_t::uri_worker_map_open [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (396)]: jk_uri_worker_map_t::uri_worker_map_open, rule map size is 5 [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (299)]: Into jk_uri_worker_map_t::uri_worker_map_open, suffix rule /.jsp=ajp13 was added [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (321)]: Into jk_uri_worker_map_t::uri_worker_map_open, match rule /MySite/Servlets/=ajp13 was added [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (299)]: Into jk_uri_worker_map_t::uri_worker_map_open, suffix rule /MySite/.jsp=ajp13 was added [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (299)]: Into jk_uri_worker_map_t::uri_worker_map_open, suffix rule /MySite/.do=ajp13 was added [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (345)]: Into jk_uri_worker_map_t::uri_worker_map_open, exact rule /MySite/AdminFunctions/j_security_check=ajp13 was added [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (408)]: Into jk_uri_worker_map_t::uri_worker_map_open, there are 5 rules [Thu Jan 29 13:18:16 2004] [jk_uri_worker_map.c (422)]: jk_uri_worker_map_t::uri_worker_map_open, done [Thu Jan 29 13:18:16 2004] [jk_worker.c (88)]: Into wc_open [Thu Jan 29 13:18:16 2004] [jk_worker.c (224)]: Into build_worker_map, creating 1 workers [Thu Jan 29 13:18:16 2004] [jk_worker.c (230)]: build_worker_map, creating worker ajp13 [Thu Jan 29 13:18:16 2004] [jk_worker.c (148)]: Into wc_create_worker [Thu Jan 29 13:18:16 2004] [jk_worker.c (260)]: Factory :ajp12 [Thu Jan 29 13:18:16 2004] [jk_worker.c (260)]: Factory :ajp13 [Thu Jan 29 13:18:16 2004] [jk_worker.c (164)]: wc_create_worker, about to create instance ajp13 of ajp13 [Thu Jan 29 13:18:16 2004] [jk_ajp13_worker.c (108)]: Into ajp13_worker_factory [Thu Jan 29 13:18:16 2004] [jk_worker.c (173)]: wc_create_worker, about to validate and
DO NOT REPLY [Bug 16001] - Tag.release() not invoked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001 Tag.release() not invoked [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 16:53 --- *** Bug 26527 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26451] - URL.openConnection() returns sun class with JDK 1.4.2_03
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451 URL.openConnection() returns sun class with JDK 1.4.2_03 --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 17:01 --- True, and that's good, but my point is that Sun says all com.sun.net classes are going byebye. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Design Question in TomCat 5
Hi, I read an onjava.com article regarding new features in Tomcat 5. In that article, it said a whole new mapper was implemented that generates little or no garbage (lots of object recycling is going on in there). And that improves performance. But from Sun's web page, it said do not pool objects. So my question is Is it a good idea to do object pooling for the sake of performance improvement? Thank you. From onjava.com article, http://www.onjava.com/pub/a/onjava/2004/01/28/tomcat5.html?page=1 Tomcat 5.0 has had many garbage creation (read performance enhancement) changes since Tomcat 4.1. Tomcat 5.0's single most important garbage-creation refactoring was the new request URI mapper. After some optimization profiling, Tomcat 4.1's request pipeline was found to create excess garbage while mapping a Connector's requests to the proper Container. For Tomcat 5, a whole new mapper was implemented that generates little or no garbage (lots of object recycling is going on in there), and thus Tomcat 5.0's request pipeline performs noticeably better than that of Tomcat 4.1. This also lowers the overall memory usage compared to Tomcat 4.1, which helps to prevent OutOfMemoryExceptions in the web apps it runs, and helps Tomcat 5 to scale higher vertically (i.e. higher scalability on a single machine). From http://java.sun.com/docs/hotspot/gc1.4.2/faq.html 31. Should I pool objects to help GC? Should I call System.gc() periodically? The answer to these is No! Pooling objects will cause them to live longer than necessary. We strongly advise against object pools.
DO NOT REPLY [Bug 26451] - URL.openConnection() returns sun class with JDK 1.4.2_03
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451 URL.openConnection() returns sun class with JDK 1.4.2_03 --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 19:07 --- The point is: The official (abstract) class for https connections is javax.net.ssl.HttpsURLConnection. That's what you're supposed to use in *your* code and that's gonna work, be it in a Sun, IBM or BEA VM. What *concrete* implementation class a call to new URL(https:...).openConnection () returns is not your business. It will be some subclass of javax.net... It's in the J2SE's discretion to return any class it likes. It's like you're complaining that servlet contexts are instance of org.apache...StandardContext. But Sun says its a javax.servlet.ServletContext... Welcome to OO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design Question in TomCat 5
Howdy, But from Sun's web page, it said do not pool objects. So my question is Is it a good idea to do object pooling for the sake of performance improvement? Do not pool objects is an overly general tip. If objects are expensive to create, pooling them is a classical way to enhance performance of a system. Yoav Shapira 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]
[Gump@dotnot.org]: jakarta-tomcat-5/jakarta-tomcat-5 failed
Project: jakarta-tomcat-5 State: Failed URL: http://gump.dotnot.org/jakarta-tomcat-5/jakarta-tomcat-5.html RSS: http://gump.dotnot.org/jakarta-tomcat-5/jakarta-tomcat-5.rss Atom: http://gump.dotnot.org/jakarta-tomcat-5/jakarta-tomcat-5.atom - G U M P Y Annotations: - Error - Failed with reason build failed - G U M P Y Work Type: Build State: Failed Elapsed: 0 hours, 0 minutes, 5 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/var/gump/xml-xerces2/java/build/xercesImpl.jar:/var/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/var/gump/xml-xalan/java/build/xalan-unbundled.jar:/var/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/home/gump/jakarta-gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/var/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djndi.jar=/var/gump/opt/jndi1_2_1/lib/jndi.jar -Dcommons-launcher.jar=/var/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar -Dcommons-collections.jar=/var/gump/jakarta-commons/collections/build/commons-collections-20040129.jar -Djmx.jar=/var/gump/opt/jmx-1_2-ri/lib/jmxri.jar -Dactivation.home=/var/gump/opt/jaf-1.0.1 -Djmx.home=/var/gump/opt/jmx-1_2-ri -Dcommons-modeler.home=/var/gump/jakarta-tomcat-5/modeler -Djmx-tools.jar=/var/gump/opt/jmx-1_2-ri/lib/jmxtools.jar -Dregexp.jar=/var/gump/jakarta-regexp/build/jakarta-regexp-20040129.jar -Djasper.home=/var/gump/jakarta-tomcat-jasper_tc5/jasper2 -Dant.home=/var/gump/ant/dist -DxmlParserAPIs.jar=/var/gump/xml-xerces2/java/build/xercesImpl.jar -Djdbc20ext.jar=/var/gump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dsite2.home=/var/gump/jakarta-site2 -Dcommons-daemon.jsvc.tar.gz=/var/gump/jakarta-tomcat-5/daemon/dist/bin/jsvc.tar.gz -Dldap.jar=/var/gump/opt/ldap-1_2_4/lib/ldap.jar -Dregexp.home=/var/gump/jakarta-regexp/build -Dcommons-beanutils.jar=/var/gump/jakarta-commons/beanutils/dist/commons-beanutils.jar -DxercesImpl.jar=/var/gump/xml-xerces2/java/build/xercesImpl.jar -Djsse.home=/var/gump/opt/jsse1.0.3 -Dcommons-pool.jar=/var/gump/jakarta-commons/pool/dist/commons-pool.jar -Dmail.home=/var/gump/opt/javamail-1.3 -Djndi.home=/var/gump/opt/jndi1_2_1 -Djaas.jar=/var/gump/opt/jaas1_0/lib/jaas.jar -Dtomcat-coyote.home=/var/gump/jakarta-tomcat-connectors/coyote -Dcommons-daemon.jar=/var/gump/jakarta-commons/daemon/dist/commons-daemon-20040129.jar -Dcommons-dbcp.jar=/var/gump/jakarta-commons/dbcp/dist/commons-dbcp.jar -Dtomcat-util.jar=/var/gump/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar -Dservlet-api.jar=/var/gump/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar -Dcommons-logging-api.jar=/var/gump/jakarta-commons/logging/dist/commons-logging-api.jar -Dcommons-fileupload.jar=/var/gump/jakarta-commons/fileupload/target/commons-fileupload-20040129.jar -Dcommons-modeler.jar=/var/gump/jakarta-commons/modeler/dist/commons-modeler.jar -Dcommons-logging.jar=/var/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons-el.jar=/var/gump/jakarta-commons/el/dist/commons-el.jar -Dcommons-digester.jar=/var/gump/jakarta-commons/digester/dist/commons-digester.jar -Dmail.jar=/var/gump/opt/javamail-1.3/mail.jar -Djta.jar=/var/gump/opt/jta-spec1_0_1/jta-spec1_0_1.jar -Dactivation.jar=/var/gump/opt/jaf-1.0.1/activation.jar 'prepare-release dist dist-source installer package-zip package-tgz package-src-zip package-src-tgz' CWD: /var/gump/jakarta-tomcat-5 - Buildfile: build.xml BUILD FAILED Target `prepare-release dist dist-source installer package-zip package-tgz package-src-zip package-src-tgz' does not exist in this project. Total time: 2 seconds - -- Gump http://jakarta.apache.org/gump [nyx.stonecobra.com] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Question in TomCat 5
As Yoav said, pooling is a question of how expensive it is to create them. Also to add in there are many more factors to consider 1. how expensive is it to GC in a non pooled environment 2. how expensive is it to synchronize to keep your pool thread safe so it all becomes a question of the scenario that you have, it is not general Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 11:11 AM Subject: RE: Design Question in TomCat 5 Howdy, But from Sun's web page, it said do not pool objects. So my question is Is it a good idea to do object pooling for the sake of performance improvement? Do not pool objects is an overly general tip. If objects are expensive to create, pooling them is a classical way to enhance performance of a system. Yoav Shapira 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26449] - Webdav servlet will not open in IE web folder.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26449. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26449 Webdav servlet will not open in IE web folder. --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 19:58 --- After looking at this further (with some pointers from Tobias and Remy) it looks like that there are a combination of issues at play here and the root cause may be one (or many!) of the following: - The IE redirect bug (see above) affects NT and 2000. XP is meant to be fixed but I am _sure_ I have seen this on XP. - Interaction with the welcome file behaviour. Either use /* as the url pattern in the servlet mapping or specify a welcome file of welcome-file / I am going to change the url pattern in the servlet mapping in TC5 to /* to ensure this works out of the box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebDAV and TC5
All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebDAV and TC5
Howdy, Why do it now? I haven't seen demand for it on the user list... Yoav Shapira Millennium ChemInformatics -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 3:10 PM To: Tomcat-Dev Subject: WebDAV and TC5 All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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]
DO NOT REPLY [Bug 26527] - Tag Pooling broken?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26527 Tag Pooling broken? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 16:53 --- http://jakarta.apache.org/tomcat/faq/misc.html#tagbroken *** This bug has been marked as a duplicate of 16001 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebDAV and TC5
Please, PLEASE add it! There is no demand because MOST users do not know any compatible clients! Thank you - George From: Shapira, Yoav [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: RE: WebDAV and TC5 Date: Thu, 29 Jan 2004 15:18:02 -0500 MIME-Version: 1.0 Received: from mail.apache.org ([208.185.179.12]) by mc3-f11.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 29 Jan 2004 12:19:36 -0800 Received: (qmail 56464 invoked by uid 500); 29 Jan 2004 20:19:07 - Received: (qmail 56364 invoked from network); 29 Jan 2004 20:19:06 - Received: from unknown (HELO mustang.mpi.com) (63.244.250.132) by daedalus.apache.org with SMTP; 29 Jan 2004 20:19:06 - Received: from lightning.mpi.com (lightning [63.244.252.11])by mustang.mpi.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0TKG6V01057for [EMAIL PROTECTED]; Thu, 29 Jan 2004 15:16:06 -0500 (EST) Received: from US-VS1.corp.mpi.com (us-be1.corp.mpi.com [63.244.252.30])by lightning.mpi.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i0TKIlck015762for [EMAIL PROTECTED]; Thu, 29 Jan 2004 15:18:48 -0500 (EST) X-Message-Info: JGTYoYF78jFEd1q16rktfRNC+LSTALWW Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Delivered-To: mailing list [EMAIL PROTECTED] X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Message-ID: [EMAIL PROTECTED] X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WebDAV and TC5 Thread-Index: AcPmo+IP6ooA8E3jR/y7NEW5tAPPQAAARTzA X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 29 Jan 2004 20:19:36.0132 (UTC) FILETIME=[36E2A040:01C3E6A5] Howdy, Why do it now? I haven't seen demand for it on the user list... Yoav Shapira Millennium ChemInformatics -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 3:10 PM To: Tomcat-Dev Subject: WebDAV and TC5 All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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] _ Find high-speed net deals comparison-shop your local providers here. https://broadband.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDAV and TC5
+1 why not, if it is in T4, lets have it in T5 - Original Message - From: Mark Thomas [EMAIL PROTECTED] To: Tomcat-Dev [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 12:10 PM Subject: WebDAV and TC5 All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - 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: WebDAV and TC5
Howdy, I don't have a big objection. But we removed it from TC5 intentionally, not by accident. No one has been complaining, aside from the one user who just voice in a few minutes ago, so we should have a good argument for adding it back, no? Yoav Shapira Millennium ChemInformatics -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 4:14 PM To: Tomcat Developers List Subject: Re: WebDAV and TC5 +1 why not, if it is in T4, lets have it in T5 - Original Message - From: Mark Thomas [EMAIL PROTECTED] To: Tomcat-Dev [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 12:10 PM Subject: WebDAV and TC5 All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - 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] 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: WebDAV and TC5
I don't have a big objection. But we removed it from TC5 intentionally, ah I missed that, what was the argument for removing it? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: WebDAV and TC5
George MATKOVITS wrote: Please, PLEASE add it! There is no demand because MOST users do not know any compatible clients! Thank you - George WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Jess Holle wrote: WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. I absolutely disagree. Windows comes with two clients (an explorer extension and a filesystem driver), MacOSX comes with a drriver, and there's also a Linux FS. Many major applications (for instance Adobe or OpenOffice) support it as well. WebDAV is robust and interoperability is actually quite good. Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Julian Reschke wrote: Jess Holle wrote: WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. I absolutely disagree. Windows comes with two clients (an explorer extension and a filesystem driver), How does the user use the filesystem driver? The end-user certainly cannot achieve anything meaningful via web folders. I did a lot of testing in this regard. Now if there is a better level of usability/functionality achievable with Windows without significant additional client side programming, I'd love to hear more about it -- i.e. I'd love to discover I'm simply ignorant here and find a silver bullet for this issue! MacOSX comes with a drriver, and there's also a Linux FS. Agreed on these counts, but these are 10% of the market. Many major applications (for instance Adobe or OpenOffice) support it as well. WebDAV is robust and interoperability is actually quite good. OpenOffice is very small in terms of market share, though I certainly wish it all the best! Adobe is also fairly small in terms of market share. What is really necessary is an across-the-board file-system and desktop GUI level integration such that all applications on the OS get some level of functionality with WebDAV (including open and save as a minimum!) and those that are DAV-aware may get more. App-by-app DAV awareness is *much* less interesting as it is guaranteed to be inconsistent between apps and as a server-vendor one can't depend on it being present in the client apps. I've not seen any means to achieve this across-the-board functionality with Windows (and again, *please* prove me ignorant here). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Jess Holle wrote: How does the user use the filesystem driver? net use ... The end-user certainly cannot achieve anything meaningful via web folders. I did a lot of testing in this regard. Well, I disagree. Lots of my customers use webfolders heavily. Now if there is a better level of usability/functionality achievable with Windows without significant additional client side programming, I'd love to hear more about it -- i.e. I'd love to discover I'm simply ignorant here and find a silver bullet for this issue! Of course there isn't any silver bullet. But all clients I've seen are still better than non-programmatic access or FTP. OpenOffice is very small in terms of market share, though I certainly wish it all the best! Adobe is also fairly small in terms of market share. Oh well. Microsoft Office is not small in market share, and works very well with WebDAV. What is really necessary is an across-the-board file-system and desktop GUI level integration such that all applications on the OS get some level of functionality with WebDAV (including open and save as a minimum!) and those that are DAV-aware may get more. App-by-app DAV awareness is *much* less interesting as it is guaranteed to be inconsistent between apps and as a server-vendor one can't depend on it being present in the client apps. I've not seen any means to achieve this across-the-board functionality with Windows (and again, *please* prove me ignorant here). Well, use one of the many filesystem drivers (Xythos, Windows XP, ...). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
I don't think small market shares or lack of clients is a reason for exclude a server feature. They are separate. If the WebDAV app added some negative impact to the tomcat server, then take it out, but if not, then lets add it back in. Filip - Original Message - From: Julian Reschke [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 2:01 PM Subject: Re: [OT] Re: WebDAV and TC5 Jess Holle wrote: How does the user use the filesystem driver? net use ... The end-user certainly cannot achieve anything meaningful via web folders. I did a lot of testing in this regard. Well, I disagree. Lots of my customers use webfolders heavily. Now if there is a better level of usability/functionality achievable with Windows without significant additional client side programming, I'd love to hear more about it -- i.e. I'd love to discover I'm simply ignorant here and find a silver bullet for this issue! Of course there isn't any silver bullet. But all clients I've seen are still better than non-programmatic access or FTP. OpenOffice is very small in terms of market share, though I certainly wish it all the best! Adobe is also fairly small in terms of market share. Oh well. Microsoft Office is not small in market share, and works very well with WebDAV. What is really necessary is an across-the-board file-system and desktop GUI level integration such that all applications on the OS get some level of functionality with WebDAV (including open and save as a minimum!) and those that are DAV-aware may get more. App-by-app DAV awareness is *much* less interesting as it is guaranteed to be inconsistent between apps and as a server-vendor one can't depend on it being present in the client apps. I've not seen any means to achieve this across-the-board functionality with Windows (and again, *please* prove me ignorant here). Well, use one of the many filesystem drivers (Xythos, Windows XP, ...). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - 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: WebDAV and TC5
Mark Thomas wrote: All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. -0 (so I don't really mind). I just don't see any big benefits. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: WebDAV and TC5
Howdy, I don't think small market shares or lack of clients is a reason for exclude a server feature. They are separate. If the WebDAV app added some negative impact to the tomcat server, then take it out, but if not, then lets add it back in. Even if WebDAV is useful in the general sense (I tend to agree with Senor Holle that it's not, I don't feel strongly either way), I think it's telling that no one complained when we removed it. Anything we add that's not used is bloat by definition, and more for us to maintain. Of course, we already do have a WebDAV servlet shipping with tomcat5, and that's the main part. What else did you (Mark T.) think of adding to the distribution? This gets me thinking again of the idea of a minimal build: no webdav, no CGI, no examples, no docs, no balancer, minimal server.xml as the default, etc, so as to minimize download size and cater to those users who know what they're doing and just want to drop their webapp into tomcat. Yoav Shapira 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: [OT] Re: WebDAV and TC5
Shapira, Yoav wrote: Howdy, I don't think small market shares or lack of clients is a reason for exclude a server feature. They are separate. If the WebDAV app added some negative impact to the tomcat server, then take it out, but if not, then lets add it back in. Even if WebDAV is useful in the general sense (I tend to agree with Senor Holle that it's not, I don't feel strongly either way), I think it's telling that no one complained when we removed it. Anything we add that's not used is bloat by definition, and more for us to maintain. Of course, we already do have a WebDAV servlet shipping with tomcat5, and that's the main part. What else did you (Mark T.) think of adding to the distribution? This gets me thinking again of the idea of a minimal build: no webdav, no CGI, no examples, no docs, no balancer, minimal server.xml as the default, etc, so as to minimize download size and cater to those users who know what they're doing and just want to drop their webapp into tomcat. Jakarta could have a minimal Tomcat binary + a set of standard Jakarta add-on web-apps. Add a standard web app catalog viewer to Tomcat and you're set. Right? [At that point Tomcat would be kind of like what NetBeans tries to be in this regard, which is pretty nice -- all other aspects of NetBeans aside.] -- Jess Holle
DO NOT REPLY [Bug 25953] - Add ability for Realm authentication to tell the user the reason for auth failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25953 Add ability for Realm authentication to tell the user the reason for auth failure [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 22:29 --- The problem is that it doesn't worth the pain of changing the API just to make this feature possible, maybe when refactoring the realms API (I'm not saying it's gonna happen) it can be done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13497] - workDir parameter in server.xml context is ignored by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497 workDir parameter in server.xml context is ignored by Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 22:29 --- I have just tested this with the latest version of TC4 from CVS and this works correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Shapira, Yoav wrote: Howdy, I don't think small market shares or lack of clients is a reason for exclude a server feature. They are separate. If the WebDAV app added some negative impact to the tomcat server, then take it out, but if not, then lets add it back in. Even if WebDAV is useful in the general sense (I tend to agree with Senor Holle that it's not, I don't feel strongly either way), I think it's telling that no one complained when we removed it. Anything we add that's not used is bloat by definition, and more for us to maintain. We didn't remove it. That webapp wasn't serving any useful purpose. Of course, we already do have a WebDAV servlet shipping with tomcat5, and that's the main part. What else did you (Mark T.) think of adding to the distribution? And I'm glad it's being maintained again. This gets me thinking again of the idea of a minimal build: no webdav, no CGI, no examples, no docs, no balancer, minimal server.xml as the default, etc, so as to minimize download size and cater to those users who know what they're doing and just want to drop their webapp into tomcat. Yes, but soon you're going to pitch a HTTP-server-in-100k, complete with its own proprietary API ;) The embedded distribution is IMO good for a minimal distribution. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDAV and TC5
I have mixed feelings. I don't think it belongs in the tomcat distribution. I'd rather see the WebDav servlet get moved to another jakarta (commons?) project. Like commons-webapps, commons-servlets. But then again the webdav servlet is tomcat specific code and might be hard being ported to another container. As long as it can be excluded like ssi and cgi can be, I'm ok. I'm done with my random thoughts. -Tim Mark Thomas wrote: All, Any objections to adding the WebDAV web application to TC5? The plan is to just copy the files across from TC4, modify the build scripts as required and make a small change to the web.xml to overcome an issue with welcome files. If no-one objects, I'll do this tomorrow. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26540] New: - Load balanced sessions not sticking to a server when a tomcatId contains a period
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540
Load balanced sessions not sticking to a server when a tomcatId contains a period
Summary: Load balanced sessions not sticking to a server when a
tomcatId contains a period
Product: Tomcat 4
Version: Unknown
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I was having a problems with my sessions not sticking to the correct web
server in a load balanced cluster. If I set tomcatId/jvmRoute to a
value that does not contain a period, the problem goes away. I'm using
Apache 2.0.47 with JK 2.0.2.
Example error configuration
# This configuration appears to fail because the jvmRoute becomes
# server.mydomain.com:8009 (contains . characters).
[shm:]
file=${serverRoot}/logs/jk2.shm
size=1048576
[lb:load_balancer]
[channel.socket:server.mydomain.com:8009]
port=8009
host=server.mydomain.com
group=load_balancer
lb_factor=1
[channel.socket:server.mydomain.com:8019]
port=8019
host=server.mydomain.com
group=load_balancer
lb_factor=1
[uri:/test/*]
group=lb:load_balancer
Example working configuration (using localhost)
# This configuration works because it constructs a jvmRoute that
# looks like localhost:8009 (no periods).
[shm:]
file=${serverRoot}/logs/jk2.shm
size=1048576
[lb:load_balancer]
[channel.socket:localhost:8009]
port=8009
host=localhost
group=load_balancer
lb_factor=1
[channel.socket:localhost:8019]
port=8019
host=localhost
group=load_balancer
lb_factor=1
[uri:/test/*]
group=lb:load_balancer
Example working configuration (using tomcatId)
# This configuration works because the tomcatId sets the jvmRoute
# to server1 (no periods).
[shm:]
file=${serverRoot}/logs/jk2.shm
size=1048576
[lb:load_balancer]
[channel.socket:server.mydomain.com:8009]
port=8009
host=server.mydomain.com
group=load_balancer
lb_factor=1
tomcatId=server1
[channel.socket:server.mydomain.com:8019]
port=8019
host=server.mydomain.com
group=load_balancer
lb_factor=1
tomcatId=server2
[uri:/test/*]
group=lb:load_balancer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Remy Maucherat wrote: Yes, but soon you're going to pitch a HTTP-server-in-100k, complete with its own proprietary API ;) The embedded distribution is IMO good for a minimal distribution. I for one wasn't about to :-) Rather I think that the module-catalog approach broadens the exposure of the user-community to these modules (rather than them just getting overlooked since they're in there somewhere) and allows separate release points -- which is a dual-edged sword... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26540] - Load balanced sessions not sticking to a server when a tomcatId contains a period
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540 Load balanced sessions not sticking to a server when a tomcatId contains a period [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 23:00 --- Tomcat does sticky sessions by appending a . and jvmRoute to the sessionid. (For example: 06A863B10B3500AA3FBA2A9EF808E876.tomcat4) So if your jvmRoute contains a . - then it will break. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26541] New: - Empty request parameters are stripped as the request passes through the JK connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26541
Empty request parameters are stripped as the request passes through the JK connector
Summary: Empty request parameters are stripped as the request
passes through the JK connector
Product: Tomcat 4
Version: Unknown
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I've noticed that empty request parameters are being stripped as they
go through the JK connector.
For example, if I use the URL http://localhost/Test.jsp?a=1b=c=3, the
parameter b will be null. When not going through the connector, the
parameter b is empty string. I've tested this with iplanet using the JK
1.2.4 connector and on both Apache 1.3 and IIS using the JK 2.0.2
connector.
I've included a sample JSP page to demonstrate this error below.
Test.jsp
%-- Try going to this page with the URL http://localhost/Test.jsp?a=1b=c=3 -
-%
%@ page import=java.util.Enumeration %
html
%
Enumeration parameterNames = request.getParameterNames();
while (parameterNames.hasMoreElements()) {
String parameterName = (String)parameterNames.nextElement();
String[] parameterValues = request.getParameterValues(parameterName);
String parameterValueString = parameterValues[0];
for (int i = 1; i parameterValues.length; i++) {
parameterValueString += , ;
parameterValueString += parameterValues[i];
}
out.println(parameterName + = + parameterValueString + br);
}
%
/html
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26540] - Load balanced sessions not sticking to a server when a tomcatId contains a period
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540 Load balanced sessions not sticking to a server when a tomcatId contains a period [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 23:12 --- I guess something I forgot to mention in this bug is that the default jvmRoute is host:port. Since most host names contain at least one ., such as 172.18.1.1 or jakarta.apache.org, it seems like this will be a common problem. I'm reopening this bug because it caused me a lot of confusion, and it seems like something worth fixing. There is not even an error to indicate an invalid jvmRoute is being used, it just doesn't work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25953] - Add ability for Realm authentication to tell the user the reason for auth failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25953 Add ability for Realm authentication to tell the user the reason for auth failure --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 23:23 --- For the record, the design of the Realm API in this regard was intentional. Telling your user that they got the password wrong (for example) tells a potential hacker that they got the username right. That's a bad security practice. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat-connectors distribution
dear developers (again), please could you give me some hint why you do not respond? is this topic to be asked at the users list? it would be very kind to give some clarification, regards, martin On Tue, 2004-01-27 at 17:49, martin grotzke wrote: dear developers, the current version of the jakarta-tomcat-connectors jk2 is 2.0.2. moreover, the connectors are released together with the tomcat-src. what can be seen as the current stable one? i'm using the jpackage.org's mod_jk2-rpms, these are built with the connector-sources shipped with the latest tomcat-4.1 release. at jpackage, there's the question now if it would be better to provide an rpm built with the connectors shipped with the latest tomcat-release, or if it should be built with the connectors 2.0.2. what would you suggest? thx in advance, martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26540] - Load balanced sessions not sticking to a server when a tomcatId contains a period
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26540 Load balanced sessions not sticking to a server when a tomcatId contains a period [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 00:56 --- Unless you provide a patch (or a committer reopens this) please do not reopen. The sticky session design has been this way (I think) since it has been written. (a few years ago) Implementing a fix would make jk(1) implementations odd since those config file are of the form: worker.WORKERNAME.property=value - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Question in TomCat 5
hi, i too wondered about this. i agree with you that Sun's suggestion of not using object pooling should not be applied in all cases. so let me point out a specific case. i guess Request and response objects are recycled and in the recycle method, all variables are cleared, if they are collection objects, or are set to null. this means you anyway end up creating all the objects again. you end up saving some memory allocation overhead of creating the request object and may be some collection objects. But this is at the cost of doing all the stuff in the recycle method and the added complexity in the code. i guess this is what the sun's site speaks about that memory allocation is no more costly, especially in the newer jvms(say 1.4.2). so my specific question is that do we need to recycle request and response objects when using jdk1.4.2? thanks, nishant. On Fri, 2004-01-30 at 00:53, Filip Hanik wrote: As Yoav said, pooling is a question of how expensive it is to create them. Also to add in there are many more factors to consider 1. how expensive is it to GC in a non pooled environment 2. how expensive is it to synchronize to keep your pool thread safe so it all becomes a question of the scenario that you have, it is not general Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 11:11 AM Subject: RE: Design Question in TomCat 5 Howdy, But from Sun's web page, it said do not pool objects. So my question is Is it a good idea to do object pooling for the sake of performance improvement? Do not pool objects is an overly general tip. If objects are expensive to create, pooling them is a classical way to enhance performance of a system. Yoav Shapira 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] - 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]
DO NOT REPLY [Bug 26451] - URL.openConnection() returns sun class with JDK 1.4.2_03
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451 URL.openConnection() returns sun class with JDK 1.4.2_03 --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 05:06 --- And, if in the next release of servlet binaries, they do away with that package entirely, will you wait till then to implement one of your own, or will you continue to use the deprecated ones? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26451] - URL.openConnection() returns sun class with JDK 1.4.2_03
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26451 URL.openConnection() returns sun class with JDK 1.4.2_03 --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 05:44 --- Becky, chill. If Sun decides to do away with the com.sun.net.** package, then they will replace the functionality with something else. Tomcat 5.0.x's SSL implementation is currently completely agnositic to the vendors implementation (and has been for a very long time on the client-side implementation :). Simply downloading the source distro, and doing a simple 'grep' will show that Tomcat has no dependancies on the com.sun.net.** package. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-connectors/jakarta-tomcat-jk-native failed
Project: jakarta-tomcat-jk-native
State: Failed
URL:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.html
RSS:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.rss
Atom:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native.atom
- G U M P Y
Annotations:
- Error - Failed with reason build failed
- G U M P Y
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 3 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only main
[Working Directory: /data/gump/jakarta-tomcat-connectors/jk/native]
-
Buildfile: build.xml
init:
[echo] /home/ajack
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk
[echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux}
netware=${netware}
apache20:
apache13:
iis:
netscape:
jni:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk/jni
[so] Compiling 4 out of 4
Compiling /data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Compile failed 1
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Command:libtool --mode=compile cc -c -o
/data/gump/jakarta-tomcat-connectors/jk/build/jk/jni/common/jk_map.o
-I/data/gump/jakarta-tomcat-connectors/jk/native/common
-I/data/gump/jakarta-tomcat-connectors/jk/native/jni
-I/usr/java/j2sdk1.4.2/jre/../include -I${build.compiler.base}/include
-I/usr/java/j2sdk1.4.2/jre/../include/linux -g -W
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
[so] Output:
[so] libtool: compile: unable to infer tagged configuration
[so] StdErr:
[so] libtool: compile: specify a tag with `--tag'
BUILD FAILED
/data/gump/jakarta-tomcat-connectors/jk/native/build.xml:82: Compile failed
/data/gump/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Total time: 2 seconds
-
--
Gump http://jakarta.apache.org/gump
[lsd]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-connectors/jakarta-tomcat-jk-native2 failed
Project: jakarta-tomcat-jk-native2
State: Failed
URL:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.html
RSS:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.rss
Atom:
http://lsd.student.utwente.nl/gump/jakarta-tomcat-connectors/jakarta-tomcat-jk-native2.atom
- G U M P Y
Annotations:
- Error - Failed with reason build failed
- G U M P Y
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native2 (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 4 seconds
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only main
[Working Directory: /data/gump/jakarta-tomcat-connectors/jk/native2]
-
Buildfile: build.xml
init.taskdef:
guess.os:
[echo] build.properties i386.Linux
[echo] Linux:true Win32:${win32} Netware:${netware} Solaris:${solaris}
HPUX:${hpux}
init.win32.properties:
init.win32.mc:
init.win32:
init.netware:
init.os:
guess.server:
[echo] Apache2
/data/gump/jakarta-tomcat-connectors/jk/native2/${env.APACHE2_HOME} ${apache2.detect}
[echo] Apache13 /usr true
[echo] IIS ${iis.home} ${iis.detect}
[echo] Iplanet ${iplanet.home} ${iplanet.detect}
[echo] AOLserver ${aolserver.home} ${aolserver.detect}
[echo] JNI ${build.jni}
init:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk2
apache20:
apache13:
[mkdir] Created dir: /data/gump/jakarta-tomcat-connectors/jk/build/jk2/apache13
[so] Compiling 39 out of 39
Compiling /data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Compile failed 1
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Command:libtool --mode=compile cc -c -o
/data/gump/jakarta-tomcat-connectors/jk/build/jk2/apache13/common/jk_channel.o
-I/data/gump/jakarta-tomcat-connectors/jk/native2/include
-I/data/gump/jakarta-tomcat-connectors/jk/native2/common
-I${build.compiler.base}/include -I/usr/include -I/usr/include/apache
-I/data/gump/jakarta-tomcat-connectors/jk/native2/include
-I/usr/java/j2sdk1.4.2/jre/../include -I/usr/java/j2sdk1.4.2/jre/../include/linux -g
-W -DEAPI -D_REENTRANT -DCHUNK_SIZE=4096 -DHAVE_MMAP
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
[so] Output:
[so] libtool: compile: unable to infer tagged configuration
[so] StdErr:
[so] libtool: compile: specify a tag with `--tag'
BUILD FAILED
/data/gump/jakarta-tomcat-connectors/jk/native2/build.xml:519: Compile failed
/data/gump/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
Total time: 3 seconds
-
--
Gump http://jakarta.apache.org/gump
[lsd]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed
Project: jakarta-tomcat-5 State: Failed URL: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html RSS: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.rss Atom: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.atom - G U M P Y Annotations: - Error - Failed with reason build failed - G U M P Y Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 5 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/data/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djndi.jar=/data/gump/opt/jndi1_2_1/lib/jndi.jar -Dcommons-launcher.jar=/data/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar -Dcommons-collections.jar=/data/gump/jakarta-commons/collections/build/commons-collections-20040130.jar -Djmx.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxri.jar -Dactivation.home=/data/gump/opt/jaf-1.0.1 -Djmx.home=/data/gump/opt/jmx-1_2-ri -Dcommons-modeler.home=/data/gump/jakarta-tomcat-5/modeler -Djmx-tools.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxtools.jar -Dregexp.jar=/data/gump/jakarta-regexp/build/jakarta-regexp-20040130.jar -Djasper.home=/data/gump/jakarta-tomcat-jasper_tc5/jasper2 -Dant.home=/data/gump/ant/dist -DxmlParserAPIs.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Djdbc20ext.jar=/data/gump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dsite2.home=/data/gump/jakarta-site2 -Dcommons-daemon.jsvc.tar.gz=/data/gump/jakarta-tomcat-5/daemon/dist/bin/jsvc.tar.gz -Dldap.jar=/data/gump/opt/ldap-1_2_4/lib/ldap.jar -Dregexp.home=/data/gump/jakarta-regexp/build -Dcommons-beanutils.jar=/data/gump/jakarta-commons/beanutils/dist/commons-beanutils.jar -DxercesImpl.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Djsse.home=/data/gump/opt/jsse1.0.3 -Dcommons-pool.jar=/data/gump/jakarta-commons/pool/dist/commons-pool.jar -Dmail.home=/data/gump/opt/javamail-1.3 -Djndi.home=/data/gump/opt/jndi1_2_1 -Djaas.jar=/data/gump/opt/jaas1_0/lib/jaas.jar -Dtomcat-coyote.home=/data/gump/jakarta-tomcat-connectors/coyote -Dcommons-daemon.jar=/data/gump/jakarta-commons/daemon/dist/commons-daemon-20040130.jar -Dcommons-dbcp.jar=/data/gump/jakarta-commons/dbcp/dist/commons-dbcp.jar -Dtomcat-util.jar=/data/gump/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar -Dservlet-api.jar=/data/gump/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar -Dcommons-logging-api.jar=/data/gump/jakarta-commons/logging/dist/commons-logging-api.jar -Dcommons-fileupload.jar=/data/gump/jakarta-commons/fileupload/target/commons-fileupload-20040130.jar -Dcommons-modeler.jar=/data/gump/jakarta-commons/modeler/dist/commons-modeler.jar -Dcommons-logging.jar=/data/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons-el.jar=/data/gump/jakarta-commons/el/dist/commons-el.jar -Dcommons-digester.jar=/data/gump/jakarta-commons/digester/dist/commons-digester.jar -Dmail.jar=/data/gump/opt/javamail-1.3/mail.jar -Djta.jar=/data/gump/opt/jta-spec1_0_1/jta-spec1_0_1.jar -Dactivation.jar=/data/gump/opt/jaf-1.0.1/activation.jar 'prepare-release dist dist-source installer package-zip package-tgz package-src-zip package-src-tgz' [Working Directory: /data/gump/jakarta-tomcat-5] - Buildfile: build.xml BUILD FAILED Target `prepare-release dist dist-source installer package-zip package-tgz package-src-zip package-src-tgz' does not exist in this project. Total time: 0 seconds - -- Gump http://jakarta.apache.org/gump [lsd] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26523] - StandardEngine make two init() calls at sub Mbeans
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26523.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26523
StandardEngine make two init() calls at sub Mbeans
--- Additional Comments From [EMAIL PROTECTED] 2004-01-30 06:40 ---
Hmm, you are right! We can't do everything,
but at StandardEngine the private readEngineMbeans() method is called from
public init(). I thing we can drop the mbeansMB.init() without side effect.
Look at StandardEngine.init()
... L 418
if( mbeansFile != null ) {
readEngineMbeans();
}
if( mbeans != null ) {
try {
Registry.getRegistry(null, null).invoke(mbeans, init, false);
} catch (Exception e) {
log.error(Error in init() for + mbeansFile, e);
}
}
This report is only a hint!
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
